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.

1. Katerina Trajchevska
From Good to SOLID
Architecture

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.

5. Single Responsibility
Principle
A class should have one, and only one, reason to change.

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.

8. 1
2
3

12. Open/Closed Principle
An entity should be open for extension, but closed for
modification.

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

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.

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.

25. Returns
IlluminateSupportCollection

27. Returns array

29. Returns
IlluminateSupportCollection

33. Interface Segregation
Principle
No client should be forced to depend on methods it does
not use.

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.

36. IlluminateDatabase
EloquentModel: 1600+
lines of code

39. Dependency Inversion
Principle
High-level modules should not depend on low-level
modules. Both should depend on abstractions.

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.

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.

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.

51. SOLID is your tool, not your goal.

52. Thank you 🙏
@ktrajchevska
Connecting tech companies with world-class developers