1. Design Joshua Lewis Project questions Assignment questions
Few small topics
Might start SOLID if time

2. Design Q: What is design to you?
Q: What are we doing when we say we’re ‘designing’?
A - making decisions about trade-offs
-deciding what goes where

3. Object-Oriented Design
Q: What is Object-Orientation about fundamentally?
- State/data opacity
- Responsibilities and roles
A system must fulfil responsibilities.
2 types of generic responsibilities – knowing and doing
Various ways of allocating responsibilities in system
OOD therefore about deciding how to allocate roles and responsibilities among objects
Objects don’t work in isolation
How do we go about allocating these roles and responsibilities?
First technique is the use of CRC Cards

4. CRC Cards Use simple index cards to represent objects Card per object
Card divided up into 3 sections, 1 each for Class, Responsibilities, and Collaborators
Cards easy to move
Emphasizes responsibilities, collaborators and dynamic relationship between classes
Move collaborating classes together to show relationships
Collaboratively brainstorm and design system of interacting objects
Low-investment, lightweight, dynamic, interactive, collaborative
Facilitates communication and shared understanding
Developed by Ward Cunningham and Kent Beck as a teaching tool at OOPSLA 1989

5. CRC Cards and Conway’s Game of Life

7. General design considerations
Q: Hardest thing about software development?
A: Changing requirements
Q: What’s the only guarantee when it comes to software systems?
A: Change
Q: So why are we so bad at it?
- Software often lives longer than we initially expect
Different challenges at different times – startup vs old corporate
Approach should be different, deliberate and explicit

8. Software and change Q: Why so hard to change software?
A: Hard part is understanding code well enough to know where and how code should change
No unintended consequences
Satisfies new requirements
So hard part of s/w dev is understanding and being able to reason about code
Anything we can do make it easier to understand and reason about is a GOOD THING
Q: What makes it hard to understand and reason about code?

9. Obstacles Duplication ‘Clever’ code Complex flow
Too many collaborators
Nested conditionals
Code with ambiguous intent
Bad names
Inconsistencies
Code that does too much
Re-inventing the wheel
Coupling
Discuss, give examples
Coupling – knows too much about how collaborators work
Clever code – optimised for performance or memory space
Names – classes, methods, variables
Why are these obstacles? Why do they cause problems?
- Unintended consequences
- cognitive load – we need to keep too much in our heads at a time
This resource is limited and does get tired

10. Cognitive Load
Q: How do we reduce cognitive load? Ie the number of things we need to maintain in our brains at a time?
A: Abstraction and intention
Intention: we want the intent of the code to be as clear and explicit as possible – structure, names, conditionals
Q: Who are we writing code for?
User
Future developers (often ourselves)
Quote: Write code as if you want future devs to want to buy you a beer after reading it
Make it as easy as possible to read and understand

11. Abstraction Q: What is abstraction? Simplified representation
Lacks detail (hides detail)
Generalised
Why powerful?
Don’t need to know the whole picture – i.e. reduces cognitive load
First-class abstractions:
- abstract classes
- interface types
Generics
Names : class, method, variable

12. Names Q: What should a variable name tell you?
Q: What should a method name tell you?
Q: What should a class name tell you?
A: As much as possible from as little effort as possible
E.g: which is clearer: CustomerRepository or FindCustomersByLocationQuery?
SmsService or SmsSender?
What are the responsibilities of SmsService?
What are the responsibilities of SmsSender?
Which is more expressive?
Which shows more empathy for the user?
Which describes its responsibilities better?

13. Other techniques Small methods Small classes Minimal scope Pairing
Minimal state
TDD
No nesting
Patterns
Consistent format/style
Early returns

14. Good code is easy to understand and reason about

15. Write code for people NOT computers