SLAC PEP-II
BABAR
SLAC<->RAL
Babar logo
Workbook HEPIC Databases PDG HEP preprints
Organization Detector Computing Physics Documentation
Personnel Glossary Sitemap Search Hypernews
Unwrap page!
Wkbk. Search
Wkbk. Sitemap
Introduction
Non SLAC
HOWTO's
Introduction
Logging In
QuickTour
Detector
Info Resources
Software Infrastructure
CM2 Introduction
Unix
OO
SRT
Objectivity
Event Store
Framework
Beta
Modifying Code
Writing and Editing
Compiling
Debugging
Analysis
Framework II
Analysis
Find Data
Batch Processing
PAW
PAW II
ROOT I
ROOT II
ROOT III
Advanced Infrastructure
New Releases
Workdir
Main Packages
Event Displays
Gen/Sim/Reco
Contributing Software
SRT and CVS
Coding
Advanced Topics
Make CM2 Ntuples
New Packages
New Packages 2
Persistent Classes
Java
Site Installation
Check this page for HTML 4.01 Transitional compliance with the
W3C Validator
(More checks...)
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