Notes from Sandi Metz “Introduction to Practical Object-Oriented”
- Object-oriented design (OOD) is about managing dependencies
- Objects shouldn’t know too much about each other
- Design is an art of arranging code
- Write code for the feature you’re developing today, but also changeable in the future
- You can’t predict what changes will be needed in your code, merely that change will occur
- Tools for a OOD ➡️ principles and patterns
- [S]ingle responsibility
- [L]iskov substitution
- [I]nterface segregation
- [D]ependency inversion
- We can look to quantify “good code”
- Name common problem and solve the problems in common ways
- Patterns are like a tool, it’s the user who must master the pattern/tool
Act of Design
- “Programmer’s past experience does not predict the future”
- This especially hits home for me as I’m learning. I can be afraid of past failures defining me.
How Design fails
- When a program is easy to create, but changes become gradually impossible
- When design is separated from the act of programming
- Design relies on the feedback loop
- Think agile software development
When to design
- Agile works because it acknowledges certainty is unattainable in advance
- Agile is an example where OOD is required, because of the way you’re iteratively implementing code
- What’s the thing that separates a novice and senior programmer?
- Lines of code written?
- How frequently they are deploying?
- How much design depends on two things:
- Your skills and timeframe
- Think of good design like good investing, don’t turn down compounding interest
Brief intro to Object-Oriented programming
- Applications are made up of objects and messages that pass between them