04 — Foundational Patterns and Principles — OOP, SOLID, and the MV* Family

Vocabulary to memorize before interviews was how I treated the foundational patterns cluster, and it stayed dead on the page. The model that made it useful: these are proven separations of concern, not rules — each one is a way of drawing lines through a system so that changing one part doesn't drag another with it [1]. Once I stopped reciting definitions and started asking "what line does this pattern draw, and why," the whole cluster collapsed into one idea applied at different scales.

Patterns and design principles are the bridge between high-level architecture and practical implementation [1]. They're proven solutions to common problems, and an architect uses them as a shared language to discuss trade-offs without re-deriving everything from scratch.

OOP: organizing code around objects

Object-oriented programming organizes code around objects that combine data and behavior, using encapsulation (bundling data with the code that works on it), inheritance (one type building on another), and polymorphism (the same name doing different things per type) [2]. The point is to model real-world entities and relationships so related code stays together and reusable. Most enterprise architecture patterns and languages rely on OOP as a foundation — it's the default paradigm of Java, C#, Kotlin, and the .NET stack [2].

The separation OOP enforces is between an object's _interface_ (what it promises to do) and its _implementation_ (how it does it). That separation is what lets one part of a system depend on a contract rather than a concrete detail, and it's the foundation the rest of this post builds on.

SOLID: five principles for maintainable OOP

SOLID is the five-principle checklist an architect runs when reviewing a design for long-term maintainability [3]:

• Single Responsibility — a class should have one reason to change.
• Open/Closed — open for extension, closed for modification.
• Liskov Substitution — subtypes must be substitutable for their base types without breaking behavior.
• Interface Segregation — many specific interfaces beat one fat interface.
• Dependency Inversion — depend on abstractions, not concretions.

Following these leads to code that is easier to extend, test, and maintain as a system grows [3]. The thread connecting all five is the same one OOP draws at a smaller scale: keep parts decoupled by depending on narrow abstractions, not on broad concrete things. When a single class has five responsibilities, a change to one ripples into the other four — SOLID is the discipline of refusing that.

The MV* family: separating UI from logic

MVC, MVP, and MVVM are patterns for separating an application's data, logic, and user interface into distinct layers [4]:

• MVC (Model-View-Controller) splits responsibilities between model, view, and controller — the controller takes input and updates the model, which notifies the view [4].
• MVP (Model-View-Presenter) replaces the controller with a presenter that handles view logic, usually talking to the view through an interface so the view stays passive [4].
• MVVM (Model-View-ViewModel) introduces a view model that binds data to the view automatically — the view subscribes to the view model's properties and updates itself without explicit manipulation [4].

Choosing between them depends on the platform and how much automatic data binding the framework supports. A framework with strong two-way binding (WPF, modern web frameworks) leans MVVM; a framework with thin views leans MVP; the classic web request/response cycle often leans MVC. The pattern is downstream of the platform, not the other way around.

The single thread

Each of these — OOP, SOLID, the MV family — is the same idea: draw a line, depend on the narrow side of it. OOP draws it between interface and implementation. SOLID polices it at the class level. The MV family draws it between UI and logic. An architect who internalizes the underlying move (separate concerns, depend on abstractions) can re-derive any specific pattern; one who memorizes the names will misapply them when the platform doesn't match the textbook example.

How I use this

In design reviews, I don't ask "did you use MVC." I ask "where does input get routed, and does the model know about the view." If the answer reveals tight coupling that violates the intended separation, that's the real issue — the pattern name on the diagram is secondary. SOLID I use as a checklist for specific smells: a class with five responsibilities, a fat interface, a direct dependency on a concrete class where an abstraction would do.

References

[1] "Patterns and design principles," roadmap.sh — Software Architect. [Online]. Available: https://roadmap.sh/software-architect/patterns--design-principles

[2] "Object-oriented programming," Wikipedia. [Online]. Available: https://en.wikipedia.org/wiki/Object-oriented_programming

[3] Baeldung, "SOLID Principles," [Online]. Available: https://www.baeldung.com/solid-principles

[4] A. Sinhal, "MVC, MVP and MVVM Design Pattern," Medium. [Online]. Available: https://medium.com/@ankit.sinhal/mvc-mvp-and-mvvm-design-pattern-6e169567bbad