¿Qué es el diseño orientado por objetos? ¿De qué se trata? ¿Cuáles son sus beneficios? ¿Cuáles son sus costos?
Parece tonto hacerse estas preguntas ahora que prácticamente todos los programadores usan un lenguaje orientado por objetos. Pero la pregunta
es importante porque, me parece, que la mayoría de nosotros utiliza esos lenguajes sin saber por qué y sin saber cómo sacarle el mayor beneficio posible.

-- Robert C. Martin
http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

DRY!

What's the problem with repetition?

But eliminating repetition is easy, right?!

public GridList(SlingHttpServletRequest request) {
    ValueMap properties = request.getResource().adaptTo(ValueMap.class);
    
    String leftLink = properties.get("leftlink", "");
    String leftTitle = properties.get("lefttitle", "");
    String leftDescription = properties.get("leftdescription", "");                    
    this.leftGridBlock = new GridBlockDialog(leftLink, leftTitle, leftDescription);

    String rightLink = properties.get("rightlink", "");
    String rightTitle = properties.get("righttitle", "");
    String rightDescription = properties.get("rightdescription", "");                    
    this.rightGridBlock = new GridBlockDialog(rightLink, rightTitle, rightDescription);
}

public GridList(SlingHttpServletRequest request) {
  ValueMap properties = request.getResource().adaptTo(ValueMap.class);

  GridBlockDialog[] blocks = new GridBlockDialog[2];
  String[] values = {"left", "right"}; 

  for (int i = 0; i < blocks.length; ++i) {
    String link = properties.get(values[i] + "link", "");
    String title = properties.get(values[i] + "title", "");
    String desc = properties.get(values[i] + "description", "");                    
    blocks[i] = new GridBlockDialog(link, title, description);
  }

  this.leftGridBlock = blocks[0];
  this.rightGridBlock = blocks[1];
}

public GridList(SlingHttpServletRequest request) {
  ValueMap properties = request.getResource().adaptTo(ValueMap.class);

  this.leftGridBlock = new GridBlockDialog(properties, "left");
  this.rightGridBlock = new GridBlockDialog(properties, "right");}

• There is a lot of repetition!
• ... and magic numbers which
  is a related concept!

public static String square(int size) {
   StringBuilder builder = new StringBuilder();
   for (int row = 1; row <= size; ++row) {
      for (int column = 1; column <= size; ++column) {
         builder.append('*');
      }
   }
   return builder.toString(); 
}
public static String pyramid(int size) {   int totalSpaces = (2 * size) - 1;
   int totalCharacters = 1;
   StringBuilder builder = new StringBuilder();   
   for (int row = 1; row <= size; ++size) {
      for (int spaces = 1; spaces <= totalSpaces; ++spaces) {
         builder.append(' ');
      }
      for (int chars = 1; chars <= totalCharacters; ++chars) {
         builder.append('*');
      }
      --totalSpaces;
      totalCharacters += 2;
   }
   return builder.toString();
}

private static final char SPACE = ' ';
private static final char CHARACTER = '*';

private static String makeString(int size, char character) {
   StringBuilder builder = new StringBuilder();
   for (int n = 1; n <= size; ++n) {
      builder.append(character);
   }
   return builder.toString();
}

public static String square(int size) {
   StringBuilder builder = new StringBuilder();
   for (int row = 1; row <= size; ++row) {
      builder.append(String.format("%s%n",makeString(size, CHARACTER)));
   }
   return builder.toString();
}public static String pyramid(int size) {
   int totalSpaces = (2 * size) - 1;
   int totalChar = 1;
   StringBuilder builder = new StringBuilder();   
   for (int row = 1; row <= size; ++size) {
      builder.append(makeString(totalSpaces, SPACE));
      builder.append(String.format("%s%n",makeString(totalChar, CHARACTER)));
      --totalSpaces; totalChar += 2;
   }
   return builder.toString();
}

private static String makeFigure(int size, int spaces, int chars, int modifierSpaces, int modifierChar) {
   
   StringBuilder builder = new StringBuilder();   
   for (int row = 1; row <= size; ++size) {
      builder.append(makeString(spaces, SPACE));
      builder.append(String.format("%s%n",makeString(chars, CHARACTER)));
      totalSpaces += modifierSpaces;
      totalChar += modifierChar;
   }
   return builder.toString();
}

public static String square(int size) {
   return makeFigure(size, 0, size, 0, 0);
}

public static String pyramid(int size) {
   return makeFigure(size, 2 * size - 1, 1, -1, 2);
}

If possible make similar methods call one another. 
In our case we only need to test 
one method instead of two.

Very important with constructors!

Eliminating repetition
helps with

Writing repetition-less code is not easy

SRP

• A class with a single responsibility is easier to re use, so you can use code that is already tested!
• If you need to re use some of the functionality of a class but you find that the other responsibilities are a drag, you will write a new class which breaks DRY!
  

Does this code breaks SRP?

public class Fraction {   private int denominator;
   private int numerator;
   private static int gcf(int a, int b) {
      return b == 0 ? a : gcf(b, a % b);
   }   public Fraction(int numerator, int denominator) {
      final int GCF = gcf(numerator, denominator);
      this.denominator = denominator / GCF;
      this.numerator = numerator / GCF;
   }}

Let's introduce a measure
to help us judge SRP

public class IntStack {
   private int i = 0;
   private int[] stack = new int[10];

   public void push(int n) {
      stack[i++] = n; // has 100% cohesion
   }
   public int pop() {
      return stack[i--]; // has 100% cohesion
   }
   public int size() {
      return i + 1; // has 50% cohesion
   }
}

Cohesion

A collorary

How to avoid it?

Java has quite a few

public class Fraction {   private int numerator;
   private int denominator;   public Fraction(int numerator, int denominator) {
      final int GCF = ArithmeticOperations.gcf(numerator, denominator);
      this.numerator = numerator / GCF;
      this. denominator = denominator / GCF;
   }}

If you have a class with methods with low cohesion try splitting into two classes

What about this code?

public Config {
   public Config(Path filename) throws IOException {
      List<String> content = Files.readAllLines(filename);
      // more code.
   }
   // more code.
}

Is this better?

public Config {
   public class Config(List<String> content) {
      // code.
   }
   // more code.
}

Think about the "moving parts"
and decouple them.

OCP

Benefits

How do you do it?

public void draw(List<Shape> shapes) {
   for(Shape s : shapes) {
      if (s instanceof Circle) {
         // code specific to drawing a Circle
      } else if (s instanceof Square) {
         // code specific to drawing a Square
      }
      // more if statements for other shapes
   }
}

public class Circle extends Shape {
   // code
   public void draw() {
      // code specific to draw a Circle
   }  
}public class Square extends Shape {
   // code
   public void draw() {
      // code specific to draw a Square
   }
}

...

public void draw(List<Shape> shapes) {
   for (Shape s : shapes) {
      s.draw();
   }
}

How to adhere to OCP

There are some design patterns
that can help too

LSP

What's the problem with inheritance?

Favor Composition over Inheritance

public enum Number {
   ACE, TWO, THREE, FOUR, FIVE, SIX, SEVEN, EIGHT, NINE, TEN, J, Q, K;

   public int value() {
      return ordinal() + 1;
   }
}

public enum Suit {
   HEARTS, DIAMONDS, SPADES, CLUBS;
}

public class Card {   private Number number;
   private Suit suit;   public Card(Number number, Suit suit) {
      this.number = number;
      this.suit = suit;
   }   public int value() {
      return number.value(); // Composition + Delegation
   }
}

A more subtle problem with inheritance

public class Ellipsis {   private int a;
   private int b;   public Ellipsis(int a, int b) {
      this.a = a;
      this.b = b;
   }   public void setA(int a) {
      this.a = a;
   }
   public int getA() {
      return a;
   }
   public void setB(int b) {      this.b = b;
   }
   public int getB() {
      return b;
   }}

Now the "easy" part

public class Circle extends Ellipsis {

}

public class Circle extends Ellipsis {
   @Override public void setA(int a) {
      this.a = a;
      this.b = a;
   }
   @Override public void setB(int b) {
      this.b = b;
      this.a = b;
   }
}

public void foo(Ellipsis e) {
   e.setA(10);
   e.setB(5);
   assert e.getA() == 10;
}

...

foo(new Circle());

What went wrong?

The behavior of a Circle object
is not consistent with the behavior
of an Ellipsis object. 

Behaviorally, a Circle is not anEllipsis!
And it's behavior that software
is really all about.

Another example:
java.sql.Timestamp
extends
java.util.Date

It may seem natural
but there are not exactly related:

A Timestamp is related to when something
happened in a local context, where a date
is something that should take into account
different calendars, timezones and offsets!

There may be a lot of reasons for which each class would need to evolve independently of each other!

How to avoid breaking LSP

ISP

Tree Set

What operations are desirable?

So, should we put all
those operations in
a big clunky interface?

interfaces that TreeSet implements:

Big Interfaces would probably
mean that a lot of the implementers
would override some methods
with an empty implementation
breaking SRP!

How to avoid breaking lSP:

DIP

The problem of compilation

What's the problem?

How we decouple code?

Use Interfaces