POODR by Sandy Metz. Chapter 1 Object Oriented Design

Aug 10, 2017

Reading time: 4 minutes

#POODR #Sandy #Metz #chapter1 #object #oriented #design #Ruby #SOLID #DRY

This chapter contains an overview of Object Oriented Design (OOD) and define common terms.

What is OOD?

OOD in an application are the parts that interact to produc the behavior of the whole system (managing dependencies).

The change is harder when there is not such a OOD because, changing one object forces to change much more and then can cause a huge damage.

 

Practical definition of Design

The prupose of design is, to allow you to design later and its primary goal is to reduce the cost of change.

"Agile Software requires design and a really good one, even the best. Because the succes relies on simple flexible and malleable code"

 

About Object Oriented Programming (OOP)

Object Oriented Language(OOL) vs Procedural Language.

In procedural languages, data is different than behaviour. Data package up the variables and passed to the behavior.

in OOL data plus behavior are one object.

In OOL:

Class is a blueprint (or manual of instructions), inside, methods are the definition of behavior and the attributes, the definition of variables.

"OOL are open-ended* and does not limit a small set. This can bring pleasure or pain, it's matter of design and the concern about this book."

*(See SOLID principles below)

SOLID (object-oriented design)

Represents five of the most well know principles of object-oriented design:

S ingle Responsibility : A class should have a single responsibility  *(ex: one potential change  in specification should be able to affect the class specification) 

O pen-Closed : Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification *(ex: such an entity can allow its behaviour to be extended without modifying its source code.)

iskov Substitution : If S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e. an object of type T may be substituted with any object of a subtype S) without altering any of the desirable properties of T (correctness, task performed, etc.).

nterface Segregation : (ISP) states that no client should be forced to depend on methods it does not use.

ependency Inversion : 
  A. High-level modules should not depend on low-level modules. Both should depend on abstractions.

  B. Abstractions should not depend on details. Details should depend on abstractions.

 

Summary

Applications that live long enough have the problemof dealing with change, the eficiency is matter of design principles and patterns, but is not enough condition to guarantee an easy to change application, because of uncertain future.

The trick: Understand the theories of design and apply them well on the right time and in the right amounts, transforming this theory into practic and specially practicing more and more to get in the end to a real world full of change and uncerainity .

<<