Using the SOLID design principles to write code that's easier to understand, maintain and extend.
The slides from the SOLID speech at the CodeTalks 2018 in Hamburg.
2. Katerina
Trajchevska
● Senior Software Engineer & co-
founder of Adeva
● Remote Work Advocate
● Community Volunteer
● Consultant with startups and
Fortune 500 companies
Software Engineer and co-
founder of Adeva
3. @ktrajchevska
The state of software development
💰 Cutting costs by sacrificing good software architecture.
🧐 Spending more time reading than writing code.
😱 Continuing someone else’s work can be dreadful.
🧐 Going back to your own code a year later can be puzzling.
4. @ktrajchevska
SOLID Design Principles
● Encourage writing code that is:
○ Easier to read and understand
○ Easier to maintain
○ Easier to extend
● Introduced by Robert Martin (Uncle Bob), named by Michael Feathers.
7. @ktrajchevska
Single Responsibility Principle
● A class should only do one thing.
● Find one responsibility and move everything else out of the class.
● Very precise names for many small classes > generic names for large classes.
14. @ktrajchevska
Open/Closed Principle
● Extend functionality by adding new code instead of changing existing one.
● Easily extend the system; never break it.
● Example: Open Source library
15.
16.
17.
18.
19.
20.
21.
22. Liskov Substitution Principle
Let φ(x) be a property provable about objects x of type T.
Then φ(y) should be true for objects y of type S where S is
a subtype of T.
23.
24. @ktrajchevska
Liskov Substitution Principle
● Any class should be able to substitute its parent class without breaking the
program.
● Every class that implements an interface, must be able to substitute any other
class that implements the same interface without breaking the program.
● Every part of the code should get the expected result.
35. @ktrajchevska
Interface Segregation Principle
● A client should never be forced to depend on methods it doesn't use.
● Changing one method in a class shouldn’t affect classes that don’t depend on
it.
● Replace a large interface with many small, specific interfaces.
41. @ktrajchevska
Dependency Inversion Principle
● Never depend on anything concrete, only depend on abstractions.
● High level modules should not depend directly on low level modules.
● Able to change an implementation easily without altering the high level code.
42.
43.
44.
45.
46.
47. @ktrajchevska
The results of SOLID
💰 Cutting costs by implementing good software architecture.
🧐 Spending more time writing than reading code.
🧐 Continuing someone else’s work can be a joy.
😎 Going back to your own code a year later like a boss.
48. @ktrajchevska
⚠️ Words of caution
● SOLID design principles are principles, not rules.
● Know your trade-offs and use common sense when applying SOLID.
● Avoid over-fragmenting your code.
● Don’t try to achieve SOLID, use SOLID to achieve better developer experience.
49.
50. @ktrajchevska
Final Thoughts
● SOLID helps you achieve code that’s easy to maintain, extend and understand.
● Spend more time writing and less time reading code.
● Always know your trade-offs and use common sense.
Did you ever had to go back to a code you wrote a year ago and weren’t able to understand what you were doing?
Make it easier to quickly extend the system with new functionality without breaking the existing ones.
Spend less time figuring out what it does and more time actually developing the solution.
This controller method has 3 different responsibilities.
The method has only one responsibility now: control the flow of the program.
Goal: get to a point where you can never break the core of your system.