Low-Level Design Flashcards
Low Level Design Principles (3)
**Encapsulate what varies: **Identify parts likely to change, need extension, or be reused, and encapsulate them to make future updates easier.
**Design to interfaces: **Avoid coupling to concrete types—use interfaces to make replacing or evolving parts of the system easier.
Favor composition over inheritance: Inheritance ties you to concrete classes; composition and delegation often provide better long-term flexibility.
Observer: pros (6)
Pros
- Decouples state-changing logic from how changes are reflected in the UI or other components.
-** Supports inversion of contro**l, allowing flexibility in how updates are handled.
- Observers can be added or removed dynamically at runtime.
- Observable objects don’t depend on concrete observer classes, allowing for easy extensibility.
- Scales well as the number of views or components increases.
- Improves maintainability by avoiding the need to modify many classes when new views are added.
Observer: cons (3)
Observable objects must still be coupled to the Observer interface.
Observers must know about the objects they are observing.
Some level of coupling remains, just at a more abstract level.
Draw Observer
in notes
Strategy Design Pattern: Pros
- Encapsulates algorithms so clients rely on an interface, not specific implementations.
- **Easily extendable: **New algorithms can be added without changing client code.
- **Avoids subclassing the client **for each variation.
- Removes conditionals from client logic (e.g., if/else chains).
Strategy Design Pattern: Cons
- The **client must know which strategy to use **and how to instantiate it.
- Strategy is typically fixed at runtime and not meant to change often.
- **May require factories or dependency injection **to fully decouple instantiation.
Draw Strategy Design Pattern
in notes
State Design Pattern: pros
- Encapsulates state-specific behavior into separate objects using composition.
- Simplifies state transitions by delegating them to state objects rather than large if/switch blocks.
- **Improves clarity: **Each state only needs to reason about its own valid transitions, not all global ones.
- Makes debugging easier (e.g., can log transitions through setState()).
State Design Pattern: cons
- Requires more classes to represent each state, increasing code size and complexity upfront.
- The client must maintain a reference to the current state, and the overall system must be aware of how to transition between states via delegation.
key diff state vs strategy
-** state: **all about allowing states within system to dynamically change at runtime (dynamic change)
- **strategy: ** NOT dynamic, algo is set at beginning and is used for the entirety of the execution
Draw Facade Pattern
in notes
Facade Pattern: pros
- Simplifies complex subsystems by providing a unified high-level interface.
-** Easier for clients to use common functionality** without needing to understand all subsystem details.
- Reduces coupling between clients and subsystem classes.
- Improves maintainability: changes to internal subsystem classes only require updating the facade, not client code.
- Supports multiple facades tailored to different client use cases.
-** Encourages modular design** by inserting a clean, optional abstraction layer.
Facade Pattern: cons
-** Does not enforce encapsulation**—clients can still directly access subsystem internals.
- Adds another layer to the design, which could lead to overhead or redundancy if not carefully managed.
- Client still dependent on the facade’s API, which must remain stable to protect clients from change.
Adapter Pattern
- act as translaters enabling objects/implementations used in one design to be converted
- Adapter objects simply act as a wrapper for another object. Concretely: the adapter contains a field of the wrapped type, and exposes a set of methods that make sense for a given design
Adapter Pattern: pros/cons
- pro: it allows clients of the adapters to remain oblivious of the design of the wrapped object, while still taking advantage of its functionality
Draw Singleton Pattern
in notes
Singleton: cons
- more care is required when implementing the pattern in languages that allow true multi-threading
- MAKE SURE YOU ARE ONLY RETURNING ONE COPY
- the Singleton itself acts as a global variable because every class in the system has the ability to get a reference to this type
Draw Decorator Pattern
in notes
in brief: allows you to dynamically add responsibilities to individual objects without modifying their class.
Works by wrapping objects using composition, allowing flexible, runtime behavior customization.
Draw Composite Pattern
in notes
Decorator Pattern: pros
- Adds features without modifying base classes
- Supports flexible combinations of features at runtime
- Follows Single Responsibility Principle: base class stays simple
- Follows Open/Closed Principle: behavior can be extended via new decorators
- Encourages composition over inheritance
Decorator Pattern: cons
- Order of decorators matters and can be hard to control
- Wrappers can’t easily interact with each other
- Can lead to many small classes
- Object identity is obscured (e.g., instanceof may not behave as expected)
Draw MVC
in notes
role of Model
Represents the application’s data
Handles data persistence and validation
Usually doesn’t know how to display itself
Helps program comprehension via clear interfaces
Acts as the Subject in the Observer pattern
role of View
Renders the Model for the user
Lets users interact with and manipulate the model
Maintains no state or data itself
Can have multiple implementations (e.g., DesktopView, MobileView)
Acts as the Observer in the Observer pattern
role of Controller
Contains main application logic
Binds the View and Model
Mediates updates to the Model based on View actions
Keeps logic out of the View to allow consistent behavior across views
Makes controller testing reusable across different views
MVC: pros
- Collaborative views; many views can render the same model in their own unique way.
- Enhanced maintainability due to the ease with which new views can be added (if existing views have kept their logic in the Controller).
- Team splitting by enabling designers, UX, and front-end teams to concentrate their work in the Views.
- Enhanced testability by trying to isolate application logic within the controller.
MVC: cons
Views can become bloated, making them hard to test and maintain.
Logic often ends up in the View instead of the Controller.
Tight coupling: changes to the Model can affect all components.
Low isolation reduces maintainability and extensibility.
Draw MVP
in notes
role of Presenter
Presenters contain all application logic, unlike many MVC Controllers.
Easily unit tested using a mock view—no UI or DOM needed.
Presenter and View are tightly bound via their interfaces for communication.
