OO Design Principles

1
OO Design Principles

• CS2340
• Spring 2003

2
The Age Old Argument

• Engineering versus Art Form
• Design defining something in specific enough
  terms so it can be built (implemented).
• Want to fill all functions while meeting as many
  constraints as possible.
• For software, our constraints are typically
  non-functional or quality concerns
• Performance, Reliability, Maintainability, etc.
• We want to engineer the illusion of simplicity

3
Important OO concepts

• Abstraction Cope with complexity
• Hierarchy ranking of abstractions
• Encapsulation Hiding details of objects
• Modularity Decompose into cohesive, loosely
  coupled modules
• Class identification and Module identification
  are independent activities!!!!
• Typing enforcement of class of object
• Concurrency Active vs. Inactive objects

Grady Booch
4
Fundamental Design Principles

• Information Hiding hide the implementation of
  data structures behind a standard interface.
• Low Coupling How much does one element rely on,
  or is connected to another.
• Low dependency, Low change impact, increase reuse
• Guides Collaborations
• High Cohesion How strongly related are the
  responsibilities of a class?
• Guides Responsibilities

5
Single Responsibility Principle

• There should only be one reason for a class to
  change.
• Multiple responsibilities increased coupling,
  lower cohesion
• Sometimes this can be hidden. Consider a modem
  class with operations dial, hangup, send,
  receive.
• Connection Management and Data Communication
• Separate into interfaces that are implemented by
  a modem class.

Martin Fowler
6
Open-Closed Principle

• Designs should be open for extension, but closed
  for modification.
• Simplistically, we can use inheritance.
• In general, we use interfaces and take advantage
  of polymorphism.

Robert Martin
7
Open-Closed Example
Robert Martin
8
Liskov Substitution Principle

• Subclasses should be substitutable for their base
  class.
• A user of a base class should continue to
  function properly if a derivative of the base
  class is passed to it.
• Compliance can be subtle
• The square-rectangle (or circle/ellipse) dilemma.
• Classes must honor the superclass contract.
• Contract pre and post conditions of messages

Barabara Liskov and Robert Martin
9
Dependency Inversion Principle

• Depend upon abstractions, not concrete
  implementations
• Dependencies should target an interface, not an
  implementation.
• There are exceptions of course (standard
  libraries like string.h)

Robert Martin
10
Dependency Inversion Example
Application
Windows GUI
Linux GUI
11
Interface Segregation Principle

• Several client-specific interfaces are better
  than one general-purpose interface.
• If sets of clients only use subsets of services,
  then separate those services into multiple
  interfaces.
• Reduces recompilation requirements of clients
  when services change.

12
Interface Separation Example
Chat Client
Game Server
Game Client
Observer Client
13
How do I group stuff together? (into categories,
packages, modules)

• Reuse Release (Classes that are reused
  together go together)
• Change Release (Classes that change together
  go together) Coupling-based
• No reuse No Release (Classes that are not
  reused together do not go together)
• Base functionality (Classes with similar services
  go together)
• Work Breakdown (Classes maintained by same person
  go together) least desirable

14
Delegation vs. Inheritance

• Many times there is an overuse of inheritance.
• Subclass explosion problem
• Difference between kindOf, isA, isARoleOf
• Joe-the-Box gt Pen
• Collections gt Portfolios

15
Conclusions

• Realizing many of these principles are a
  foundation for design patterns.
• These are principlesnot laws.
• Some art is involved in getting a good design
  as well as engineering.
• Design is often a compromise between different
  principles.
• There is no one right design but there are
  certainly bad ones.