Skip to content

Category: Design Patterns & Principles

Breaking Circular Dependency between Components

Introduction Couple of days ago, I came across a piece of code that was not just tightly coupled but also formed a circular dependency among the components. In the following code, I’ve tried to give you a gist of it (may not be the best though). The below code has two key components, DataProvider and DataValidator. The DataProvider “new” DataValidator and passes in its own instance, which is then used…

Introduction to Software Design Patterns

Ever since software engineering has come to life, software engineers have repeatedly faced situations wherein they have to solve similar problems over and over again. And being a software engineer I can tell you that it is very annoying. So, what can we do about it? How do we solve our similar software problems? Well, the answer to these questions is, by using Software Design…

Composed Relationship Types Func<Owned<T>>

We often end up in situations where injecting a service using simple relationship types like Func<T>, Lazy<T>, Owned<T> and others, doesn’t serve the purpose. For instance, there can be a scenario where we want to control the lifetime of a component and yet the initialization of the component takes place at run time. Now, for such a scenario, injecting the service as either Func<T> or…

Func <T> – Dynamic Instantiation

Think of a scenario where we want more than one instance of a given service, or the decision, whether to instantiate a component is made at run time. For such scenarios injecting a service as a Direct or Lazy dependency will not be enough. However, injecting the service dependency as a Func do.   Using Func <T> Consider the following example, where we have a PaymentProcessor…

Owned<T> – Controlled Lifetime with Autofac

In general, Autofac controls the lifetime of components. It automatically disposes off all the disposable components at the end of lifetime scope. However, that may mean a component is held onto for too long. Generally speaking, an owned dependency corresponds to some unit of work performed by the dependent component.   Releasing an Owned<T> We use an owned dependency when we want to control the disposal…

Using Lazy<T, TMetadata> in Dependency Injection

We know how to use a Lazy<T> and IEnumerable<T>. Recently, I came across a piece of code that uses these two in combination. However, it doesn’t make sense if we simply inject a dependency of IEnumerable<Lazy<T>>. Therefore, we need some data to decide which one of the registered implementations, returned by the container, shall be instantiated. This data is generally known as the Metadata. In…

Direct Dependencies & Enumeration<T>

In this post, we will be talking about the two types of relationships, namely, direct dependency relationship and enumeration. In terms of a component A and service B, these relationships can be stated as the following: Direct Dependency – A needs B Enumeration – A needs all the kinds of B   Direct Dependency (B) It’s quite common to have a direct dependency relationship –  component A needs service B.…

Being lazy with Lazy<T>

Being lazy doesn’t refer to being lazy in life, but being lazy about the creation or instantiation of objects in our code. Sometimes, creation of an object is very costly. Now, when we say “costly”, we are not talking about money. Rather, we are talking about the memory consumed in the process and by the object itself. Consider a component A that uses a service…

Why Service Locator is an Anti-Pattern?

Previously, we saw how we can use a Service Locator in order to prevent ‘newing‘ of objects in our code. However, everything comes with a price. Though we will talk about this in detail, but just to give you a gist of it, a service locator is an anti-pattern as it hides the class dependencies.   Commerce Application Example The example we are following is…