Cleaner Code
Writing
BY SHREY ANANDARIYA
Introduction
One of the best theories for cleaner code writing is SOLID
principles.
SOLID principles was introduced by Robert C. Martin in his 2000
paper “Design Principles and Design Patterns”.
However, the SOLID acronym itself was later introduced by
Michael Feathers.
Definitions
Single Responsibility
A class should have one and only one reason to change, meaning that a class should have only one job.
Open/Closed Principle
Objects or entities should be open for extension but closed for modification.
Liskov substitution principle
Objects of a superclass shall be replaceable with objects of its subclasses without breaking the
application.
Interface segregation principle
Clients should not be forced to depend on interfaces they do not use.
Dependency inversion principle
High-level modules should not depend on low-level modules; both should depend on abstractions.
Single
Responsibilit
y Principle
• This violates the Single
Responsibility Principle because
it's handling multiple tasks.
• We'll refactor it into separate
functions, each responsible for a
single task.
Single
Responsibilit
y Principle
• Now, we have separate functions
for generating the report, sending
it via email, and saving it to a file.
• This adheres to the Single
Responsibility Principle, as each
function is responsible for a single
task.
Open-Closed
Principle
• The Open-Closed Principle
emphasizes that components
should be
o Open for extension: can add new
behaviors or functionalities
o Closed for modification: existing
code should remain unchanged.
• Here, we modify the existing
Button component by adding an
icon prop. Altering an existing
component to accommodate new
requirements violates the Open-
Closed Principle.
Open-Closed
Principle
• We create a separate IconButton
functional component.
• The IconButton component
encapsulates the rendering of an
icon button without modifying the
existing Button component.
• It adheres to the Open-Closed
Principle by extending the
functionality through composition
rather than modification.
Liskov
Substitution
Principle
• This principle emphasizes the need
for substitutability of objects
within a hierarchy
• This approach violates the Liskov
Substitution Principle as it modifies
the behavior of the derived
component, potentially resulting in
unforeseen problems when
substituting it for the base Select
component.
Liskov
Substitution
Principle
• This component follows the Liskov
Substitution Principle and allows
the use of select's characteristics.
• By allowing the use of the select
element's characteristics and
accepting additional props, the
CustomSelect component follows
the Liskov Substitution Principle.
Interface
Segregation
Principle
• It suggests that interfaces should
be focused and tailored to specific
client requirements rather than
being overly broad and forcing
clients to implement unnecessary
functionality.
• Here, we pass the entire product
details to ProductThumbnailURL,
even though it doesn’t require it.
• It adds unnecessary risks and
complexity to the component and
violates the Interface Segregation
Principle (ISP).
Interface
Segregation
Principle
• Now, the ProductThumbnailURL
component only receives the
required information instead of
the entire product details.
• It prevents unnecessary risks and
fosters the Interface Segregation
Principle (ISP).
Dependency
Inversion
Principle
• It emphasizes that high-level
components should not depend on
low-level components.
• The CustomForm component is
tightly coupled to its children,
preventing flexibility and making it
challenging to change or extend its
behavior.
Dependency
Inversion
Principle
• In the revised code, we introduce
the AbstractForm component,
which acts as an abstraction for
the form.
• It receives the onSubmit function
as a prop and handles the form
submission.
• This approach allows us to easily
swap out or extend the form
behavior without modifying the
higher-level component.
Conclusion
The SOLID principles provide guidelines that empower developers to create
well-designed, maintainable, and extensible software solutions.
By adhering to these principles, developers can achieve modularity, code
reusability, flexibility, and reduced code complexity.
I hope this presentation has provided valuable insights and inspired you.