Class Structure - Abstract and Concrete Classes 

There’re many articles your can find to give you a good understanding of Object Oriented
Programming. Since this is a lesson as the beginning parts leading towards BPM and PRPC,
we’ll start from a real business case; walk you through the traditional way of programming, then
compare to the way of OO to make the concept clear.

Business case: Dealing with a piece of work in the real world

Case scenario:

1)      You’re a call centre agent of a bank dealing with customer request over
the phone;

2)      A client called to get a statement of last month;

3)      You get the bank account number of the customer;

4)      Use the number to get the client’s profile

5)      Then authenticate the client by PIN or asking security questions;

6)      You get the beginning balance and a list of transactions by the time
range of last month;

7)      You build the statement of last month with a format with begin balance,
list of transactions and calculated end balance;

8)      You mail the statement to the client with address on client’s profile;

Initial analysis: First we need to get a list of functionalities that can be provided by computer
software that will make the job more efficient. This case is simple enough to give us this list of
functions to be built:

Get Client Profile by Bank Account Number;

         Get begin balance at the begin date, and a list of transactions by begin and end date;

         Calculate the end balance;

         Print the statement with giving format and client address;

Traditional Programming by pseudo code

Begin

Define a list of variables for Client Profile with Account Number, Name, and Address etc;

Read  Account Number from user input;

Read from file or select from database (if there’s a database) and set to the variables of Client Profile using Account
Number as reference key to find right file or database record;

Define the Begin Date and End Date of the time range;

Read Begin Date and End Date from user input;

Define variables of beginning balance and an Array for transactions with variables;

Read Beginning Balance of the Account with Beginning Date from file or select from database (if there’s a
database) and set Beginning Balance;

Read transactions from file or select from database (if there’s database) and Loop the Transaction Array to to set
the variables;

Calculate the End Balance and write back to file (or database);

Define a Position Array for printing format;

Calculate position of each variable to match the printing format and set the Position Array for printing;

Print with all variables and Positions;

End

There’s nothing wrong with this approach. Over decades, this type of approach served the
business well and many of such programs are still working. Likely, there’re more than just a few
such programs are working independently for serve different business cases.

Challenges happen when we need to make certain changes to such program. For example, the
file (or database) structure need to be changed, say the Bank acquired another bank and it’s client
information are in different format, since there’re many other important programs are using the
file (or database), we don’t want to change the file format (or database structure), but we need to
make this statement request program working for all clients from the acquired bank too. Then
any programs like this one that needs to get the client profile would have to go through the
change/test/deploy process to adopt the new format. It could be a big cost for the acquisition.

OO Design and Programming

From the concept, Object Oriented Design and Programming is trying to utilize some of the ways
that human recognize the real world. A bank client has account number, name and address; a
statement has begin date, end date, a list of transactions, as it appears in the printed paper.
OO design is about how to define a reusable piece of program, which can be used by multiple
programs, each program that’s using it does not need to get into all details of that particular
piece. For example, you can define a piece of code which can represent a Bank Client, It has
Bank Account Number, Name and Address; you can do operations like Update Address, Get
Statement by time range. Then define a piece of code which can represent a Statement that has
Begin Date, End Date and List of Transactions, you can do Print Statement.

The Program in our case will become simple like:

Begin

Load Client by Account Number;

Get Statement by Begin Date and End Date;

Print Statement;

End

Any program that needs to use Client Profile would not need to redefine variables in its own, and
need not to know where the details of the Client Profile come from (File, Database, or another
system)

To achieve such level of simplicity and reusability, certain design and programming approaches
would be needed. Of course, the programming language used much also support the OO.

The introduction of OO needs to go through a few concepts:

Object and Class;

Design time and runtime;

Inheritance;

Object in OO can be related to a real world object. “John Smith” as a real person, must have a
name, an address, birthday and gender. He can do “ Talk”, “ Walk” and “Sit” etc.

Class is an abstract level of define a group of Objects, when we look at many individual person,
we realize that each person has something in common, like “Name”, “Address” as “Attributes”, “
Talk” and “ Walk” as behaviours.

If we define “Person” as a class, then “John Smith” is an “Object”, which is an instance of the
class “Person”.

Design time is when we define and write the program codes of “Classes”. At this stage, we’re
not talking about “John Smith” and his address. But define what an “Attributes” for this class
“Person” should have and what type of operations we can do with it.
Runtime is when the program code we defined as “Class” is used and loaded into computer’s
memory. By then we need to setup the “Object” by create an instance of the “Class” we defined
and coded in the design time. And we need to set all the “Attributes” of the “Object” we created.

Inheritance is how we define levels of abstraction of objects i.e. level of classes. Think about
Animal  Dog Chihuahua, or in our case, Person  Bank Client

Superclass and Subclass are relatively defined. Animal is the Superclass for Doc, Doc is the
Subclass of Animal; while Doc is the Superclass of Chihuahua.

Attributes and Operations defined in Superclass, by inheritance, will be part of the Subclass’s
attributes and operations, which means if we define Name and Address in Class "Person”, when
we define “Bank Client” as its Subclass, we call “ inherited from class Person”, will have Name
and Address already. No need to redefine it in Bank Client again. If we talk about an operation
“updateAddress” for class “Person”, “Bank Client” can use this operation by default. While more
than just a “Person”, “Bank Client” may have specific operations like “getAccountBalance”,
which is for “Bank Client” only, since not each person could be a “Bank Client”.

Now we can at least looking at two levels of reusability:

Class/Object level for Runtime: “Bank Client” as a class, can be reused in multiple programs
whenever a client profile and common operations needed for client like “getAccountBalance”;

Inheritance Level for Design time: “Person” as a class has many attributes and operations that
are common for it’s subclasses like “Bank Client”, “Investor” or “InsurancePolicyHolder”.
Proper level of class definition will give wider range of reusability and expendability to the
program packages.

Let’s come back to our case using the OO approach now.

First in design time, we can define a class of “Bank Client”, not going into the higher level of
abstraction to “Person”.

“Bank Client” has attributes: Name, Address, and Account Number;

Operation: getStatementByTimeRange(beginDate, endDate),

“Statement” has attributes: beginDate, endDate, transactionList, beginBalance, endBalance

Operations: Print

Now the actual pseudo code for request statement program using OOP will be:

Begin

BankClient aClient(Read accountNumber from user input);

 Statement thisStatement = aClient.getStatement(Read Begin Date and End Date from user input);

thisStatement.Print;

What need to know is, if you do this only once and never going to use it again, there’s no real
point to go through these OO design and program. But think about this BankClient and Statemet
can be reused by any other programs, and if there’s any changed need to be made for
“BankClient” to get client details from different file structure, databases or any other systems,
the programs that’s using “BankClient” never even need to know.

There is more information about the techniques needed for how to properly define and use
classes.

In PRPC, OO is a key concept need to be grasped since not only real world object will be defined
and used as classes and objects, also many data and composition of data structures will also be
defined and used as classes and objects.