Autofac gives us all the advantages that I mentioned in the previous article. We can forget in the beginning about our container that we wrote. He does not reach autofac to his feet :) let’s see what’s so interesting about autofac. Let’s start with the basic logging and creation of class instances.
The question “Why not use my own container?” I answered in the previous article about containers in the introduction.
In the previous article we parted in a lot of stress :) But it was the intended effect, how tests can make the design more difficult … NOT TRUE !!! This results only through ignorance. We had three issues to solve.
We already have the code of this game somewhat orderly and specific functionalities drawn for separate classes.
Before we go to the article, I would like to clarify the issues of character classes. One of the readers mentioned that the character classes are unnecessary, that it is better to do the functions because these classes only change their state and do not have a separate logic, he is right. …
First we have to refactorize this code to have what to inject, so you can come to the conclusion that we use a dependency injection to and satisfy solid rules, which means that dependency injection somehow suggests that we follow these rules.
At the beginning, let’s see how the classes of the characters have changed, namely the Thief, Mage, Barbarian and Paladin classes, and as we remember in that example, these classes inherit from the concrete class and should not. I dare even think they can not, amen.
I built a simple small application running in the console on which we will work through the entire dependency injection department, I specifically wrote it as if it would do a novice developer, i.e. how you can guess this code will be untestable and very unreadable, I will throw the code right away :)
It is an application or rather a web game prototype that first registers the user in the player database and later in this game we make our own character, I did not want to throw in some complicated example, some application that uses the map I…
As someone once said, “Each of us will sooner or later hear the word SOLID, some of our friends will say that our code should be SOLID”
Dependency Injection is very much related to the last principle of dependency inversion, which “book version” sounds like this:
High-level modules should not depend on low-level modules — the relationships between them should result from abstraction.
Abstractions should not depend upon details. Details should depend upon abstractions.
Inversion of control is also a very important term related to Dependency Injection. Such my short explanatory rule inversion of control is “In the classic application…
Hi everyone, after a long break in writing, there is a lot of material to describe and a lot has happened to me all this time 🙂 This article will be a continuation of the singleton, that is part two can be said, the first link is here http://devman.pl/programtech/design-patterns-singleton/ I thought that the first part about singleton is too short and many issues related to the singleton is not explained, you have before you the second part of the singleton, which I think clearly explains the topic 🙂
We will also use unit tests today to demonstrate how they work…
The main goal of the Strategy pattern is described in the picture below:
In the simplest terms, the state pattern is that if the internal state of the object changes (we can rely on one of the variables of this object, eg on the bool type) from truth to false then we change the behavior of this object.
The most important elements in implementing this pattern are: