Object Oriented Concepts

Object Oriented fundamentals




Open recursion


Aggregation (has), composition (is part of)

Low coupling, high cohesion

Component: Class, module...

Object Oriented Design Principles

What are them?

Principles (hints, guide lines) that are intended to guide OO software design.

Why are useful?

The software designed following these principles will be more reliable and easy to maintain, because it will be:

  1. Adaptable: Easy to change according to new requirements. -- Not rigid
  2. Solid: Each component will do its job, changes in one component should not affect other components i.e., might affect the application as a whole but not individual components. -- Not fragile
  3. Reusable: Components inside the application will be re-usable. -- Not immobile
  4. Structured: Each component have a well defined responsibility, e.g., when a change is needed there a single and specific place to do it. -- Not viscous

Which are them?


Single Responsibility: Each class should offer a series of closely related functionality through its methods. Cohesion.

Open-Closed: Open for extension, closed for modification. Component’s functionality can be changed without changing its code. Abstraction

Liskov Substitution: Subclasses should be substitutable for their base classes; references to Interfaces (or base classes) should be able to use implementers (or subclasses) of the interface. Polymorphism

Interface segregation principle: many client-specific interfaces are better than one general-purpose interface.

Dependency Inversion (Inversion of Control): Concrete classes (or implementations) should depend on interfaces [and not vice versa]  i.e., Details depend on abstractions, abstractions should not depend on details; clearly defined layers. Abstraction

Design Principles and Design Patterns, Robert Martin

Object Oriented Design Principles, Javier Navarro


API Design

When declaring interfaces keep in mind:

When implementing interfaces

It is very easy to create a bad API and rather difficult to create a good one. Even minor and quite innocent design flaws have a tendency to get magnified out of all proportion because APIs are provided once, but are called many times.

How To Design A Good API and Why it Matters, Joshua Bloch

API Design Matters, Michi Henning

Exception handling

From Chapter 7 Error Handling of the book Clean Code

Use Exceptions Rather Than Return Codes

Use Unchecked Exceptions

The debate is over. For years Java programmers have debated over the benefits and liabili- ties of checked exceptions. When checked exceptions were introduced in the first version of Java, they seemed like a great idea. The signature of every method would list all of the exceptions that it could pass to its caller. Moreover, these exceptions were part of the type of the method. Your code literally wouldn’t compile if the signature didn’t match what your code could do.

At the time, we thought that checked exceptions were a great idea; and yes, they can yield some benefit. However, it is clear now that they aren’t necessary for the production of robust software. C# doesn’t have checked exceptions, and despite valiant attempts, C++ doesn’t either. Neither do Python or Ruby. Yet it is possible to write robust software in all of these languages. Because that is the case, we have to decide—really—whether checked exceptions are worth their price.

Define Exception Classes in Terms of a Caller’s Needs 107

What price? The price of checked exceptions is an Open/Closed Principle violation.


Checked exceptions can sometimes be useful if you are writing a critical library: You must catch them. But in general application development the dependency costs outweigh the benefits.

Provide Context with Exceptions

Define Exception Classes in Terms of a Caller’s Needs


I haven't noticed any lower quality of exception handling since I switched to unchecked exceptions.

  -Jakob Jenkov in Java Exception Handling [Kindle Edition]



At its heart, it was the simple idea that Model classes should be responsible for representing the state of your application, View classes should be responsible for drawing your user interfaces and presenting that state to your users, and Controller classes should be for translating actions performed by your user into changes to your model, that were then reflected in your view.


Robustness principle

Is a general design guideline for software:

Be conservative in what you do, be liberal in what you accept from others (often reworded as "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.

Among programmers, to produce compatible functions, the principle is popularized in the form be contravariant in the input type and covariant in the output type.