PRPC OOP Terms: Classes

Abstract base class (ABC), is a class that cannot be instantiated; in PRPC this means that a clipboard page cannot be created using the class. An abstract class is designed only as a parent class from which child classes may be derived. Abstract classes are often used to represent abstract concepts or entities. The incomplete features of the abstract class are then shared by a group of subclasses which add different variations of the missing pieces.

Abstract classes are super classes which contain abstract methods and are defined such that concrete subclasses are to extend them by implementing the methods. The behaviors defined by such a class are "generic" and much of the class will be undefined and unimplemented. Before a class derived from an abstract class can become concrete, i.e. a class that can be instantiated, it must implement particular methods for all the abstract methods of its parent classes.

Partial classes are classes whose implementations are split over multiple Rulesets, making it easier to deal with large quantities of code and to allow selective substitution of implementation flavors using Access Group or Application Record as a means for switching-out one version for another at runtime. A primary benefit of partial classes is allowing different programmers to work on different parts of the same class at the same time. It also makes automatically generated code easier to interpret, as it can be separated from other code into distinct Rulesets.

PRPC OOP Terms: Public versus Private Access

In computer science, the principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed. The protection involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change). In modern programming languages, the principle of information hiding manifests itself in a number of ways, including encapsulation (given the separation of concerns) and polymorphism. PRPC supports information hiding through both polymorphism (though somewhat limited polymorphism) and separation of concerns through its implementation of the class hierarchy and Ruleset packaging. Consider the following three "access modifiers" popular in most Object Oriented languages.

A concern is a generic term used to encompass any programmatic element (aka rule instances) including class definitions, activities, properties, streams, or other rule types.

Friendly: a property, activity, stream, or class that is accessible to the class itself and to all classes in the same Ruleset. A property or method is declared friendly by virtue of the absence of any more specific access modifiers.

Friendly access is accomplished by defining classes and other concerns directly inside the Ruleset housing the primary application. There is no restriction applied to internal knowledge between classes and concerns declared thusly. It is the easiest to implement (indeed it is the default) and the hardest to maintain.

Friendly Classes

Public: a property, activity, stream, or class that is accessible to every class with visibility to the Ruleset. It is distinguished from friendly access in that explicit access is must be specified to allow interaction between concerns contained by different Rulesets.

Public access in PRPC is implemented by allowing an application's primary Ruleset Version to have prerequisite knowledge of the Ruleset in which a class and related concerns are defined. It may be accomplished with a minimum of two Rulesets.

Public Class A

Private: a property, activity, stream that is accessible only to the class in which it is defined. Note that a class cannot be declared private as a whole.

Private access in PRPC is implemented by allowing an application's primary Ruleset Version to have prerequisite knowledge of the public Ruleset as above. The class in question is defined within the public Ruleset. Additionally, the public RuleSet Version is allowed prerequisite knowledge of a second private Ruleset into which private concerns are placed. The application itself may not refer to any concern defined within the private Ruleset; invocation of these concerns may only be accomplished through access to public methods (which may be a virtual method). This may be accomplished with a minimum of three Rulesets.

Public (partial) Class A with Private Class B

In such an arrangement, concerns that extend Public Class A may be included in the private Ruleset making Class A into a partial class. This allows concerns within Class A to be a mix of Private and Public access. Indeed, multiple Private Rulesets may be created to extend the private capabilities of Class A without impacting the integration between the application classes and the public interface of Class A.

PRPC OOP Terms: Methods

Methods are functions whose behavior is tied to a specific class. The intimacy of a method to its class allows extraordinary control over the state of objects derived from the class but also limits the behavior relative to other objects. This restraint assists developers in managing boundaries between objects and the classes that define them. Below are three special purpose method types with which you should be familiar.

Abstract method is a function whose behavior is appropriate to any objects derived from subclasses of an Abstract Base Class.

An abstract method is implemented as an activity (or other action-oriented rule type) whose "applies to" name part is a PRPC abstract class. It will generally operate only against properties defined within the abstract class and allow specialization of large portions of functionality by making frequent calls to Virtual methods (see below).

Virtual method is a function whose behavior, by virtue of being considered "virtual," is determined by the definition of a function with the same signature furthest down in the inheritance lineage of the instantiated object on which it is called. By convention, virtual methods are typically implemented within Abstract Base Classes. This concept is a very important part of the polymorphism portion of object-oriented programming (OOP).

A Virtual method is implemented by creating a "stub" or Activity with no steps (or other rule type) in a parent class and a like-named, overriding method Activity in a subclass with steps defined. An activity intended to use the method against a subclass Instance at run-time will call the virtual method using a Step Page whose class is defined as being of the (usually Abstract) parent class. At compile-time, access is validated against the Virtual method (Activity) and at run-time the overriding method (Activity) is executed.

Static methods act at the class level rather than at the instance level. Therefore, a static method cannot refer to a specific instance of the class. They may be found in both concrete and abstract classes.

A static method is implemented as an Activity that does not operate on its Primary page. Any internal functionality will use pages explicitly created via Page-New, Obj-Open, etc.. It may therefore be invoked without an appropriately instantiated page using a Call <class name>.<static activity name> syntax with an empty Step Page.

Peer Interviewing

In our business every member of staff is likely to be interviewing potential new team members or being interviewed by clients to determine their fit to project needs. Improvement in your interviewing approach will inevitably improve your skills as an interviewee; these are sides of the same coin and coin is money. To that end, we (Jessica and I) try to involve as many people in our vetting process as is feasible. For the bulk of Knowledge Warriors, your involvement in the hiring process will fall under the aegis of peer interviewing. When you have the opportunity to be involved in a peer interview, you should look at the experience as your opportunity to:

1. Impact the growth of the company;
   
2. Influence the quality of people with whom you work, learn, and earn;
   
3. And Invest in your own interview skill: a chance to learn, to improve.
   

With that in mind, here is my advice on how to approach the interview itself. In general, a peer interview is about deciding if the interviewer and interviewee would enjoy working together; a two-way street. If something about the candidate makes you suspect that they would make a poor colleague, whether because of attitude, behaviors, or skills lacking, the company may be able to do better. We do not hire just any warm body (no, not even ones with previous PRPC experience). Mind you, your responsibility is to see beyond your own personal peeves and prejudices to judge a candidates suitability on more defensible, general criteria. You will be asked to substantiate your opinions; those opinions are expected to be drawn from your unique perspective.

First timers often don't know where to start in the conversation.

• Don't fall into the trite path by asking generic questions like: "where do you see yourself in 5-years?". What are you going to do with that information? Let managers ask stupid questions.
  
• Also, don't spend the entire interview talking, spend it mostly listening. Engage your candidate, answer questions, but you should seek to have them do most of the talking. Resist the urge to fill-in the gaps in the conversation. Let them struggle a little by embracing the quiet moments.
  

So to avoid generic questions and to get your candidate talking, try using follow one or both of the following styles of peer interviewing.

Project/Position Experience Approach

Probably the most often used approach to interviewing is to look at the candidates resume as a list of accumulated experiences. This viewpoint asks you to judge in two fundamental dimensions:

1. Are experiences applicable, directly or indirectly, to the situations that a person in the target position will likely face.
   

This involves probing beyond the basic summary information contained in most project/position resumes to determine the essential dynamics of the experience. Ask questions that will unearth aspects of the experience that will be revealing in light of challenges that you have faced at KR. Here are some examples.

• Who was the 'customer(s)' for the project?
  
• What were the deliverables?
  
• Did you have to live with the decisions that you made or the code that you delivered?
  
• Was the timeframe strict or was it loose?
  
• Was the candidate in charge or following direction, individually contributing or part of larger team?
  
• Was the politics of the situation complex?
  
• Was the experience technically challenging?
  
• What was the result of the effort and did the candidate have a material impact on the outcome?
  

 

1. Have the experiences produced an attendant education in the mind of the candidate.
   

Projects and positions of the past are only valuable if those experience have left a positive impression on the candidate; did they learn something? This involves probing to see if the candidate was paying attention to what was going on around them. Do they remember what the key issues where and how they were faced? Can they demonstrate that new skills were derived or that existing skills where improved? Dig beyond what the candidate has written on the resume. Is there detail behind the experiences? Is there evidence of reflection; thoughtfulness?

Skill/Behavior Approach

Most resumes, particularly technical resumes, these days have a buzzword bullet list. These usually list languages, tools, technologies, and methodologies with which the candidate is familiar. They are either called-out in a separate space or embedded within each experience block. I think that the average candidate feels driven to make this list long at the expense of depth. Interviewing a candidate from this viewpoint will involve digging into these bullet-bites to determine which are real and which are fantasy. Similarly, this viewpoint asks you to judge two fundamental dimensions:

1. Does the candidate (still) know enough about a listed skill to make it valuable today?
   

The easiest way to begin is with the assumption that those items listed first are the most familiar. Using that assumption, I often use start probing in the middle. If those middle skills are solid, I will move further down. If not, I will move further up and discount those below. You might just select items with which you are most familiar yourself and probe those. If you want to probe something for which you have no current knowledge, Google it first. Find something tricky and ask the candidate to explain it to a novice. There is no need to be (or to appear to be) an expert in order to judge someone's knowledge of a subject.

1. Are the real skills either directly useful to the proposed role or are they analogous enough to be of value?
   

Direct applicability are easiest. Knows PRPC, BPM, or rules well… good sign. Knows Java, HTML, XML, MQ-Series, WebLogic, etc… probably very useful. Analogous skills are harder to gauge. You might consider factors such as:

• Was the knowledge difficult to master?
  
• Does their application require logical, structured thinking?
  
• Is a language or approach object oriented or procedurally oriented?
  
• Is the application of the knowledge linked closely to business results?
  

Now that you have questioned the candidate, it is time for you to provide them with an opportunity to understand what they are getting themselves into. Since you are generally living the life that the potential hire will be entering, your perspective is important. I usually allow the candidate to ask questions. If they don't have questions, you should take the opportunity to fill them in about the challenges of working for KR. Be positive, but honest and direct. Remember to share the positive, but resist the urge to oversell. We are asking people to commit to spending 1.5 – 2 years minimum time with us to justify the training and up-front investment. People need a realistic expectation of what it will take to thrive as a Knowledge Warrior. In the end, you are going assessing whether the candidate will have what it takes to do just that.