[OO Design Foundation] Object Oriented Modeling 2

Design Principle

1. Coupling and Cohesion

• are the metrics used to evaluate design complexity
  • Coupling focuses on complexities between a module and other modules
  • Cohesion focuses on complexities within a module
• Help better apply object-oriented design principles achieve more managable system
  • Think of badly designed system like a puzzle
    • You can only connect specific puzzle to another puzzle
  • Think of well-designed system like a lego block
    • You can connect any two blocks without much trouble
    • All modules are compatible with one another
    • This is what you should strive to make
• A module is tightly coupled if it is highly reliant on other modules
  • Like puzzles

• A module is loosely coupled if it is easy to connect to other modules
  • Like lego
  • This is what you should strive to make

Coupling

• when evaluating coupling of a module, the following is considered:
  • 1. Degree
    • Is number of connections between the module and others
    • is needed to be kept small
    • Example
      • 1. connecting a module to other modules through a few parameters or narrow interface
  • 2. Ease
    • Is how obvious are the connections between module and others
    • Is needed (as much as possible) to have its connections easy to make without needing to understand the implementation of other modules
  • 3. Complexity
    • is how interchangable other modules are for this module
    • you want other modules easily replacable for something better in the future

Cohesion

• considers complexity within a module
• represents the clarity of a responsibilities of a module
• A module is
  • highly cohesive if your module performs one task and nothing else, or has a clear purpose
  • lowly cohesive if your module tries to encapsulate more than one purpose, or has an unclear purpose

 

Example

• The following has low cohesion because it has two purposes and it's unclear

• The following example is highly cohesive and loosely coupled

 

2. Separation of Concerns

• Is a key idea that applies throughout object oriented programming
• is an ongoing process throughout the design process
• Creates more cohesive classes using abstraction, encapsulation, decomposition and generalization

Definition

• A concern is a very general notion, basically saying it is anything that matters in providing a solution to a problem

 

Steps

 

Sepration of Concern Starting Example - a SmartPhone

• There is low cohesion in above class
  • There are behaviors not related to each other
  • The camera behaviors do not need to be encapsulated with the behaviors of the phone in order for the camera to do its job
• The above class has low modularity
  • We cannot access the camera or the phone separately if we are to build another system only one or the other
  • We cannot replace current camera with different camera, or replace it completely with a different object

 

• 1. Analyze a class's concern

• 2. Separate them out into their own more cohesive classes and encapsulate all the details about each into functionally distinct and independent classes

• 3. Redesign code

3. Information Hiding

• allows models of our system to give others the minimum amount of information needed to use them correctly and hide everything else
• is often associated with encapsulation
• allows you to build flexible, reusable, and maintainable systems
• JAVA has four levels of acess:
  • 1. Public
    • Accessible by any classes (methods and variables)
    • Does not allow other classes to change the implementation of the behavior for the method
  • 2. Protected
    • are only available to
      • a. encapsulating class itself
      • b. it's subclasses
      • c. classes within the same package (a mean which JAVA uses to organize multiple classes into a single name space)
        
        
  • 3. Default
    • Only allows access to attributes and methods to subclasses and to the encapsulating class
    • Is also called no modifier access because explicit declaration is not needed
      
      
  • 4. Private
    • are not accessible by any classes other than the encapsulating class itself
    • cannot access attributes directly, and cannot invoke methods by other classes

4. Conceptual Integrity

• Is about creating consistent software as if it's written by a single person
  • Is not about quashing people's opinion but about everyone agreeing to use certain design principles and conventions
• Is a very important principle, and one that will help you to create consistent and well designed software.
• has multiple ways to have it achieved:
  • 1. Communication
    • i.e. Daily standup meetings, sprint retrospectives (agreeing to use certain libraries, and methods)
  • 2. Code Reviews
  • 3. Having a well-defined design, or architecture underlying your software
    • Guides how your software is organized
  • 4. Unifying Concepts
  • 5. Having a Small Core Groups that accepts commits to the code base
    • Ensures that any software changes follow the overal architectural design of your software
• Is most important considerations in system design

Generalization Principles

1.  Inheritance Issues

Good Generalization

• Is that:
  • It's subclass has more functionality than the superclass.

  • It's subclasses provide and share attributes and behaviors from the same superclass, but each subclass has their own distinct functions.

Misusing inheritance

• Can lead to poort codes
• Happens when design principles are used improperly
• Is detected by the following:
  • 1. Ask question "Am I simply using inheritance to simply share attributes or behaviors without further adding anything special in my subclasses?"
    • If yes, you are misusing inheritance
    • Here, superclass is already enough
    • Example
    • 1. Pizzas at a pizza shop
      • Say class for each pizza is constructed (Pepperoni, Hawaiian, ...)
      • And a superclass is created with sharing attributes and methods
        
        
        
      • Note that Pepperoni Pizza is not really different from subclass
      • There is no reason to use inheritance in this case
        • you can use Pizza class with pepperoni as its toppings
  • 2. Check if Liskov Substitution Principle is broken
    • States that "subclass can replace a superclass, if and only if, the subclass does not change the functionality of a superclass"
      • In layman's term "if we substitute a superclass object reference with an object of any of its subclasses, the program should not break"
    • Example
      • 1. Animal and Whale
        
        
        
        
        • Whale breaks Liskov Substitution Principle because it's run and swim method overrides the animal's class's running and walking methods and replaces it with swimming behavior

 

Using Decomposition

• If a class is misued and inheritance does not suit your need, consider decomposition
  • Example
    • 1. Smart phone
      • is a good example where decomposition works better than inheritance
      • doesn't make sense to inherit from phone
        
        
        (not a good example)
        
        (a good example)

 

 

References

- Object-Oriented Design, University of Alberta: https://www.coursera.org/learn/object-oriented-design

객체 지향 설계

- The Liskov Substitution Principle Explained, reflectoring.io: https://reflectoring.io/lsp-explained/