Object-oriented design principles

Question 1

The law of Demeter

Answer 1

Avoid as much as possible long chains of message calls

• Solution
  
  • Intermediate classes
    
    • should be “deeper” and provide complete services
    • should not return references to their internal structure
  • More concretely, the code of a method should access only:
    
    • The instance variables of this
    • The arguments of the method
    • Any new object created within the method
    • (If unavoidable) globally available objects

Question 2

The interface segregation principle (ISP)

Answer 2

• Client code should not be forced to depend on interfaces it does not need
• How?
  
  • Define specialized interfaces that specify a small and coherent slice of behavior that clients can depend on
  • Clients depend on interfaces that represent specific roles directly relevant to each client
• Whenever you add an association/aggregation between two classes;
  
  • Direct reference, if the client class needs the whole interface of the associated class
  • Segregated interface, if the client depends only on a role that objects of the associated class will fullfil

Question 3

ISP trade off

Answer 3

if you notice that you are using two or more
segregated interfaces always together, it is time to merge
them back into a single interface

Question 4

The Comparable interface

Answer 4

• It is a specific instance of the ISP
• It provides a single method
• Collections class = check it when you need to manipulate lists of elements (e.g., sorting, shuffling, etc.)
• PROBLEM = the developer of Collections cannot anticipate all the possible types of objects being managed by the class!
• Now the sort() method of Collections can sort objects
  independently of their nature, as long as they are comparablewith each other
  The sort() method simply depends on the minimum possible set of behaviour required by objects to be sortable: comparison
• function objects
  
  • Rule of thumb: comparator classes as nested classes of the class being compared (better cohesion)

Question 5

Objects identity

Answer 5

• The identity of an object distinguishes one object from another
• It is useful to think of an object’s identity as the place where its value is stored in memory

Question 6

Objects equality

Answer 6

• Equality refers to the fact that two distinct objects are semantically the same
• In general, equality between two objects must be defined by the programmer
  
  • Attribute values may be technically different, but semantically the same
  • Trivial example = you may consider as “equal”, strings with the same characters independently of their capitalization
  • You implement your own equality check by overriding the equals(Object)method of Object In Java, the root of the hierarchy class is Object

Question 7

Objects uniqueness

Answer 7

• Objects of a class are unique if it is not possible for two distinct objects to be equal
  
  • E.g., what is the meaning of having two Cards with the same rank and suit?
• How to have unique objects?
  
  • One object → Singleton design pattern
  • Multiple objects → Flyweight design pattern

Question 8

The Liskov substitution principle

Answer 8

• If S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program B
• It is a way of ensuring that inheritance is used correctly
• When you develop the client code of a class T, you are making implicit assumptions about how T’s methods work
  
  • those assumptions must also hold for all subclasses S of T, otherwise you risk to break all the client code using T

Question 9

The Liskov substitution principle in OO programming

Answer 9

• Inheritance should only be used to extend the behaviour of a superclass
• It is bad design to use inheritance
  
  • a. to restrict the behaviour of a superclass
  • b. when the subclass is not a proper subtype of its superclass

Question 10

Methods of a subclass (according to Liskov)

Answer 10

• cannot have stricter preconditions
• cannot have less strict post-conditions
• cannot take more specific types as parameters
• cannot make overridden methods less accessible (e.g. public -> protected)
• cannot throw more checked exceptions
• cannot have a less-specific return type