Object Oriented Concepts
Object Oriented fundamentals
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:
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
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
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.
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.