Design Patterns: Elements of Reusable Object-Oriented Software

Author: Ralph Johnson, Erich Gamma, John Vlissides, Richard Helm
All Stack Overflow 198
This Year Reddit 49
This Month Stack Overflow 2

About This Book

Capturing a wealth of experience about the design of object-oriented software, four top-notch designers present a catalog of simple and succinct solutions to commonly occurring design problems. Previously undocumented, these 23 patterns allow designers to create more flexible, elegant, and ultimately reusable designs without having to rediscover the design solutions themselves.

The authors begin by describing what patterns are and how they can help you design object-oriented software. They then go on to systematically name, explain, evaluate, and catalog recurring designs in object-oriented systems. With Design Patterns as your guide, you will learn how these important patterns fit into the software development process, and how you can leverage them to solve your own design problems most efficiently.

Each pattern describes the circumstances in which it is applicable, when it can be applied in view of other design constraints, and the consequences and trade-offs of using the pattern within a larger design. All patterns are compiled from real systems and are based on real-world examples. Each pattern also includes code that demonstrates how it may be implemented in object-oriented programming languages like C++ or Smalltalk.


by CodeSheikh   2019-01-20
Nice list. Appreciate it. But I see there are a few amazing software books missing from the list such as:

- Clean Code (by "Uncle Bob")) []

- Design Patterns (by "Gang of 4") []

- Introduction to Algorithms (by "CLRS") []

by anonymous   2019-01-13

I believe the famous recommendation of "favor composition over inheritance" was coined in the GoF Design Patterns book.

It says (p.20):

Favor object composition over class inheritance.

Ideally, you shouldn't have to create new components to achieve reuse. You should be able to get all the functionality you need just by assembling existing components through object composition. But this is rarely the case, because the set of available components is never quite rich enough in practice. Reuse by inheritance makes it easier to make new components that can be composed with old ones. Inheritance and object composition thus work together.

Nevertheless, our experience is that designers overuse inheritance as a reuse technique, and designs are often made more reusable (and simpler) by depending more on object composition. You'll see object composition applied again and again in the design patterns.

Notice that this statement refers to class inheritance, and must be distinguished from interface inheritance which is fine.


Both are ways to achieve reusability, but the advantage of composition over inheritance is dynamism. Since the composition can be changed dynamically at runtime this represents a great advantage, whereas inheritance is statically defined at compile time.


Also, composition is based on using the public interfaces of the composed objects, therefore objects respect each other's public interfaces and therefore this fosters encapsulation. On the other hand, inheritance breaks encapsulation since child components typically consume a protected interface from the parent. It is a well known problem that changes in the parent class can break the child classes, the famous base class problem. Also in inheritance parent classes define the physical representation of subclasses, therefore child clases depend on parent classes to evolve.


Another advantage of composition is that it keeps classes focused on one task and this foster cohesion as well.


Evidently a problem with composition is that you will have more objects and fewer classes. That makes a little more difficult to visualize your design and how it achieves its goals. When debugging code it is harder to know what is going on unless you know what exact instance of a given composite is currently being used by an object. So composition makes designs a bit harder to understand in my opinion.

Since the advantages of composition are multiple that's why it is suggested to favor it over inheritance, but that does not mean inheritance is always bad. You can achieve a great deal when inheritance is properly used.

Interesting References

I would suggest a study of GoF Design Patterns to see good examples of both types of reusability, for instance a Strategy Pattern that uses composition vs a Template Method that uses inheritance.

Most of the patterns make a great use of interface inheritance and then object composition to achieve their goals and only a few use class inheritance as a reusability mechanism.

If you want to delve more the book Holub on Patterns, on chapter 2 has a section called Why extends is Evil that delve much more on the liabilities of class inheritance.

The book mentions three specific aspects

  • Losing Flexibility: The first problem is that explicit use of a concrete-class name locks you into a specific implementation, making down-the-line changes unnecessarily difficult.
  • Coupling: A more important problem with implementation inheritance is coupling, the undesirable reliance of one part of a program on another part. Global variables are the classic example of why strong coupling is bad. If you change the type of a global variable, for example, all the code that uses that variable—that is coupled to the variable—can be affected, so all this code must be examined, modified, and retested. Moreover, all the methods that use the variable are coupled to each other through the variable. That is, one method may incorrectly affect the behavior of another method simply by changing the variable’s value at an awkward time. This problem is particularly hideous in multithreaded programs.
  • Fragile-Base-Class Problem: In an implementation-inheritance system (one that uses extends), the derived classes are tightly coupled to the base classes, and this close connection is undesirable. Designers have applied the moniker “the fragile-base-class problem” to describe this behavior. Base classes are considered “fragile” because you can modify a base class in a seemingly safe way, but this new behavior, when inherited by the derived classes, may cause the derived classes to malfunction.
by anonymous   2019-01-13

Good opening slides for any education course in my opinion are:

  1. Why are we here? (Where has the need for this course been identified?)
  2. What do I expect to learn?
  3. Who should take this course? (What are the intended students, prerequisites, etc?)
  4. When can I apply what I’ve learned?
  5. Expectations of you (Participation, homework, tests, minimum classes to attend, etc)

For design patterns I could expect several visual tools or "job aids".

I would follow a structure similar to the Elements of Reusable Object-Oriented Software book:

  1. UML – Class Diagram Overview
  2. OOP – Abstraction, Encapsulation, Polymorphism, Inheritance
  3. Cohesion and Coupling
  4. What is a Design Pattern? – Pattern Name, The Problem, The Solution, The Consequences
  5. Why are Design Patterns so hard to learn?
  6. Why use Design Patterns?
  7. How to select a Design Pattern?
  8. How to use a Design Pattern?
  9. Cover various GoF design patterns with examples – Show examples of code before applying a design pattern, and how it looks after like Vince Huston does in his examples.
  10. Conclusion

As already mentioned, design patterns are really ideas, so when teaching you must convey the idea. If they understand the problem, solution and consequences of the design pattern, then they will be far better off than trying to force patterns into the code (and that will become a nightmare). Recognition of where and what patterns (if any) can be applied is the real goal. The Huston examples are really good for putting out an example of code to the class and seeing if they can identify a pattern to improve it. Hope this helps.

Head First Design Patterns is an excellent reference as well.

by anonymous   2019-01-13

I think the first thing that is needed here is a good / appropriate data structure to keep / manipulate the table data. That depends on specific requirements you can have, such as size of the table, performance requirements, etc.

Let's assume you will use some Matrix class which provides low-level operations over table (set cell value, add/remove row, transpose, etc).

This class will operate with basic data structures, for example, it may have get_row method which will return a list of numbers. Now we can, for example, get the summary of values in this list, but we can't just change some list item and have this change reflected in the parent Matrix (the row data is disconnected from the parent matrix structure).

Now we can build our structure upon this Matrix class, our two targets are:

1) make it more convenient for the user, some of the "conveniences" can be:

  • row, column and cell objects all connected to the parent Table object (if we modify the row item, it will be reflected in the parent table and other row / column / cell obejcts).
  • we can generate different views of the same data (such as pivot tables)
  • we can use special column/row addressing system (such as using 1, 2, 3, ... for rows and A, B, C, ... for columns)

2) hide the actual data structure we use to store the table data

  • this way we can work on Matrix implementation independently without breaking user code
  • we can even replace it with different structure (maybe we find something that is faster or something that takes less memory), or we can have different implementations for different situations (for example for desktop and mobile apps)

This is the approximate classes structure I would start with (python-like pseudo code):

class Matrix:
    """The base data structure, implementation detail."""

    get_cell(int x, int y):
        """Returns cell value by x/y column and row indexes."""

    set_cell(int x, int y, value):
        """Sets cell value by x/y column and row indexes."""

    get_row(int index) -> list:
        """Returns `list` of values in the `index` row."""

    get_column(int index) -> list;
     """Returns `list` of values in the `index` column."""

The Matrix class is a low level data structure and it should not be a part of a public interface.

The public interface is represented by Table class and other related classes below:

class Table:
    """The user-level interface to work with table data."""

        """Initializes Matrix object."""
        # The "_data" object is private, only to be used internally.
        self._data = Matrix()

    row(int number) -> Row:
        """Returns `Row` object by row number (1, 2, 3, ...)."""
        row = Row(self, number)
        return row

    column(string name) -> Column:
        """Returns `Column` object by string name (A, B, C, ...)."""
        column = Column(self, name)
        return column

    cell(int row_number, string col_name) -> Cell:
        """Returns `Cell` object by string name (A, B, C, ...)."""
        cell = Cell(self, row_number, col_name)
        return column

    attach(Observer observer):
        """Register an observer to be notified when Table state was changed."""

        """Notify all dependent objects about the state change."""
        for observer in self.observers:


To keep Table and Row / Column / Cell objects in-sync we can use the Observer pattern.

Here the Table is a Subject and Row / Column / Cell are Observers. Once the state of the Table (and underlying data) is changed, we can update all dependent objects.

class Row(Observable):
    """Table row object."""

    constructor(Table parent, int index):
        self.parent = parent
        self.index = index
        self._data = None

        """Update row data.

        Fetches the `list` or row values from the `Matrix` object.
        # Note: we have two choices here - the `Row`, `Column` and `Cell` objects
        # can either access `Table._data` property directly, or `Table` can provide
        # proxy methods to modify the data (like `_get_value(x, y)`); in both cases
        # there is a private interface to work with data used by `Table`, `Row`,
        # `Column` and `Cell` classes and the implementation depends on the language,
        # in C++ these classes can be friends, in python this can be just a documented
        # agreement on how these classes should work.
        # See also the comment in the `remove` method below.
        self._data = parent._data.get_row(index)

        """Returns sum of row items."""
        sum = 0
        for value in self._data:
            sum += value
        return sum

    cell(string col_name):
        """Returns cell object."""
        return parent.cell(self.index, col_name)

        """Removes current row."""
        # Here we access `parent._data` directly, so we also have to
        # call `parent._notify` here to update other objects.
        # An alternative would be a set of proxy methods in the `Table` class
        # which would modify the data and then call the `_notify` method, in such case 
        # we would have something like `self.parent._remove_row(self.index)` here.

The Column and Cell classes are similar, the Column will hold the column data and the Cell will wrap the cell value. The user-level usage can look like be this:

table = Table()
# Update table data
table.cell(1, "A").set(10)
table.cell(1, "B").set(20)
# Get row sum
sum = table.row(1).sum()

# Get the table row
row = table.row(1)
# The `remove` operation removes the row from the table and `detaches` it,
# so it will no longer observe the `table` changes.
# Now we have the detached row and we can put it into another table,
# so basically we cut-and-pasted the row from one table to another

Using this approach you can quite easily implement such operations as copy, cut, paste. Also you can apply Command pattern here and extract these operations into small classes. This way it will also be quite easy to implement undo and redo.

The PivotTable table can also be a special kind of Observable. Depending on the requirements to the features for the pivot table, you may find Builder pattern useful to configure the pivot table. Something like this:

pivotBuilder = PivotBuilder(table)
# Group by column "A" and use `SumAggregator` to aggregate grouped values.
pivotBuilder.group_by_column("A", SumArggregator())  # or maybe pivotBuilder.groupBy(table.column("A"))
pivotTable := pivotBuilder.get_result()

The classes to export table to different formats probably don't have to be observable, so they'll just wrap the Table object and transform it to the appropriate format:

json_table = JsonTable(table)
data = json_table.export()

Of course, the above is just one of many possible implementation options, treat them as some ideas that can be useful (or not useful) depending on specific requirements you have.

You may find more ideas in the GoF patterns book.

by anonymous   2018-08-06

Decorator adds responsibilities for an object dynamically. Let's say we need to count the number of times an item is added to a Set (a kind of instrumentation detail). We have Set interface in java and we can implement a decorator to add the instrumentation behavior to an existing Set implementation like so.

public class InstrumentedSet<E> extends ForwardingSet<E> {
    private int addCount = 0;

    public InstrumentedSet(Set<E> s) {

    public boolean add(E e) {
        return super.add(e);

    public boolean addAll(Collection<? extends E> c) {
        addCount += c.size();
        return super.addAll(c);

    public int getAddCount() {
        return addCount;


public class ForwardingSet<E> implements Set<E> {
    private final Set<E> s;

    public ForwardingSet(Set<E> s) {
        this.s = s;

    public int size() {
        return s.size();

    public boolean isEmpty() {
        return s.isEmpty();

    public boolean contains(Object o) {
        return s.contains(o);

    public Iterator<E> iterator() {
        return s.iterator();

    public Object[] toArray() {
        return s.toArray();

    public <T> T[] toArray(T[] a) {
        return s.toArray(a);

    public boolean add(E e) {
        return s.add(e);

    public boolean remove(Object o) {
        return s.remove(o);

    public boolean containsAll(Collection<?> c) {
        return s.containsAll(c);

    public boolean addAll(Collection<? extends E> c) {
        return s.addAll(c);

    public boolean retainAll(Collection<?> c) {
        return s.retainAll(c);

    public boolean removeAll(Collection<?> c) {
        return s.removeAll(c);

    public void clear() {


There are lot more examples for Decorator pattern that you better take a look. For an instance, say you are developing Window based GUI application. You may need to add borders to the window, a scroll bar and so on. Some times you may need to add any combination of those. That is a good use of Decorator pattern as stated in the famous Design Patterns book [1] by Gamma. I would suggest you read this book [1] to find more about design patterns.


by xbrandnew99   2018-03-19

Design Patterns: Elements of Reusable Object-Oriented Software doesn't use JS for it's examples, but is highly regarded in learning design patterns.

Also, Mastering JavaScript Design Patterns is pretty good, and if I recall correctly, is modeled after the first book I mentioned. Heads up, there is a more up to date 2nd edition of this book available (linked version is 1st edition)

by rjcarr   2018-03-19

Not some book, but the book:

Again, not saying you need to read it cover-to-cover, but if you didn't even know it existed then that's likely a problem.

by BlueCoatEngineer   2018-03-19

kicks chair back to glance at shelf


The Art of Electronics, 3rd edition (Horwitz/Hill)

Learning the Art of Electronics (Hayes/Horowitz)

*Signal Integrity - Simplified (Bogatin)

Debugging - 9 Indispensible Rules... (Agans)


The C Programming Language (Kernighan / Ritchie)

The Practice of Programming (Kernighan / Pike)

Clean Code: A Handbook of Agile Software Craftmanship (Martin)

Design Patterns: Elements of Reusable Object-Oriented Software (Gamma, Helm, et al)


*Computer Architecture, Fifth Edition: A Quantitative Approach (Hennessy / Patterson)

Note the repeated author names. :) Some of these might be a little beyond you since you're a freshman. I put a star in front of the ones that you might want to wait on until you've got more fundamentals built up. You don't have to wait for your school to teach them to you though.

A great way to jump-start your knowledge is to buy an Arduino experimentation kit (like Adafruit's ARDX) and learn how to use it. You'll get to play with where the code meets the hardware and you'll learn enough electronics knowledge to go all sorts of different directions.

Edit: almost forgot; teach yourself to draw like a mechanical engineer. There's likely an into to mechanical drawings course for the frosh Mechos, take it if you can. It comes up more often than you'd think and it'll help you learn to effectively communicate ideas visually.

by anonymous   2018-03-19

It is good that you have started organizing your code into objects, this is a good move into the better application structure. Once when you start looking deeper into it, you will find ways to split your current objects into even smaller parts and organize them in better ways, having less code solving more problems in more flexible ways.

For example, in your code the business logic is still tightly coupled to the database. What if you decide to use mysqli instead of PDO? You'll have to touch every class in your application.

But if the database interaction was extracted into own set of objects that were used by your business logic, it would be much easier to replace the database access layer. In fact, you could quite easily replace MySQL with PostgreSQL or even with plain files in that case.

I can think of two ways to learn more about how OOP works: read a book or learn from the existing code.

The book I linked is my favorite OOP book and shows some very good examples of how the problem can be solved with OOP by decomposing the program into the co-operating objects.

And I'd also recommend starting using some OOP framework, I had some good experience with Yii in the past, check the guide to see how it looks like. You'll see tons of useful objects solving various problems you have to solve all the time when developing a web application. Try to build some simple application with it and then try to look inside the framework code to see how it actually works.

One more advice is to look into automatic testing. This will not only keep your application alive, but will teach you how to compose better objects. You'll have to use your classes in two different situations - your actual code and tests. Inside tests you will want to isolate the object you are testing from the rest of the code, for example, test the sales stats algorithms without touching the database. And you'll have to split you code into smaller and more flexible structure to be able to do that.

by Michael Stum   2018-03-19

Big List of Resources:


  • ¶ Link to a PDF file
  • $ Link to a printed book
by anonymous   2017-11-27
Re, "Is there some design pattern involved in...?" It _is_ a design pattern. A design pattern is any way of doing something that is replicated by lots of developers. The purpose of the original [Design Patterns book]( was to teach us to give them names so that we may more easily talk about them. I don't know if there's a better name, but most developers would know what I was talking about if I said, "...create a thread with a `Runnable` _delegate_."
by gnufied   2017-08-20
What i listed was just an example but you can verify quickly - without opening the actual book.

And afaict - none of the patterns I listed are mentioned verbatim.

by PaulKeeble   2017-08-20
The classical Design Patterns book has a first chapter which takes you through the design of a text editor using the patterns provided in the book. If what you do is read the chapter and then the patterns referenced as you go and build the text editor based on their design you get exactly the sort of thing you are looking for. Its a different way of doing it than the entire book but arguably just in a different format for what is otherwise a reference book.

by anonymous   2017-08-20

No, that does not violate any OOP principle.

A prominent example is an object who's behavior depends on whether a connection is established or not (e.g. function doNetworkStuff() depends on openConnection()).

In Java, there is even a typestate checker, which performs such checks (whether Duck can already Quack()) at compile time. I often have such dependencies as preconditions for interfaces, and use a forwarding class whose sole purpose is protocolling and checking the state of the object it forwards to, i.e. protocol which functions have been called on the object, and throw exceptions (e.g. InvalidStateException) when the preconditions are not met.

A design pattern that handles this is state: It allows an object to alter its behavior when its internal state changes. The object will appear to change its class. The design pattern book from the Gang of Four also uses the example above of a network connection either being established or not.

by anonymous   2017-08-20

You have to make up your mind whether the so called apple-specific method (in this case checkPrice()) is really specific to Apple. Or it is actually generally applicable to all fruits.

A method that is generally applicable should be declared in the base class

Assuming the answer is yes (in this case it does seems to be yes), then you should declare the method in the base class. In this case you can iterate through all the different types of fruits, and all of them would accept the method checkPrice(), so you don't even need to make a special case for apples.

A method that isn't generally applicable can be declared in an interface

What if the answer is no? Let's assume we need another method called getJuicePrice(), and we further assume that only some fruits can be made into juice (apple juice, orange juice) but other cannot (pineapple? durian?). In this case, a simple solution is to declare an interface, and only the fruits for which the method is appropriate would implement the interface. So let's say this interface is JuiceBehavior

package fruitcart;

import java.math.BigDecimal;

public interface JuiceBehavior {
    BigDecimal getJuicePrice();

And all fruits for which juice behavior is applicable (yes for Apple, no for Durian) would implement the interface:

package fruitcart;

import java.math.BigDecimal;

public class Apple implements JuiceBehavior {

    public BigDecimal getJuicePrice() {
        // FIXME implement this
        return null;


And then in your loop, what you check is whether a fruit is instanceof the interface:

if (fruit instanceof JuiceBehavior) {
    System.out.format("can be made into juice "
        + "with price $ %.2f%n", fruit.getJuicePrice());
} else {
    System.out.format("cannot be made into juice %n");


This solution would work for simple cases, but in more complicated cases, you may notice that you start to duplicate a lot of implementation code for getJuicePrice() for different types of fruits. This leads to the next topic

Design Pattern: Strategy

You may want to start thinking about the Design Pattern called Strategy, which further encapsulates JuiceBehavior and make it into a family of classes representing different juice behaviors. It also let you set different types of fruits to take different implementations of JuiceBehavior. I won't go into the details here. But you can read up on that on some books about Design Patterns. Such as

  1. Design Patterns: Elements of Reusable Object-Oriented Software
  2. Head First Design Patterns: A Brain-Friendly Guide
by Bill the Lizard   2017-08-20

Head First Design Patterns

alt text

and the Design Pattern Wikipedia page are the best resources for beginners. FluffyCat is another good, free online resource for design patterns in both Java and PHP.

The Gang of Four book is where to go afterward, but it's fairly advanced, so I'd wait until you have a pretty firm grasp from the other resources.

by anonymous   2017-08-20

Can somebody please explain in layman's terms?

Design patterns are not really "layman" concepts, but I'll try to make it as clear as possible. Any design pattern can be considered in three dimensions:

  1. The problem the pattern solves;
  2. The static structure of the pattern (class diagram);
  3. The dynamics of the pattern (sequence diagrams).

Let's compare State and Strategy.

Problem the pattern solves

State is used in one of two cases [GoF book p. 306]:

  • An object's behavior depends on its state, and it must change its behavior at run-time depending on that state.
  • Operations have large, multipart conditional statements that depend on the object's state. This state is usually represented by one or more enumerated constants. Often, several operations will contain this same conditional structure. The State pattern puts each branch of the conditional in a separate class. This lets you treat the object's state as an object in its own right that can vary independently from other objects.

If you want to make sure you indeed have the problem the State pattern solves, you should be able to model the states of the object using a finite state machine. You can find an applied example here.

Each state transition is a method in the State interface. This implies that for a design, you have to be pretty certain about state transitions before you apply this pattern. Otherwise, if you add or remove transitions, it will require changing the interface and all the classes that implement it.

I personally haven't found this pattern that useful. You can always implement finite state machines using a lookup table (it's not an OO way, but it works pretty well).

Strategy is used for the following [GoF book p. 316]:

  • many related classes differ only in their behavior. Strategies provide a way to configure a class with one of many behaviors.
  • you need different variants of an algorithm. For example, you might define algorithms reflecting different space/time trade-offs. Strategies can be used when these variants are implemented as a class hierarchy of algorithms [HO87].
  • an algorithm uses data that clients shouldn't know about. Use the Strategy pattern to avoid exposing complex, algorithm-specific data structures.
  • a class defines many behaviors, and these appear as multiple conditional statements in its operations. Instead of many conditionals, move related conditional branches into their own Strategy class.

The last case of where to apply Strategy is related to a refactoring known as Replace conditional with polymorphism.

Summary: State and Strategy solve very different problems. If your problem can't be modeled with a finite state machine, then likely State pattern isn't appropriate. If your problem isn't about encapsulating variants of a complex algorithm, then Strategy doesn't apply.

Static structure of the pattern

State has the following UML class structure:

PlantUML class diagram of State Pattern

Strategy has the following UML class structure:

PlantUML class diagram of Strategy Pattern

Summary: in terms of the static structure, these two patterns are mostly identical. In fact, pattern-detecting tools such as this one consider that "the structure of the [...] patterns is identical, prohibiting their distinction by an automatic process (e.g., without referring to conceptual information)."

There can be a major difference, however, if ConcreteStates decide themselves the state transitions (see the "might determine" associations in the diagram above). This results in coupling between concrete states. For example (see the next section), state A determines the transition to state B. If the Context class decides the transition to the next concrete state, these dependencies go away.

Dynamics of the pattern

As mentioned in the Problem section above, State implies that behavior changes at run-time depending on some state of an object. Therefore, the notion of state transitioning applies, as discussed with the relation of the finite state machine. [GoF] mentions that transitions can either be defined in the ConcreteState subclasses, or in a centralized location (such as a table-based location).

Let's assume a simple finite state machine:

PlantUML state transition diagram with two states and one transition

Assuming the subclasses decide the state transition (by returning the next state object), the dynamic looks something like this:

PlantUML sequence diagram for state transitions

To show the dynamics of Strategy, it's useful to borrow a real example.

PlantUML sequence diagram for strategy transitions

Summary: Each pattern uses a polymorphic call to do something depending on the context. In the State pattern, the polymorphic call (transition) often causes a change in the next state. In the Strategy pattern, the polymorphic call does not typically change the context (e.g., paying by credit card once doesn't imply you'll pay by PayPal the next time). Again, the State pattern's dynamics are determined by its corresponding fininte state machine, which (to me) is essential to correct application of this pattern.

by anonymous   2017-08-20

Three things I'd suggest:

Design patterns - Elements of reusable object oriented software - THE original design patterns book. Has examples in C++.

Head first design patterns - a very nice books detailing design patterns in Java. An enjoyable view.

Real world examples of design patterns in JDK - a terrific Stack overflow answer by BalusC.

by anonymous   2017-08-20

If you are looking for physical validation, what I usually find that helps is doing some prototyping. This gives you a good idea usually of any unforeseen problems that might be in your design and just how easy it is to add onto it. I would try to apply any design patterns possible to allow future scalability. Elements of Reusable Object-Oriented Software is a great reference for that. Here are some good examples that show before and after code using design patterns. This can help you visualize how design patterns could make your code more scalable as well. Here is an SO post about specific design patterns for software scalability.

by anonymous   2017-08-20

This is actually simple to do once you understand that DI is about patterns and principles, not technology.

To design the API in a DI Container-agnostic way, follow these general principles:

Program to an interface, not an implementation

This principle is actually a quote (from memory though) from Design Patterns, but it should always be your real goal. DI is just a means to achieve that end.

Apply the Hollywood Principle

The Hollywood Principle in DI terms says: Don't call the DI Container, it'll call you.

Never directly ask for a dependency by calling a container from within your code. Ask for it implicitly by using Constructor Injection.

Use Constructor Injection

When you need a dependency, ask for it statically through the constructor:

public class Service : IService
    private readonly ISomeDependency dep;

    public Service(ISomeDependency dep)
        if (dep == null)
            throw new ArgumentNullException("dep");

        this.dep = dep;

    public ISomeDependency Dependency
        get { return this.dep; }

Notice how the Service class guarantees its invariants. Once an instance is created, the dependency is guaranteed to be available because of the combination of the Guard Clause and the readonly keyword.

Use Abstract Factory if you need a short-lived object

Dependencies injected with Constructor Injection tend to be long-lived, but sometimes you need a short-lived object, or to construct the dependency based on a value known only at run-time.

See this for more information.

Compose only at the Last Responsible Moment

Keep objects decoupled until the very end. Normally, you can wait and wire everything up in the application's entry point. This is called the Composition Root.

More details here:

Simplify using a Facade

If you feel that the resulting API becomes too complex for novice users, you can always provide a few Facade classes that encapsulate common dependency combinations.

To provide a flexible Facade with a high degree of discoverability, you could consider providing Fluent Builders. Something like this:

public class MyFacade
    private IMyDependency dep;

    public MyFacade()
        this.dep = new DefaultDependency();

    public MyFacade WithDependency(IMyDependency dependency)
        this.dep = dependency;
        return this;

    public Foo CreateFoo()
        return new Foo(this.dep);

This would allow a user to create a default Foo by writing

var foo = new MyFacade().CreateFoo();

It would, however, be very discoverable that it's possible to supply a custom dependency, and you could write

var foo = new MyFacade().WithDependency(new CustomDependency()).CreateFoo();

If you imagine that the MyFacade class encapsulates a lot of different dependencies, I hope it's clear how it would provide proper defaults while still making extensibility discoverable.

FWIW, long after writing this answer, I expanded upon the concepts herein and wrote a longer blog post about DI-Friendly Libraries, and a companion post about DI-Friendly Frameworks.