Software Design
First design, then code
SOLID Principles
The SOLID principles are guidelines for software development with the intention of creating quality software, applying good practices to eliminate bad designs that lead to chaotic, difficult-to-maintain software.
Single Responsibility
arrow_forwardA class should have one, and only one, reason to change; that is, encapsulate the responsibility.
Open Closed
arrow_forwardSoftware entities should be open for extension but closed for modification.
Liskov Substitution
arrow_forwardObjects in a program should be replaceable with instances of their subtypes.
Interface Segregation
arrow_forwardNo client should be forced to depend on methods it does not use.
Dependency Inversion
arrow_forwardHigh-level modules should not depend on low-level modules. Both should depend on abstractions.
Patrones de Diseño
They represent solutions to common problems, applicable to different design problems in different circumstances. They are categorized according to their purpose: Creational, Structural and Behavioral.
Creational
They define the way an object is created. They abstract the details of creation, helping to create a system independent of how objects are created, composed and represented.
Abstract Factory
arrow_forwardDefines an interface for creating related object families without specifying their class.
Builder
arrow_forwardSeparates the construction of a complex object from its representation.
Factory Method
arrow_forwardDefines an interface to create an object, but lets subclasses decide which class to instantiate.
Prototype
arrow_forwardAllows the creation of new objects by cloning an existing object known as the prototype.
Singleton
arrow_forwardEnsures that a class has only one instance, and provides a global point of access.
Structural
They focus on how to combine classes and objects to form larger structures, and thus be able to solve complex problems.
Adapter
arrow_forwardConverts the interface of a class into another that clients expect.
Bridge
arrow_forwardDecouples an abstraction from its implementation, so that both can vary.
Composite
arrow_forwardComposes objects in tree structures to represent part-whole hierarchies.
Decorator
arrow_forwardAdds additional responsibilities to an object dynamically.
Facade
arrow_forwardProvides a unified and simplified interface to a set of interfaces in a subsystem.
Flyweight
arrow_forwardUses sharing to support a large number of fine-grained objects efficiently.
Proxy
arrow_forwardProvides a surrogate to control access, defer its creation, or manage remote accesses.
Behavioral
They deal with algorithms and the assignment of responsibilities to objects.
Chain of Responsibility
arrow_forwardDecouples the sender of a request from its receiver.
Command
arrow_forwardEncapsulates a request as an object.
Interpreter
arrow_forwardEvaluates sentences in a language.
Iterator
arrow_forwardAccesses elements sequentially.
Mediator
arrow_forwardReduces communication complexity.
Memento
arrow_forwardCaptures and restores internal states.
Observer
arrow_forwardSubscription for state changes.
State
arrow_forwardAlters behavior based on state.
Strategy
arrow_forwardInterchangeable algorithms.
Template Method
arrow_forwardDelegable algorithm skeleton.
Visitor
arrow_forwardNew operations without changes.
Deep Dive: The cost of bad design
We often hear that software design is a "luxury" that fast-paced teams cannot afford. However, technical reality proves otherwise through the metaphor of technical debt.
"If you don't have time to do it right, when will you have time to do it over?"
A poorly designed system presents what we call rigidity. Trying to change one part of the system breaks three other unrelated parts. This fragility stalls innovation and turns maintenance into a nightmare of "monkey patching".
By applying design patterns, we are not adding complexity; we are applying proven solutions to recurring problems. We are creating a common language for the team and ensuring the scalability of the product in the long term.
Explore other topics
Next level:
Clean Architecture arrow_forward
Designing is starting to code with a plan (instead of starting by writing code).
Robust software, with good quality attributes and prepared for the future.