I already talked about the subject of Dependency Inversion here and of course the way to implement Dependency Inversion is to use Dependency Injection.
First let’s go back to what is Dependency Injection. Dependency injection is used to inject real implementations into a class that uses abstract interfaces instead. So let’s say a Presenter Class uses of View Class. If you are using SOLID, then your Presenter Class will “see” the View Class thru an abstract interface (a contract) and thus the dependency to the View Class will be reversed as you can see in the Fig-1.
When this is done, you can “insert” whatever View in the Presenter as long as it respects the View Protocol contract.
To do the insertion, you will use Dependency Injection. There are 2 types of Dependency Injection :
Of course it’s impossible to answer this question in one single post, or even in one single book (the best known book for this is the one from M.Feathers, “Working Effectively with Legacy Code” that you can buy here). In fact it’s impossible to answer this question at all as it will all depend on what is the current status of what you have to refactor and every situation is specific. But still, there are few things that can be said and that can/should be applied when it’s about refactoring. Continue reading “Help, I need to refactor, but where should I start ? (SDP to the rescue)”
For this week, I want to give a clear example of the type of architecture that I’m trying to push on the projects I work on. Some of you probably already know VIPER. It tends to become a classical architecture in iOS development and in other platforms like Android. VIPER goes for :
V : View
It was inspired by the Onion Architecture or Clean Architecture pushed by Robert Cecil Martin, more known as Uncle Bob.
You probably use models in your code every day and so do I. The major problem with a model is that it will surely evolve. It will evolve because the business will require a change or because a new feature will be needed and thus will require the model to change or because the api will have new fields or different informations. The best case is that this evolution will not touch your code, the worst case is that this evolution will destroy your code. But in any case you depend on this model and this is generally bad… Continue reading “Protect yourself from models !”
Dependency Inversion is a very simple concept : “if a class B depends on a class A, you can revert this dependency by generating a contract that class A must implement”. Thus you became responsible for this contract and you do not depend anymore on anyone because they will have to implement your contract and not you… Continue reading “What is Dependency Inversion ?”
One of the first thing that made me think that architecture mattered was when I discovered what Dependency Inversion was all about.
First I was generally mixing Dependency Inversion and Dependency Injection. For sure you better associate them but they can be used independently if you want. To me Dependency Injection was about : I want to have a class and be able to use it with what I want and I want to be the master of this. It was also the D letter in the acronym SOLID (this is wrong if you don’t know… 🙂 D is for Dependency Inversion). I was even pushing this during interviews and I was fully wrong… Continue reading “How I discovered Dependency Inversion…”