The document outlines key architectural principles and software design patterns, focusing on concepts such as code reuse, the DRY principle, and the NIH syndrome. It contrasts the cathedral and bazaar models of software development, emphasizing the benefits of open-source collaboration and simplicity in design. The GRASP (General Responsibility Assignment Software Patterns) principles provide guidance on effectively assigning responsibilities within software classes to achieve low coupling and high cohesion.

1. Lecture 14
GRASP

2. Agenda
 Architectural Principles
 GRASP

3. Reading
 Barbin 2, 4

4. ARCHITECTURAL PRINCIPLES

5. Code Reuse
 Use of existing software to build new software
 Examples:
– Libraries, previous version, inheritance, composition,
cut-paste programming, code generators, and
frameworks
 Opposite
– Reinventing the Wheel or Reinventing the Square
Wheel

6. DRY – Don’t Repeat Yourself
 Aimed at reducing duplicate information,
process and behavior
– Can apply to code, databases, documentations,
builds, tests
 Achieved by
– Automating repetitive tasks, data transformation, code
generators, scripting

7. NIH – Not Invented Here
 Syndrome where people don’t want to use
existing code but prefer to writing their own in-house
code
– Fear of unknown, distrust, turf war, nationalism,
protectionism
 Opposite
– Proudly found elsewhere (PFE) where use of other
code, open source, is encouraged

8. Cathedral and the Bazaar (CatB)
 Software models
– In the Cathedral model, the source code is protected
and seen by only exclusive limited group of devs
– In the Bazaar model, the source is open to everyone

9. Cathedral and the Bazaar (CatB)
 Software models
– The Cathedral model creates proprietary assets that
can be monetized
– The Bazaar model finds more bugs faster and is
central to the open source community
– Monetization of Bazaar code must be done with
services or something else that selling code

10. POGE – Principles of Good
Enough
 Quick and simple solution is favored over
complex and elaborate
– The software is evolved and driven by end user
requirements
– Central to the Agile development

11. Worse is Better
 Less (worse) functionality is preferable (better)
 Quick and simple solution is favored over
complex and elaborate
– The software is evolved and driven by end user
requirements
– Central to the Agile development
 Examples
– Unix, C

12. Worse is Better
 Simplicity
– The design must be simple, both in implementation
and interface
 Correctness
– The design must be correct in all observable aspects
 Consistency
– The design must not be overly inconsistent.
 Completeness
– The design must cover as many important situations
as is practical

13. GRASP

14. GRASP
 General Responsibility Assignment Software
Patterns
– Note: pattern is not referring to Design Pattern
 Set of principles that will guide you on how to
assign responsibility to classes
– Responsibility is data (knowing) and process (doing)
 Answers: “Where to put the Code?”
 Who takes care of what?

15. GRASP
1. Creator
2. Controller
3. Information Expert
4. Low Coupling
5. High Cohesion
6. Indirection
7. Pure Fabrication
8. Polymorphism
9. Protected Variations

16. Creator
 Creator has the responsibility of creating an
object
– Who should create objects?
– Creating object creates dependency
A should create B if A has intimate knowledge of B
A contains B and knows how to initialize B
Factory classes know how to create

17. Controller
 The overall coordinator of system operations
Receiving client requests and delegating them to other
objects to fulfill the request
Controllers are the classes that handle exceptions
Model-View-Controller, Process

18. Information Expert
 The class that has the information necessary to
fulfill responsibility
Example: Employee class that knows how to get and
set its own information

19. Low Coupling
 Assign responsibility to classes so that coupling
is low
– They have less dependency on each other
– Dependency injections
– Coupling between
different modules

20. High Cohesion
 Assign related responsibility to classes so that
they form a highly-cohesive and functional unit
– Cohesion within a module

21. Indirection
 Assign responsibility to an intermediate object
to facilitate communication between two objects
to avoid direct coupling
Example: mapper, adaptors, data exchange XML – Json

22. Polymorphism
 Assign responsibility of defining variations of
behaviors to different classes
Example: class Payment with subclasses
PaymentByCreditCard, PaymentByDebitCard etc

23. Protected Variations (PV)
 Identify variations and evolution points, then
assign their responsibilities to stable interfaces
– The implementation can then be written and modified
without affecting existing clients
Open-Closed Principle
Program to Interfaces not implementation
Separate what varies

24. Pure Fabrication
 Assign responsibility to artificial or convenience
objects to abstract operation
Example: loggers

25. Summary
 Architectural Principles
– DRY, NIH, CatB, POGE, Worse is Better
 General Responsibility Assignment Software
Patterns