Software Architecture: Meta and SOLID Principles in C#

Explore the open-closed principle, its two definitions by Martin and Meyer, and how refactoring fixes violations, while previewing template method, strategy patterns, and abstract classes versus interfaces.

The open closed principle states software should be open for extension but closed for modification. Changes come from adding code, using abstractions and interfaces to enable extension via dependency injection.

Demonstrate an OCP violation with a device finder that uses a switch to set parameters, showing why adding new devices requires modifying the method, and highlight Martin's view of OCP.

Refactor the design by abstracting the find method behind a device interface, enabling new device implementations without code changes and balancing inheritance with composition for open-for-extension design.

Explore OCP related patterns, including template method, strategy, and visitor patterns, and compare abstract classes versus interfaces for extensibility in C# design.

Identify the common smell of OCP violation—many conditional branches and switch statements—and explore delegates, the chain of responsibility pattern, template method, visitor, and strategy patterns to favor composition over inheritance.

apply the open for extension and closed for modification principle, isolate the parts that change most, and centralize object creation in a single module using abstract classes or interfaces.

Explore the Liskov Substitution Principle, contracts and variance, and preconditions and invariants, highlighting common LSP violations with a BCL example and strategies to fix them.

Clarify the Liskov substitution principle, showing subtypes must replace base types without observable client differences, and note duck typing and two common violations: contracts and covariance or contravariance.

Explore programming to contracts, distinguishing contracts from interfaces, and define preconditions, postconditions, and invariants; see how weakening contracts in inheritance breaks LSP and how code contracts verify correctness.

Explore a classic LSP violation where square inherits from rectangle, revealing why substitutability fails for area calculations and illustrating an open-closed principle violation.

We refactor to separate data and behavior by introducing a shape interface with per-shape area algorithms for rectangle and square, improving cohesion and API safety for future LSP discussion.

Explore common LSP violations with practical examples of variance, covariance, and related concepts; analyze how read-only collections and downcasting reveal subtleties in C# generics and interface design.

Identify common smells of LSP violation, such as refused bequest and downcasts, and apply tell‑don’t‑ask while fixing root causes by creating a shared base class.

enforce the LSP by treating subtypes as interchangeable with base types to ensure consistent behavior; avoid strengthening preconditions or weakening postconditions and respect covariance and contravariance in generics (in, out).

Explore the interface segregation principle (ISP) within solid principles, define ISP, identify problems caused by fat interfaces, and refactor to improve maintainability with life demo examples.

Explore how interface definitions in c# shape APIs and why the interface segregation principle favors small, cohesive interfaces. See how interface aggregation and dependency inversion solve fat classes.

Explore how a fat bank terminal interface triggers an isp violation across Zone, PDU, and Zap terminals, highlighting lsp risks and the need for refactoring.

Apply the interface segregation principle by creating small, isolated interfaces for card reader operations, implement this interface on bank terminal models, and achieve low coupling and high cohesion.

Demonstrates how a knowledge-heavy interface implementor complicates tests with a config class and xml configuration. Extract a minimal interface, inject it via the constructor, and apply the interface segregation principle.

Segregate the configuration interface so reports access only the configuration needed for generating reports, inject that interface into the report constructor, and implement a unit test to spot isp violations.

Identify common smells tied to the interface segregation principle and LSP, and apply fixes like splitting fat interfaces with the facade or adapter pattern to improve cohesion and dependency management.

Explore the interface segregation principle by ensuring clients depend only on used methods. Extract focused interfaces, apply facades or adapters, and embrace ISP to improve long-term maintainability.

Explore the dependency inversion principle, inversion of control, and dependency injection; learn refactoring techniques to fix DIP violations, examine containers, and understand architectural implications.

explore the dependency inversion principle by contrasting tight and loose coupling, define that high-level modules should depend on abstractions, and examine practical decoupling with a lamp and socket analogy.

Explore dependencies between high-level domain objects and low-level infrastructure, and show how interfaces enable indirection to reverse dependencies, achieving runtime flexibility and reduced compile-time ties.

Explore volatile versus stable dependencies, learn how indirection abstracts unstable external systems like databases and web servers, and apply test doubles to keep code unit-testable.

Explore inversion of control, dependency injection, and the dependency inversion principle, distinguishing dependencies, injection techniques, callbacks, frameworks, and the template pattern.

Demonstrate how a divergence checker is tightly coupled to counter and fiscal registration devices, revealing a DIP violation and prompting three dependency injection approaches to enable reliable unit testing.

Apply dependency injection to expose hidden dependencies and improve testability: use constructor, property, or method injection; compare encapsulation implications and enable unit tests with test doubles.

Explore dependency injection techniques in C#, including constructor, property, and method injection, and learn pitfalls when a constructor takes many dependencies, use container objects, and consider default constructors for frameworks.

Explore how to define boundaries and invert dependencies with plug-ins, privileging domain logic at the core and embracing onion, hexagonal, and ports-and-adapters architectures for flexible, testable software.

Explore pure DI vs manual dependency injection, and how IoC containers automatically resolve dependencies from the view model to the customer interface, repository, and gateway.

Implement a simple IoC container in C# by mapping types and resolving dependencies. Register dependencies, handle constructors with recursion, and validate creation of the main view model.

Explore a real-world wpa app for managing students built with an IoC container, demonstrating bootstrap, MVVM, data binding, and a Windsor-based plug-in architecture with an XML data provider.

Identify common smells of dependency inversion principle violations, such as explicit dependencies and hidden, static dependencies, and decouple with a layer of indirection, interfaces, and adapters to enable test doubles.

Explore how higher level policies avoid low level details, distinguish stable and unstable dependencies, and apply inversion of control and dependency injection to enable a ports and adapters architecture.

Learn core software design principles, including the dry and keep it simple principles, and you ain't going to need it, separation of concerns, Demeter, least knowledge, least astonishment, and encapsulation.

Apply the dry principle to eliminate duplicate logic and magic values by creating a single source of change, and use the open/closed principle to avoid switch-case duplication.

Apply the Kiss principle to keep software simple, reduce accidental complexity through decomposition and small components, and balance solid principles with composition over inheritance and avoiding pre-emptive optimisations.

Master the Yagni principle to avoid overengineering by selecting the simplest thing that could possibly work now, weighing future costs, and balancing extension points with refactoring and testing.

Learn how separation of concerns divides UI, business logic, presentation logic, and database into modular components to simplify development and maintenance, and to keep domain logic persistence agnostic.

Master the CQS principle: design methods as either commands or queries, never both, and use explicit names and signatures to improve clarity, security, and API honesty.

Explain the law of demeter as a principle of least knowledge that reduces coupling, using the paper boy scenario to show why wallets should be encapsulated and accessed via getPayment.

Explore the principle of least astonishment, showing that APIs should behave as users expect to avoid temporal coupling and surprising side effects in methods like print report.

Explore information hiding and encapsulation as foundations of robust APIs in C#. Learn how stable interfaces and private members protect invariants and simplify client use.

Define what an api is and why modular design matters. Examine good apis—simplicity, expressiveness, extensibility, and consistency—by comparing private and public APIs and applying open-closed principles.

Explore solid vs yagni to avoid needless complexity from overgeneral designs, gold plating, and coupling, and apply the single responsibility principle, reused abstraction principle, and the rule of three.

Compare the open/closed principle and yagni, examining private vs public api contexts and why future refactoring costs drive different choices about adding abstractions.

Clarify the difference between SRP and ISP by contrasting the designer's single-responsibility focus with the client's need to depend only on exposed interfaces, using a data storage example.

Clarify the difference between architecture and design, identify significant components, and learn to defer architectural decisions while exploring architecture and design patterns.

Master the dry principle by ensuring a single unambiguous representation and avoiding overengineering. Decompose to reduce essential versus accidental complexity and separate concerns into modular design.

Join the mailing list for discounts, leave a review, explore discounted courses and the blog on engineerspock.com, and support the creator on Patreon.