SOLID Principles of Object Oriented Design and Architecture

Define and debate the single responsibility principle (SRP) as the first SOLID principle, illustrate its ambiguity and team disagreements, and explore alternative, practical definitions for real-world design.

The lecture reexamines the single responsibility principle, arguing that defining it by using 'and' is impractical, and compares describing a class's duties with or without the conjunction.

Adopt a practical definition of the single responsibility principle: a class should have only one reason to change, enabling collaboration and a focus on business requirements.

learn to use Unified Modeling Language class diagrams to visualize the auth manager, its public methods, and the high level object oriented design concept.

Explore how the auth manager demonstrates the single responsibility principle by delegating password hashing to a hasher and persistence to a users data access object during the login flow.

Explore applying the single responsibility principle to a karaoke player by extracting parsing, lyrics overlay, and recording functionalities into dedicated classes, and treating the player as a final state machine.

Explore the single responsibility principle through reusability, showing how decoupling features into standalone classes for functionalities a, b, and c improves reuse and avoids over-engineering.

Apply the single responsibility principle by defining each class with one reason to change, using an analysis framework to isolate changing functionalities into standalone classes, like lego components.

Explore the concept of abstraction across hardware and software, from transistors and logic gates to modules, firmware, and operating systems, and learn how abstraction layers simplify complex digital systems.

Explore abstractions in object-oriented design and how they support SOLID principles. See how statements, methods, objects, and modules form abstraction levels to manage complexity and promote clean code.

Explore abstractions in client–service relationships, abstract service definitions, and realization, then compare abstract class, interface, and duck-typing across statically and dynamically typed languages within SOLID context.

Explore the open-closed principle of SOLID, clarifying open for extension versus closed for modification, and unpack the common confusion and historical perspective on how this principle guides design.

Examine the historical Open Closed Principle by Bertrand Meyer, defining open as extendable and closed as ready to ship with a stable API after release.

Open-closed principle relies on stable abstractions; extend a module's behavior by creating new derivatives of the abstraction, illustrating polymorphism. The lecturer notes protected variation as another practical framing.

Demonstrates open-closed principle by refactoring a salary calculator into tax calculators and a factory, illustrating strategy and abstract factory patterns with UML abstractions.

Explore applying the open closed principle to a karaoke player by introducing lyrics and timings parser abstractions and a factory for implementations, while weighing abstraction costs to avoid over-engineering.

Protect existing code from future changes by introducing abstractions between the application and the changes. Apply open-closed principles selectively, monitor requirements, and extract abstractions to realize quick, safe business value.

Explore the Liskov substitution principle through an intuitive rectangle and square example, showing why a square cannot substitute a rectangle when width and height vary independently.

Explore the history of the Liskov substitution principle, named after Barbara Liskov, and how safe subtype substitution underpins data abstraction, inheritance, and open-closed design.

Explore the Liskov substitution principle rules, distinguishing subclassing from proper subtype and detailing the seven rules for methods and type properties to assess subtype relations.

Explore the three method signature rules of the Liskov substitution principle: contravariance of arguments, covariance of results, and the exception rule, with practical subclassing examples.

Preserve all superclass invariants and constraints when subclassing, as shown by the bounded queue and duplicating queue, in line with the Liskov substitution principle.

Explore why square cannot be a proper subtype of rectangle under the Liskov substitution principle, highlighting invariants, constraints, and the conflict between square's width-height invariant and rectangle's setWidth constraint.

Explains how subtypes substitute super types without changing behavior and advocates design and document for inheritance or prohibit it, citing Liskov rules—contravariance, covariance, exception, pre‑condition, post‑condition, invariant, and constraint rules.

Learn how the interface segregation principle refactors a service into two smaller interfaces so each client uses only the methods it needs, improving readability and maintainability.

Explore how the publish-subscribe pattern and event bus enable decoupled communication, using interface segregation to separate publishers from subscribers and support maintainability and the open-closed principle.

Apply the interface segregation principle to refactor a legacy distributed system by replacing a monolithic XListener with message-specific dispatchers, so clients subscribe only to relevant messages.

Apply interface segregation principle and the principle of least knowledge by using narrowly focused interfaces to show what clients do and don't do, guiding maintainers and enabling refactoring.

Apply the dependency inversion principle: high level modules depend on abstractions, not details, with abstractions independent of details and runtime flow aligning with the implementation.

The open-closed principle is shown as a dependency-inversion-driven example where KaraokePlayer depends on a LyricsParser obstruction, encapsulated by LyricsParserImpl realizations, protecting against future changes and enabling multiple parsing strategies.

Demonstrate dependency inversion by replacing the client’s direct async call with a callback abstraction, decoupling client and service, and enabling reusable, readable doSomething flows.

Leverage dependency inversion to decouple inter-dependent modules by defining obstructions in module A that module B must implement, enabling fakes and acceptance tests for easier integration.

Leverage the dependency inversion principle to shield code from changing requirements, enable reusable components, and ease integration with external modules, while avoiding excessive abstractions that add indirection and complexity.

Apply solid principles to guide class design and architecture, emphasizing single responsibility principle, open close principle, liskov substitution, interface segregation, and dependency inversion.

Access bonus resources and course discounts via the included links. Follow the instructor on X for updates on android and programming, and subscribe to the blog and newsletter.