--- title: "04 — Foundational Patterns and Principles — OOP, SOLID, and the MV* Family" uid: foundational-patterns-and-principles tags: ["oop", "solid", "mvp", "patterns", "roadmap:software-architect", "mvvm", "design-principles", "mvc"] excerpt: "Patterns and principles aren't rules to memorize — they're proven separations of concern. Each one draws a line through a system so changing one part doesn't drag another." date: 2026-08-13T03:27:42+0000 source: https://www.aveshina.my.id/en/blog/foundational-patterns-and-principles --- 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]: - **S**ingle Responsibility — a class should have one reason to change. - **O**pen/Closed — open for extension, closed for modification. - **L**iskov Substitution — subtypes must be substitutable for their base types without breaking behavior. - **I**nterface Segregation — many specific interfaces beat one fat interface. - **D**ependency 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]: ```figure ``` - **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](https://roadmap.sh/software-architect/patterns--design-principles) [2] "Object-oriented programming," Wikipedia. [Online]. Available: [https://en.wikipedia.org/wiki/Object-oriented_programming](https://en.wikipedia.org/wiki/Object-oriented_programming) [3] Baeldung, "SOLID Principles," [Online]. Available: [https://www.baeldung.com/solid-principles](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](https://medium.com/@ankit.sinhal/mvc-mvp-and-mvvm-design-pattern-6e169567bbad) ```quiz Q: What do MVC, MVP, and MVVM all fundamentally do? - Cache data on the client for performance - Separate an application's data, logic, and user interface into distinct layers correct: 1 explain: All three are UI-separation patterns that divide data (Model), UI (View), and the logic between them (Controller/Presenter/ViewModel) so each can change independently. Q: What is the key difference between MVP and MVC? - MVP removes the Model entirely - MVP uses a Presenter that owns view logic, usually via an interface, making the view more passive correct: 1 explain: In MVP the Presenter handles view logic and talks to the View through an interface, whereas in MVC the Controller routes input and the Model notifies the View directly. Q: MVVM is best suited to platforms that… - have strong automatic (often two-way) data binding between a ViewModel and the View - use only server-side rendering with no client state correct: 0 explain: MVVM's defining trait is automatic data binding — the View subscribes to the ViewModel and updates itself. Platforms with strong binding (WPF, modern web frameworks) lean MVVM. Q: The "S" in SOLID stands for Single Responsibility, which means… - a class should have one reason to change - a project should have a single architect correct: 0 explain: Single Responsibility: a class has one reason to change. Multiple responsibilities in one class mean a change to one ripples into the others. Q: What thread connects OOP, SOLID, and the MV* family? - They all enforce separation of concerns by depending on narrow abstractions - They all require a specific programming language correct: 0 explain: Each draws a line and asks you to depend on the narrow side: OOP separates interface from implementation, SOLID polices it at class level, MV* separates UI from logic. ```