methods and principles for System Design

1. System Design
Naveen Muguda

2. notation
• f1, f2 => properties
• m1, m2 => methods
• X,Y,Z => modules
• a, b, c => responsibilities

3. • ER diagram
• design the database tables
• strap a front end/API in front
• voodoo/tribal knowledge
how design happens

4. • designed by asking:
• What (structure) does this module represent?
• what can X do?
Data-driven design

5. how to do this worse
• map relations to classes

6. information hiding
• private f1;
• private A m1();
• public A m2(){….};

7. encapsulation
• (a & b) => (a) + (b)
• A{m1(){..}, m2(){..}} =>
A{m1(){..}}, B extends A{m2(){..}}
• m1(){..} =>
m1(){m2(); m3();} ;m2(){..}, m3(){..}

8. encapsulation != information hiding

9. • identifying and assigning responsibilities
• who should do a?
Responsibility Driven
Design

10. Responsibility
• “contract/obligation/expectation from a module”
• knowing/doing

11. ..at every level
• provide transport from DH to customer
• create runsheet
• manage payment
• write to data store
• handle rollback

12. process
• identify roles, invent modules, shift responsibilities
• design and redesign the community
• till we reach executable code

13. process
• exploratory
• iterative

14. roles
• to be useful objects need to play roles
• set of related responsibilities

15. role stereotypes
• to help focus on responsibilities
• “controller” “coordinator” “service provider”
“bridge” “manager” “money handler”

17. collaborations
• don’t exist in isolation
• collaborates with others
• fulfils some responsibilities by module(a by me)
• works with other modules for others (b by X)

19. Responsibility Driven Design
• play specific roles in the system architecture.
• is responsible for specific portions of the work.
• Objects collaborate in clearly-defined ways, to
fulfil the larger goals.
• in a smoothly-running community of objects.

20. 101 principles
• High Cohesion
• Low Coupling

22. separation of concerns
• modules should be exclusive, no overlap of
functionality
• don’t share responsibilities

23. Single
“Responsibility”Principle
• A class/module should have only one reason to
change.

24. Open/closed principle
• modules should be open for extension, but closed
for modification
• avoid bloated classes, inherit/refactor

25. Dependency Inversion

26. Don’t Repeat yourself
• “Every piece of knowledge must have a single,
unambiguous, authoritative representation within a
system.”
• avoid creating duplicate clients and definitions
for entities in services

27. law of parsimony
• prefer designs with fewer assumptions
• simpler,elegant

31. refactoring
• reassign responsibilities

32. domain driven design
• developers speak the same language as users