cs2340: Design Principles

1
cs2340 Design Principles

• Summer 2007

Many of these principles come from Robert Martin
or the NASA design guidelines for OO design.
2
Remember

• These are principles, not hard and fast rules
• You will not be punished if you have a valid
  reason to deviate
• Dont do stupid stuff just because its in the
  rule
• Red lines are for normal operation only

3
Things to Avoid

• High Coupling
• Low Cohesion
• Rigidity
• Fragility
• Immobility

4
Single Responsibility Principle

• Each class should have a single overriding
  responsibility (High Cohesion)
• Each class has one reason why it should change

5
Law of Demeter

• An Object only sends messages to
• Itself (its own instance methods)
• Objects sent as arguments to message m
• Objects created as part of reaction to m
• Objects directly accessible via attributes

Purpose Reduce coupling
6
Law of Demeter (UGA Version)

• I can play by myself
• I can play with toys given to me
• I can play toys I made myself
• I can play with my own toys (but not take them
  apart)

7
Examples

• screen add button.
• screen panel addbutton.
• process aString
• aString size.
• process aUser
• aUser connection send message.

8
Examples

• b User new.
• b name.
• b connection send aMessage.
• myConnection send aMessage
• myConnection socket send aMessage.

9
Open Closed

• Objects are open for extension but closed for
  modification.

Extension via inheritance, polymorphism.
Related design patterns Template, State, Strategy
10
Example

• computePay aCategory
• aCategory salaried ifTrueself computeS
• aCategory hourly ifTrueself computeH
  hours
• aCategory bonus ifTrueself computeB amt
  
• aCategory volunteer ifTrue self computeV

11
Liskov Substitution Property
What is wanted is something like the following
substitution property If for each object o1 of
type S there is an object o2 of type T such that
for all programs P defined in terms of T, the
behavior of P is unchanged when o1 is substituted
for o2, then S is a subtype of T.
Liskov88 Subclasses should be substitutable
for their base classes. Consider behavior, not
just is a Square/rectangle problem
12
Dependency Inversion Principle

• Depend on abstractions, not concretions
• Program to interfaces not implementations
• Program to most abstract class possible
• ArrayListltintgt list new ArrayListltintgt()
• Listltintgt list new Listltintgt()
• Collectionltintgt coll new Collectionltintgt()

13
Interface Segregation Principle

• Dont make large multipurpose interfaces
  instead use several small focused ones.
• Dont make clients depend on interfaces they
  dont use.
• Class should depend on each other through the
  smallest possible interface.

14
Abstract Class vs. Interface

• Sometimes a wash
• Sometimes a critical decision

15
Class vs. Attribute

• Avoid primitive obsession
• Make classes when it makes sense based on reuse
  and functionality

16
Packaging/Deployment Principles

• ReleaseReuse
• MaintenanceIsolated Changes
• Inverse Reuse
• Share same function/goal

17
Acyclic Dependency

• Do not have cyclic dependencies in your packages
• Decomposition into independent modules

18
Design Metrics

• Instability measure The more concrete the more
  unstable the class is.
• Depend on most stable classes
• Ci incoming dependencies (packages that depend
  on me)
• Co outgoing dependencies (packages that I
  depend on)
• Instability Co / (Co Ci)

19
Design Metrics

• Stable classes are abstract classes
• Na Number of abstract classes
• Nc Number of total classes
• Abstractness Na / Nc

20
Design Metrics

• So how good is my package?

Distance A I 1 Closer to zero,
better the design
21
Design Metrics

• Class Size
• Methods per class
• Lack of Cohesion (count of methods with
  dissimilar purpose)
• Coupling Between Classes (count of other classes
  that this class refers to)
• Depth of Inheritance Tree
• Method Complexity