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

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

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

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

CRC Cards and Conway’s Game of Life

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

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?

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

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

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

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?

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

Good code is easy to understand and reason about

Write code for people NOT computers