SOLID Programming with Ruby example

1. SOLID PRINCIPLES
with Ruby examples
By Nhan Nguyen (nhanntit)

2. ROBERT C. MARTIN
“Clean code is not written by
following a set of rules. You
don’t become a software
craftsman by learning a list
of heuristics. Professionalism
and craftsmanship come
from values that drive
disciplines.”
Clean Code: A Handbook of Agile
Software Craftsmanship

3. By following SOLID design
principles, developers can achieve
a maintainable and extendable
codebase
CONTENT

4. SINGLE RESPONSIBILITY
PRINCIPLE
A class should have a single
responsibility.
 A class’s responsibility isn’t always
immediately clear.
 Any complicated classes should be divided
into smaller classes that are each
responsible for a particular behaviour,
making it easier to understand and maintain
your codebase.
 The goal of the SR principle is to fight
complexity that creeps in while you’re
developing an application’s logic.

5. CHECK AN EXAMPLE
Any violation SRP?

6. VIOLATIONS
1. Handling two tasks:
generate_report!, send_report
2. May be problematic in
expanding in the future: have
to change the logic of the class

7. REFACTORED
1. Separate classes
2. Changing the logic of the class
without touching the remaining
class

8. OPEN-CLOSED PRINCIPLE
Modules, classes, methods and
other application entities should be
open for extension but closed for
modification.
 The codebase of software projects is often
modified throughout their lifetimes.
Therefore, a developer’s goal should be to
build a flexible system that is easy to modify
and extend.
 All modules, classes, methods, etc. should
be designed in a modular way, so that we
are able to change the behavior of the
system without changing the source code.

9. CHECK AN EXAMPLE
Any violation OCP?

10. VIOLATIONS
1. We’ll have to modify the logger
every time we need to add
additional senders or formatters

11. REFACTORED
1. Segregated senders and formatters to
separate classes
2. Enabled the addition of new senders and
formatters without having to modify the base
code

12. LISKOV SUBSTITUTION
PRINCIPLE
Subclasses should add to a base
class’s behaviour, not replace it.
 The principle states that parent instances
should be replaceable with one of their
child instances without creating any
unexpected or incorrect behavior.
 LSP ensures that abstractions are correct,
and helps developers achieve more
reusable code and better organize class
hierarchies

13. CHECK AN EXAMPLE
Any violation LSP?

14. VIOLATIONS
1. The child class violates the LSP
principle since it completely
redefines the base class by
returning a string with filtered
data, whereas the base class
returns an array of posts.

15. REFACTORED
1. Segregated the filtration logic
and the statistics string
generation logic into two
methods: “posts“ and
“formatted_posts“

16. THE INTERFACE SEGREGATION
PRINCIPLE
Clients shouldn’t depend on
methods they don’t use. Several
client-specific interfaces are better
than one generalized interface.
 Main classes should be segregated into
smaller specific classes, so their clients use
only methods they need.
 We get the interfaces segregated
according to their purpose, so we avoid
“fat” classes and code that’s hard to
maintain.

17. CHECK AN EXAMPLE
Any violation ISP?

18. VIOLATIONS
1. Existing the unused methods for
an instance

19. REFACTORED
1. Segregated in two interfaces
with methods that perform
specific tasks

20. THE DEPENDENCY INVERSION
PRINCIPLE
High-level modules shouldn’t
depend on low-level modules.
 Abstractions shouldn’t depend on details.
Details depend on abstractions
 The code that follows the LSP and OCP
principles should be readable and contain
clearly separated abstractions. It should also
be extendable, and child classes should be
easily replaceable by other instances of a
base class without breaking the system.

21. CHECK AN EXAMPLE
Any violation DIP?

22. VIOLATIONS
1. The classes PdfFormatter and
HtmlFormatter may contain the
logic that refers to other
classes. Thus, we may impact
all the related classes when
modifying the class Printer

23. REFACTORED
1. High-level object (Printer)
doesn’t depend directly on the
implementation of low-level
objects
2. Our high-level functionality is
separated from all low-level
details, so we’re able to easily
change the low-level logic
without system-wide
implications

24. CONCLUSION
Applied correctly, SOLID design
recommendations can help you
build system architecture that is
easy to modify and extend over
time
 Saying “Now my code conforms to SOLID
design principles” is the wrong approach.
 Remember that SOLID principles themselves
don’t guarantee great object-oriented
design.
 Apply SOLID principles smartly

25. RELAX