Object Oriented Java
In this, we will discuss Object Oriented Java, its components and language. At the end, you should have an understanding of:
- A History of Object Oriented Programming (OOP).
- Comparing OOP to previous methods.
- The components of Object Orientation (OO), i.e. Objects, Classes, Encapsulation, and Polymorphism.
- OO Modeling Notation, the Unified Language (UML); how these concepts are diagrammed; the notation used to concepts from user to analyst to programmer.
A Change in Design
With the move to an object-oriented language like Java, it is not just the programming that changes, but the design concepts as well.
In many ways, the language and its constructs are the easy parts to learn.
It is the change in mind-set that is required in order to think of problems and solutions in an object oriented way that is difficult.
This may take some time to achieve.
The History
Object Oriented Programming (OOP) is not a new concept. The first of these languages was produced in the 1970s.
However, the limitations of early computer systems, including CPU performance and limited memory, slowed the acceptance of OOP.
Some structured languages, such as C and COBOL, have had OO derivatives or extensions made to produce new OO languages, such as C++ and Object COBOL.
Other new languages, such as Java, have been written from the ground up, using object oriented principles.
OOP compared to Structured programming
For many years, most systems were designed using structured programming methodologies, and written using procedural language like COBOL or PL/I.
Structured programming dictated that a system be fully specified before a single line of code was written, leading to either good documentation and limited code, or limited documentation with flexible code.
The ideal in structured programming was to specify a system made up of “black boxes”, where the implementation of the “box” was hidden, and the execution of the box had no side effects for the parameters passed to it.
Good structured design had procedures that were self-contained and did not modify external data. However, the procedural languages that these systems were written in allowed modification to take place.
COBOL, with its implementation of a global WORKING STORAGE, is particulary prone to violating this goal.
As systems grew, even well specified black boxes tended to be less black. Changing one procedure could lead to unforseen consequences, so testing requirements grew dramatically.
Object Oriented Design (OOD) and programming addresses these issues and more.
Objects
Objects are the building blocks of object oriented programming.
Objects represent real world entities. Look around and you will see many objects — a car, a telephone, a stapler, a pencil, a computer.
When you deal with these objects, you do not separate their attributes or methods. You deal with them as a whole, i.e. you drive a car, you make a phone call, you write with a pencil.
You start a car, put it into gear, press the gas pedal, and drive. You do not think about how pressing the gas pedal makes the car move, or how the speedometer measures the car’s speed.
Using an object oriented approach, the car is an object that has attributes and methods.
In this example, speed is an attribute and pressing the gas pedal is a method. Object orientation models real world objects.
An object is an entity that has data or attributes, and a set of behaviors or methods.
Methods: Start, Stop, Accelerate, Brake, Turn, etc.
Attributes: Speed, Direction, Color.
Class
A class is a group of objects that share common attributes and common methods.
Referring to the car as an object, yourCar is an object, myCar is an object, joesCar is an object, but they are all cars.
In OO terminology, myCar is an instance of the class Car.
If the class Car had attributes of color and owner, they could be different for each car, but they would all be cars.
Diagramming
As object orientation developed, the need for design notation that analysts, developers and clients would accept as standard became necessary, in the same way as circuit diagram schematics serve electrical engineers.
This standard notation is called the Unified Modeling Language (UML). It evolved from the combined work of Grady Booch, James Rumbaugh and Ivar Jacobson, who had been developing their own notation seperately, As many organizations felt the need for a single notation, a UML consortium sprang up. This involved many influential companies, including DEC, HP, Microsoft, and Oracle.
In 1997, the consortium produced version 1.0 of the UML and submitted it to the Object Management Group (OMG) in response to the OMG’s request for a standard modeling language.
UML has become the de-facto standard for the software industry, and it continues to evolve.
Next, you will explore UML notations and diagrams, along with the concepts that they describe.
These will be used later to describe or specify Java programs.
Notations
Object Oriented Design and Programming includes notation conventions. We will use the UML conventions and introduce the various components as we go along.
- Class Names: underlined, mixed case, with the first letter of each word capitalised, no spaces or hyphens.
Examples: Car, E.gpgj_l, LoanAccount - Attribute Names: italicized, mixed case, first letter lowercase, first letter of remaining words capitalized, no spaces or hyphens. Examples: bodyCoIour, leadSize, accountNumber
- Method Names: boldface, mixed case, first letter lowercase, first letter of remaining words capitalized, no spaces or hyphens, begins with a verb. Examples: press The Gas, doWrite, makePayment
- A named instance or object is a class associated name: and object’s name begins with a lowercase letter, precedes a colon that precedes the class name, and the whole name is underlined.
Examples: myCar:Car, aPenciI:PenciI, currentAccount:LoanAccount
Note: The use of typefaces and text attributes will vary, depending on the tools being used, the important thing is consistency and that the convention is known to both the author and reader.
Objects and Classes
Having introduced both objects and classes, it is now possible to define them in relation to each other
Class — a category or group of things that have similar attributes and common behaviours; a template for creating objects
Object — an instance Of a class that has values for each Of the attributes of a class, The second part Of the object definition is very important, i.e. an object must have a value for each attribute.
The more attributes and behaviours that you take into account, the more accurate will be the representation you have of the real world problem.
Using our car example, we can represent the Car class (using UML), as seen here.
A class is represented by a rectangle, divided into three areas:
- The upper contains the name.
- The middle contains the attributes.
- The lower contains the methods.
We represent the object instance myCar:Car of class Car with a name and a value for each attribute, as shown.
Encapsulation
Here, we take our model of a car and write a program to represent it, using a traditional structured approach, follwed by an 00 approach.
In a traditional (COBOL) approach to modeling a car, we would define a data structure for it like this:
We would build separate procedures to operate on the car’s data:
If we wanted to change the car structure, we would have to check all the procedures for references to the data.
On the other hand, the object oriented representation would be like this:
public class car {
float speed;
String owner;
int color;
public void speedup() {
speed = speed + 1;
public void start() {
speed = 0;
}
}The attributes of the car and the methods needed to maintain them are kept together in a single class.
Also, notice that the attributes or data of the car class are not updated directly, but are updated by the speedup method.
The hiding or protecting of an object’s data is called encapsulation.
Nothing outside of the object should be aware of an object’s internal structure, or how its methods are implemented.
Inheritance
- A class is a category of objects.
- An object is an instance of a class.
- The object inherits all the characteristics of the class.
This is the simplest form of inheritance. Whatever attributes and methods defined for the Car class, myCar inherits.
Not only can an object inherit from a class, a class can inherit from another class.
Inheritance permits the sharing of attributes and methods among similar classes.
A passenger car is a type of vehicle, as is a bus and a truck. Therefore, we could have a PassengerCar class, a Bus class, and a Truck class that all inherit common attributes from the Vehicle class.
We can say PassengerCar, Bus and Truck are all subclasses, or children, of Vehicle, and that Vehicle is, in turn, a superclass or parent.
When you use inheritance to build a specific type of object from a general object, you can describe the relationship by using the terminology “PassengerCar extends Vehicle” or “Bus is inherited from Vehicle”.
Here is the UML representation of the relationship between the PassengerCar, Bus, and Truck subclasses, and the Vehicle superclass.
Note that the arrow points from the child to the parent.
This tells us that the PassengerCar class will not only have bodyShape and passengers, but will also have engineSize, numberOfWheels, noOfDoors, speed, color, and owner, which are inherited from the Vehicle class.
Java supports single inheritance only
Pure OO allows for child classes to have multiple parents. This is called Multiple Inheritance.
Java permits children to have only one parent. This is called Single Inheritance.
A child class can also have children.
If a subclass has subclasses, it is both a superclass and a subclass. Its subclasses inherit the attributes and methods of both itself and its superclass.
Aggregation
If we were to take a look at a typical personal computer (PC), we would see that it is made up of a mouse, a keyboard, a central processing unit (CPU), a disk drive, a graphic card and a monitor, speakers, and many other components.
Each of the components have different attributes and behaviors, so they cannot be related by inheritance.
However, we usually deal with a PC as a whole, and can describe its attributes and behaviors as a whole.
Such an association between objects is called an aggregation.
In UML, we represent an aggregation, as shown here. At a higher level, we can then deal with the PC as a whole.
This diagram can be interpreted as a PC consisting of the shown components.
Note that the number of parts involved in the relationship is shown.
1 == 1 only
n == n only
* == 0 or more
1..* == 1 or more
n..* == n or more
n..m == n to m
(as the number of speakers here is shown as 2 to 4)
Association
There is often a relationship between two classes of objects that is not inherited and not aggregated.
The classes do not share attributes and behaviors. They are not part of, nor do they contain each other. Such a relationship is called an association.
Examples of associations are those between a PC user and the PC, or a driver and a car.
In the UML, we can show that one user uses many PCs, or that many drivers drive one car.
Polymorphism
Sometimes, an operation has the same name in different classes. You can open a newspaper, open a door or, open a bank account.
In each of these cases, “open” is a different operation.
In OO, each class knows how that operation is supposed to work for itself.
When the same message, or method, or request can elicit a different response, depending on the class that is receiving it, this is known as polymorphism.
Object Communication
In traditional systems, programs and procedures call each other with parameters. In OO, objects send and receive messages.
One object sends a message to perform an operation, the other object receives the message and performs the operation. The messages generally consist of a class or instance name, a method name, and required arguments.
In our car example, we have a message from the driver to start the car, and another message to speed up.
Of course, these messages can be diagrammed by the UML. For these interactions, a sequence diagram is used.
This sequence diagram example shows the interaction between a PC user and a PC’s components.
The messages being passed, the sender and the receiver, and the sequence in which they occur are shown.
Note: The PC user on this diagram and others that you will be presented with is called an actor. This term represents an entity (system or person).
Other Concepts and Notations
Object Orientation and the UML is a complete area that tries to cater for all situations and model all components and stages of a system.
To do this, there are many other types of diagrams and notations that can be constructed, which the Java programmer or analyst may be presented with.
You have seen class, object and sequence diagrams.
You will now briefly see some of the other types of diagrams that you could be presented with or produce when dealing with 00 and Java system development.
Use case diagrams
Use Case: Showing system usage, each Use Case appears as an ellipse, and each actor as a system or person.
The Use Case is a concept to help an analyst or programmer understand how a system should behave. An actor initiates a Use Case and an actor (possibly the initiator) receives something of value from the Use Case.
The Use Case can show the boundary between the system and the outside world. Actors are usually outside the system, whereas the cases are inside.
State diagrams
A state diagram captures the state of an object during a specific time period. It presents the state that an object can be in, along with the transitions between states. It also shows the start and end point of a sequence of changes.
A state is represented as a rounded rectangle.
A transition between states is represented as a line connecting those states.
Note: A state diagram can also be referred to as a state machine.
Activity diagrams
An activity diagram shows the steps and decision points that occur within the behavior of an object, or within a business process.
Each step is an oval, and each decision point is a diamond.
Collaboration diagrams
A collaboration diagram is a way of visualizing how objects work together over time (as in a sequence diagram).
It is an extension of an object diagram which, in addition to the associations between objects, shows the messages that objects send each other.
Objects may be anywhere on the diagram. Messages from one object to another appear as lines connecting the objects. Each line is numbered according to its position in the sequence of messages, and shows information about the message.
Component Diagrams
A component diagram models the components of a system. It contains components, interfaces and relationships.
Each component appears as a rectangle, with smaller rectangles overlaid on its left border.
Deployment diagrams
A deployment diagram represents the physical architecture of a computer system.
It can show each computer and device in a system, and the components that reside in each computer.
The main hardware item is a node, which can be either a processor (e.g. servers or workstation) that can execute a component, or a device (e.g. printer or monitor) that cannot.
The computer or node is represented as a cube with individual components within.
Use what you need
The UML is a very rich toolset that an analyst or programmer can use to choose the tool to suit the job.
Not every problem needs to be recorded using every method. As a programmer, you need only recognize what is presented.
Remember — UML is a tool to help you.
Conclusion
I hope you’ve enjoyed it and have learned something new. I’m always open to suggestions and discussions on LinkedIn. Hit me up with direct messages.
If you’ve enjoyed my writing and want to keep me motivated, consider leaving starts on GitHub and endorsing me for relevant skills on LinkedIn.
Till the next one, happy coding!
