Home > Pyxis Agile expertise centre > Object Oriented Programming

Object Oriented Programming

Object-oriented programming (OOP) is a programming paradigm that uses "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs. Programming techniques may include features such as data abstraction, encapsulation, modularity, polymorphism, and inheritance. Many modern programming languages now support OOP.

Concepts

Core principles

Design goals

Orthogonality : Orthogonality is a system design property facilitating feasibility and compactness of complex designs. Orthogonality guarantees that modifying the technical effect produced by a component of a system neither creates nor propagates side effects to other components of the system.
Low coupling : degree to which each program module relies on each one of the other modules.
High cohesion : a measure of how strongly-related is the functionality expressed by the source code.

S.O.L.I.D principles

Uncle Bob's Principles Of Ood

Class design (SOLID):

Single Responsibility Principle : A class should have one, and only one, reason to change.
Open Closed Principle : You should be able to extend a class behavior, without modifying it.
Liskov Substitution Principle : Derived classes must be substitutable for their base classes.
Interface Segregation Principle : Make fine grained interfaces that are client specific.
Dependency Inversion Principle : Depend on abstractions, not on concretions.

Package cohesion:

The Release Reuse Equivalency Principle : The granule of reuse is the granule of release.
The Common Closure Principle : Classes that change together are packaged together.
The Common Reuse Principle : Classes that are used together are packaged together.

Coupling between packages :

The Acyclic Dependencies Principle : The dependency graph of packages must have no cycles.
The Stable Dependencies Principle : Depend in the direction of stability.
The Stable Abstractions Principle : Abstractness increases with stability.

Inversion of Control

Inversion of Control, or IoC, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to procedural programming.

In traditional programming the flow is controlled by a central piece of code. Using Inversion of Control this central control as a design principle is left behind.

Inversion of Control as a design guideline serves the following purposes:

There is a decoupling of the execution of a certain task from implementation.
Every system can focus on what it is designed for.
The systems make no assumptions about what other systems do or should do.
Replacing systems will have no side effect on other systems.

Articles

Martin fowler on Inversion Of Control

Tools

The Art of UNIX Programming

The Art of UNIX Programming , by Eric Steven Raymond

Rule of Modularity: Write simple parts connected by clean interfaces
Rule of Clarity: Clarity is better than cleverness.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines
Rule of Simplicity: Design for simplicity; add complexity only where you must
Rule of Parsimony: Write a big program only when it is clear by demonstration that nothing else will do
Rule of Transparency: Design for visibility to make inspection and debugging easier
Rule of Robustness: Robustness is the child of transparency and simplicity
Rule of Representation: Fold knowledge into data so program logic can be stupid and robust
Rule of Least Surprise: In interface design, always do the least surprising thing
Rule of Silence: When a program has nothing surprising to say, it should say nothing
Rule of Repair: When you must fail, fail noisily and as soon as possible
Rule of Economy: Programmer time is expensive; conserve it in preference to machine time
Rule of Generation: Avoid hand-hacking; write programs to write programs when you can
Rule of Optimization: Prototype before polishing. Get it working before you optimize it
Rule of Diversity: Distrust all claims for “one true way”
Rule of Extensibility: Design for the future, because it will be here sooner than you think

Law of Demeter (Tell don't ask)

You should endeavor to tell objects what you want them to do; do not ask them questions about their state, make a decision, and then tell them what to do..

Don't Repeat Yourself - DRY

Don't Repeat Yourself (DRY) or Duplication is Evil (DIE) is a principle of software development aimed at reducing repetition of information of all kinds, especially useful in multi-tier architectures. The DRY principle is stated as "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system." The principle has been formulated by Andy Hunt and Dave Thomas in their book The Pragmatic Programmer.

Steve Smith on DRY

Command-query separation (CQS)

Command-query separation (CQS) is a principle of imperative computer programming. It was devised by Bertrand Meyer as part of his pioneering work on the Eiffel programming language.

It states that every method should either be a command that performs an action, or a query that returns data to the caller, but not both. In other words, asking a question should not change the answer. More formally, methods should return a value only if they are referentially transparent and hence possess no side effects.

Martin Fowler on Command Query Separation

Design by Contract

Design by Contract (DbC) or Programming by Contract is an approach to designing computer software. It prescribes that software designers should define formal, precise and verifiable interface specifications for software components, which extend the ordinary definition of abstract data types with preconditions, postconditions and invariants. These specifications are referred to as "contracts", in accordance with a conceptual metaphor with the conditions and obligations of business contracts.

Robustness principle

The robustness principle is a general design guideline for software:Be conservative in what you send; be liberal in what you accept.The principle is also known as Postel's Law, after Internet pioneer Jon Postel, who wrote in an early specification of the Transmission Control Protocol that TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.
In other words, code that sends commands or data to other machines (or to other programs on the same machine) should conform completely to the specifications, but code that receives input should accept non-conformant input as long as the meaning is clear.