 Principles and Definitions
Massimo Marino - LBNL/ICS
This constitutes a very very brief description of the Principles
and Definitions that should be applied and be adhered to in order to -
pretend to - do Object Oriented Programming. It is not intended to
provide exhaustive explanation: That would have be out of the scope of
the present document. To obtain further details there is no
other option than to discuss them with experts around or browse the
literature.
They are important because of their deep impact on the entire architecture
of an OO application, especially if violated. If that is the case,
you could still get a working application, object-based, but definitely
not OO. Never forget that OO does not come automatically by just programming
in C++, or by using objects.
First, you should always ask yourself if the class (and objects from
that) you just finished declaring and defining adheres to these two basic
definitions:
Object
package of data and the procedures (methods) that operate on
that data. It performs an operation when it receives a request (message)
from a client. Requests are the only way to change an objectâs internal
data. The internal data is said to be encapsulated: it cannot be accessed
directly and its representation is invisible from outside.
Interface
Are fundamentals to OO systems. It says nothing about the
object implementation. That means two objects having completely
different implementation can have identical interfaces. This leads to
the principle: Program to an Interface, not to an implementation. This
so greatly reduces implementation dependencies between
subsystems.
Principles guide you in the invention process of classes, relationships,
and their collaboration, and in the way these last are implemented. They
are the "golden rules" that will make simpler to achieve the promises of
OO programming: Robustness, Maintainability, Reusability.
The Law of Demeter
A supplier object to a method M should be restricted to:
Constituents (immediate) of the object
accessed through this
Arguments (objects) of M
objects whose creation is responsibility of the class defining M
objects in global variables
Open-Closed
Modularity in terms of objects at the same time - Open -
and further extendable - Closed - without direct modification.
Achieved establishing collaborations among abstract classes and making
full use of polymorphism
Liskov Inheritance
Put behavior in foremost consideration: Derived classes must
be usable through the base class interface without the need for the user
to know the difference.
Dependency Inversion
Data and processes (internals) shielded behind interfaces and
crisply defined objects responsibilities: Details depend upon abstractions.
Interface Segregation Principle
Clients should only know their pertinent interface: Non-cohesive
object should multiply inherit from cohesive abstract base class interfaces.
Different groups of clients should use a different subset of the available
interface.
 Massimo Marino
|
