It should come as no surprise that the programming paradigm of the language used
to implement the system will affect the architectural style of that system.
Each programming paradigm has its own set of constructs and
their use will shape the system you create.
There are many different styles of language-based architecture systems.
In this lesson, we will explore the object-oriented architectural style,
which results from the object-oriented programming paradigm.
When you're choosing to develop a project using an object-oriented language,
such as Java or C++, you're not simply choosing a language.
Object-oriented principles, constructs, and
design problems are all part of the whole deal.
Before we move on,
let's briefly recap the object-oriented principles that are available to you.
First, there's abstraction.
With abstraction, you can simplify a concept by ignoring unimportant details.
Next up is encapsulation.
Encapsulation allows you to bundle data and
functions into a self-contained object.
So that other objects can interact with it through an exposed interface.
Also, let's recall decomposition,
which allows you to break up a whole problem into smaller, distinct parts.
And lastly, generalization allows you to factor out conceptual commonalities.
Also at your disposal are object-oriented design patterns.
Object-oriented design patterns fall into creational, structural, and
behavioral categories.
Creational patterns guide you in creating new objects.
Structural patterns describe the relationships between objects and
the interactions between classes and subclasses.
And behavioral patterns focus on how objects perform work individually and
how they can work as a group to accomplish something.
Together, elements like these will lead to an object-oriented
architectural style for the system.
The object-oriented architectural style is focused on the data.
When presented with a system to model,
you may begin by looking at the different kinds of data handled by the system
to see how the system can be broken down into abstract data types.
An abstract data type can be represented as a class that you define to organize
data attributes in a meaningful way, so that related
attributes are grouped together, along with their associated methods.
An encapsulation restricts access to the data and
dictates what can be done with it.
Object-oriented refers to a system composed of objects,
where each object is an instance of a class.
In other words, the type of each object is its class.
Objects may interact with each other through the use of their methods.
The object-oriented paradigm allows for inheritance among abstract data types.
This means that one abstract type can be declared an extension of another type.
These classes themselves form a language-based architecture that arises
from basic object oriented principles.
The classes within the system will determine the overall
structure of the system.
Now lets consider how an automatic pet feeder would be implemented using
an object-oriented approach.
Our goal is to create classes that accurately and
succinctly model the entities involved in the problem.
To do this, you must first take stock of the data and information flow that is
present in the system so that we can identify classes within this system.
The objects in this system are the pets and the food dispenser.
The food dispenser device consists of a pet food storage container to
hold the kibble.
The bottom of this container may be temporarily opened to dispense food to
a dish below.
The dispenser also includes a light on top that will flash when it's empty.
Each pet in the system wears a collar with a unique ID tag.
Suppose that when in close proximity to the food dispenser, the pet's collar tag
triggers the food dispenser to drop a portion of pet food into the dish.
We can model pet and
food dispenser objects in the system as abstract data types.
The pet class would have attributes for
it's collar ID, maximum daily food intake amount, and current food intake amount.
The maximum daily food intake amount is a value the pet owner can set
that determines the maximum amount of food the pet may consume in a whole day.
And the current food intake amount is the amount of food the pet consumed so
far that day.
The pet class would have a method update or reset its current food intake amount.
So each morning, this value would reset to zero.
The food dispenser class would have attributes to keep track of which
pets are authorized to visit it and how much food is left.
The food dispenser class would have a method to dispense the food and
a method to flash its light when it runs out of food.
Instances of these classes would interact with each other to determine whether or
not food should be dispensed when a particular pet visits the dispenser.
The overall object-oriented architectural style of the system directly follows from
the fact that an object-oriented approach was used in the development.
Some problems are well-suited to the object-oriented architectural style.
In the example we looked at above,
it was relatively easy to identify the classes involved.
However, this is not always the case.
In a system centered around scientific computation, the identification of classes
may result in unnecessary complexity, and in turn, lower performance.
As we shall soon see, the object-oriented programming paradigm will not always be
the most appropriate solution to a problem.
Another design choice may be better suited for the problem at hand.
Kenny WongAssociate Professor
