How to find a girl or dependency injection pattern in action. Part II

Vasily Pereverzev — Tue, 07 Jan 2020 15:50:44 +0000

Implementation

In the previous part, we introduced the basic concepts of the dependency injection pattern.

Now it is time to make out an example implementation (in this example, I use the Qt / C ++ bundle). Let's imagine a basic simple case.

What can we see here?

Module A

Interface IDummyInterface
Service DummyService that implements interface IDummyInterface

Module B

ServiceInjector - the "dating agency".
Picks up metadata (contacts) of the necessary service from ServiceResolver (agency database) and injects it in the client
ServiceResolver - the database of our "dating agency". Able to register services and submit their metadata (contacts) for subsequent injection

Module C

DummyClient - client that needs the functionality declared in IDummyInterface. At the same time, he doesn't want to know anything about the details of the implementation of DummyService

Step 1

Add to the IDummyInterface interface the ability to represent ourselves through the unique identifier QUuid.

#include <servicesresolver.h>

class IDummyInterface
{
public:
    INTERFACE_ID

    virtual void doSomething() = 0;
};

The implementation of the macro is extremely simple - just creating a unique identifier.

#define INTERFACE_ID                             \
    public:                                      \
    static const QUuid interfaceId() {           \
        static QUuid id = QUuid::createUuid();   \
        return id;                               \
    }                                            \

Step 2

ServicesResolver::registerService<IDummyInterface, DummyService>(
[]() -> DummyService* {
    return new DummyService();
});

// in case of singleton

ServicesResolver::registerService<IDummyInterface, DummyService>(
&DummyService::instance
);

Step 3

Inherit our client from ServiceInjector:

#include "serviceinjector.h"

#include "interfaces/idummyinterface.h"

class DummyClient : public ServiceInjector<IDummyInterface>
{
...
};

Inject dependency to the client:

#include "serviceinjector.h"

#include "interfaces/idummyinterface.h"

class DummyClient : public ServiceInjector<IDummyInterface>
{
    INJECT(IDummyInterface, dummyService)

    .....
};

The INJECT macro implementation is a simple setter and getter.
The first parameter is the type of interface.
The second parameter - an alias for the service in the scope of the client, needed for simplify calls of a service.

#define INJECT(INTERFACE_NAME, ALIAS)                              \
public:                                                            \
    INTERFACE_NAME* ALIAS() {                                      \
        return ServiceInjector<INTERFACE_NAME>::getService();      \
    }                                                              \
                                                                   \
    void set##ALIAS(INTERFACE_NAME* impl) {                        \  
        ServiceInjector<INTERFACE_NAME>::setService(impl);         \
    }                                                              \

The full implementation details and code-snippets can be found at our open-source project:

musescore / MuseScore

MuseScore is an open source and free music notation software. For support, contribution, bug reports, visit MuseScore.org. Fork and make pull requests!

Music notation and composition software

MuseScore is an open source and free music notation software. For support, contribution, and bug reports visit MuseScore.org. Fork and make pull requests!

Features

WYSIWYG design, notes are entered on a "virtual notepaper"
TrueType font(s) for printing & display allows for high quality scaling to all sizes
Easy & fast note entry
Many editing functions
MusicXML import/export
MIDI (SMF) import/export
MEI import/export
MuseData import
MIDI input for note entry
Integrated sequencer and software synthesizer to play the score
Print or create PDF files

More info

License

MuseScore is licensed under GPL version 3.0. See license file in the same directory.

Packages

See Code Structure on Wiki

Building

Read the Compilation section of the MuseScore Wiki for a complete build walkthrough and a list of dependencies.

Getting sources

If using git to download repo of entire…

View on GitHub

How to find a girl or dependency injection pattern in action. Part I

Vasily Pereverzev — Tue, 07 Jan 2020 15:50:39 +0000

Intro

Many large projects as they grow inevitably face the following list of problems:

Сomplexity

Concentration of motley logic in one place, blurred responsibility, classes of several thousand lines. Familiar symptoms right?

To combat the high complexity of logic, there is a good old divide-and-conquer technique. As a rule, complex things consist of a subset of simple ones that is is much easier to understand.

Coupling

Changed or added logic in one part of the application, but broke in completely different one (maybe even completely unrelated at first glance).
Classes interact very closely with each other and each of them strictly relies on the implementation of its neighbors.

Lovely dependency injection

There are many technical articles on this subject, but let's have some fun and try to dilute the explanation with exaggerated analogies.

Meet, ladies and gentlemen, the very abstract Peter:

As you can see from the illustration, Peter is a pianist with a great sense of humor. Pretty good guy, huh?

However, Peter does not have enough female attention for complete happiness. So he decides to find a girl.

Peter wanders around clubs and pubs, attends theme parties, tries to seduce female colleagues. But all to no avail... The perfect, the NECESSARY girl has not yet been found...

Finally, tired and sad Peter decides to abandon these attempts and focus on his work.

But the dream of great love nevertheless glimmers in him and he decides to APPEAL to a specialized dating service to shift burden of searching the second half for SPECIALLY TRAINED people.

When addressing, Peter fills out a form in which he describes in detail the girl of his dreams.

It turns out that Peter is not only a wonderful musician, but also a lucky one.
Because the perfect candidate was quickly found in the agency database. In accordance with all the wishes of Peter.

The agency sends the girl’s contacts to our musician. Well, then magic of love, romance and "they lived happily ever after."

Take off the mask

Well, now it's time to take off the masks and move on to the realities of development in terms of Dependency Injection:

Client - our Peter, a consumer who needed some value
Interface - the form that Peter filled out
Injector - a dating agency that picked up a girl for Peter
Service - the beloved of Peter, whom he has sought for so long
IoC(inversion of control) container - the agency's database

Please note that in the first case, Peter acted ACTIVELY and independently tried to find his Service, but at the same time he completely forgot about his main activity.

He later delegated responsibility to the agency and spoke in a PASSIVE position.
All he did was declare his needs(INTERFACE) and leave contact details for communication.
So the special service(AGENCY) easily fulfilled its only responsibility - to find a couple for Peter.

Conclusions

This pattern allows to separate and isolate clients from dependency implementation. All it needs is an interface. Clients can be concentrated on their own activities, because all dirty work would be done automatically by special INJECTOR service beyond the scope of a CLIENT.

Additionally, an isolated class is very easy to test with unit tests, because under the mask of the interface you can enclose MOCK or FAKE.

Forem: Vasily Pereverzev