I've been trying to follow the principles of Dependency Injection, but after reading this article, I know I'm doing something wrong.
Here's my situation: My application receives different types of physical mail. All the incoming mail passes through my MailFunnel object.
While it's running, MailFunnel receives different types of messages from the outside: Box, Postcard and Magazine.
Each mail type needs to be handled differently. For example, if a Box comes in, I may need to record the weight before delivering it. Consequently, I have BoxHandler, PostcardHandler and MagazineHandler objects.
Each time a new message comes into my MailFunnel, I instantiate a new corresponding MailHandler object.
For example:
class MailFunnel
{
void NewMailArrived( Mail mail )
{
switch (mail.type)
{
case BOX:
BoxHandler * bob = new BoxHandler(shreddingPolicy, maxWeightPolicy);
bob->get_to_work();
break;
case POSTCARD:
PostcardHandler * frank = new PostcardHandler(coolPicturePolicy);
frank->get_to_work();
break;
case MAGAZINE:
MagazineHandler * nancy = new MagazineHandler(censorPolicy);
nancy->get_to_work();
break;
}
}
private:
MaxWeightPolcy & maxWeightPolicy;
ShreddingPolicy & shreddingPolicy;
CoolPicturePolicy & coolPicturePolicy;
CensorPolicy & censorPolicy;
}
On one hand, this is great because it means that if I get five different pieces of mail in, I immediately have five different MailHandlers working concurrently to take care of business. However, this also means that I'm mixing object creation with application logic - a big no-no when it comes to Dependency Injection.
Also, I have all these policy references hanging around in my MailFunnel object that MailFunnel really doesn't need. The only reason that MailFunnel has these objects is to pass them to the MailHandler constructors. Again, this is another thing I want to avoid.
All recommendations welcome. Thanks!
This looks more like a factory to me. Move the invocation of the get_to_work() method out of the invocation and return the handler. The pattern works pretty well for a factory.
class MailHandlerFactory
{
IMailHandler* GetHandler( Mail mail )
{
switch (mail.type)
{
case BOX:
return new BoxHandler(shreddingPolicy, maxWeightPolicy);
break;
case POSTCARD:
return new PostcardHandler(coolPicturePolicy);
break;
case MAGAZINE:
return new MagazineHandler(censorPolicy);
break;
}
}
private:
MaxWeightPolcy & maxWeightPolicy;
ShreddingPolicy & shreddingPolicy;
CoolPicturePolicy & coolPicturePolicy;
CensorPolicy & censorPolicy;
}
class MailFunnel
{
MailHandlerFactory* handlerFactory;
MailFunnel( MailHandlerFactory* factory ) {
handlerFactory = factory;
}
void NewMailArrived( Mail mail ) {
IMailHandler handler = handlerFactory.GetHandler(mail);
handler.get_to_work();
}
}
When you see that switch statement, think polymorphism. This design can only be extended by modification. I'd redo it in such a way that I could add new behavior by adding classes. It's what the open/closed principle is all about.
Why can't you just have three methods that are overloaded which take the different types of mail, and then do the appropriate thing? Or have each type handle itself.
In fact, if you have something like type, chances are you should in fact have different types.
Basically do the following:
1) Make the Mail class abstract.
2) Create a three sub classes of mail, Box, PostCard, and Magazine
3) Give each subclass a method to handle mail, or centralize it in a separate HandlerFactory
4) When passed to the mail funnel, simply have it call the handle mail method, or have the HandlerFactory pass it the mail, and get the appropriate handler back. Again, rather than having awkward switch statements everywhere, use the language, this is what types and method overloading is for.
If your mail handling becomes complex and you want to take it out, you can eventually make a mail handler class and extract those policies into that.
You can also consider using a template method, because the only real difference between each of those seems to be the handler you instance, maybe you could simplify it, such that the mail type determines the handler, the rest of the code is basically the same.
Interesting that you're applying dependency injection to a C++ project; it has been done elsewhere, a quick Google search finds a Google code project Autumn Framework.
But the answer by tvanfosson is what I would suggest trying first, before adopting a new framework.
Related
I need to write an application using C++ which handles input signal from various sources and end up with something like this:
InputManager: handle input signals and convert them to messages.
Processor: it will receive all messages from the input. Put it in a
queue and operating one by one.
Other modules.
// define states of the instance
enum class State {
A,
B,
C,
....
};
// handle input message, all the message passed to the Processor queue should be redirect to this function.
void onInput(std::shared_ptr<Message> msg) {
switch(msg->mgsId) {
case 1:
// do something
break;
case 2:
// do something
break;
default:
break;
}
}
....
The thing is, the Processor Class getting bigger and bigger when the number of signals increases; and if I have to do something break the flow like waiting for a specific event before continue operating, the code becomes very hard to read.
I know it's a very newbie question. But I have no idea how to restructure my code in a readable way.
Use the following answer (which I took from a comment by Aconcagua):
I'd write one class per signal type, create one class instance per
concrete signal and have all of them keep a link to the single queue
instance. If you give the classes one common base class, you might
even put all of them into a single std::vector (not by value, though,
otherwise you run into object slicing). – Aconcagua
I'm trying to create a performance monitor of sorts to run on a Particle board (STM32 based). I'm used to programming in c so the OOP approach is a bit new but I think it would fit well here.
For the purpose of this question let's assume I have two types of monitors:
Frequency. The application can call a "tick" method of the monitor to calculate the time since it last ran and store it.
Period- call a "start" and "stop" method of the monitor to calculate how long a process takes to run and store it.
What I would like to do is to create instances of these monitors throughout my application and be able to report on the stats of all monitors of all types from the main module.
I've read about the singleton design pattern which seems like it might be what I need but I'm not sure and I'm also concerned about thread safety with that.
I'm thinking I will create a "StatMonitor" class and a derived class "FrequencyMonitor" and "PeriodMonitor". Monitor would be a singleton and everywhere I wanted to create a new monitor I would request an instance of "Monitor" and use that like so:
freqMonitor * task1FreqMonitor = StatMonitor::GetInstance()->Add_Freq_Monitor("Task1");
The StatMonitor would track all monitors I've added and when I wanted to print the stats I could just call the printAll method which would iterate it's array of monitors and request their results like so:
StatMonitor::GetInstance()->PrintAllStats();
Am I going down the right path?
Your path sounds good, except that FrequencyMonitor and PeriodMonitor should not derive from the class that "manages" all these monitors (let's call it MonitorPrinter).
MonitorPrinter should be a singleton and could look like this:
class MonitorPrinter
{
public:
static MonitorPrinter& getInstance()
{
static MonitorPrinter monitorPrinter;
return monitorPrinter;
}
void printAllStats()
{
for (const auto& [_, frequencyMonitor] : _frequencyMonitors)
frequencyMonitor.print();
for (const auto& [_, periodMonitor] : _periodMonitors)
periodMonitor.print();
}
FrequencyMonitor& getFrequencyMonitor(std::string name)
{ return _frequencyMonitors[name]; }
PeriodMonitor& getPeriodMonitor(std::string name)
{ return _periodMonitors[name]; }
private:
MonitorPrinter() = default;
std::map<std::string, FrequencyMonitor> _frequencyMonitors;
std::map<std::string, PeriodMonitor> _periodMonitors;
};
Demo
(The const auto& [_, frequencyMonitor] is a structured binding).
FrequencyMonitor and PeriodMonitor should not have anything to do with singletons, and from your description, they need not be part of a class hierarchy either (as they have different interfaces). If you want, you can prevent users (other than the MonitorPrinter) from instantiating these classes using other techniques, but I won't elaborate on that here.
In short, there is no need to use OOP here. Use a singleton to provide (and keep track of) the monitors, and implement the monitors to your liking. Be wary of thread safety if this is relevant (the above is not thread-safe!).
Developing a Drupal 8 example site, I have declared block in a module, and I want to do a few things with this block, like check the route and show this block only on nodes, also check if the user has permissions to see this block, and the content of the block is a form which I had defined in another place of the module.
I don't want to get the classes/services that I need in a static way, I want to use dependency injection to get those classes because it is technically better to decouple code and allow better testing.
Now "create" method and the "constructor" method on the block are like so:
<?php
public static function create(ContainerInterface $container, array $configuration, $plugin_id, $plugin_definition) {
return new static(
$configuration,
$plugin_id,
$plugin_definition,
$container->get('current_user'),
$container->get('form_builder'),
$container->get('current_route_match'),
$container->get('access_check.permission')
);
}
public function __construct(
array $configuration, $plugin_id,
$plugin_definition,
AccountProxyInterface $user,
FormBuilderInterface $formBuilder,
ResettableStackedRouteMatchInterface $route,
AccessInterface $access
) {
parent::__construct($configuration, $plugin_id, $plugin_definition);
$this->user = $user;
$this->formBuilder = $formBuilder;
$this->route = $route;
$this->access = $access;
}
Is this the correct way to do this? Maybe I'm doing too much in the block file? Should I create a service to move the logic to another place? Probably I would need more things, which means using more services, and my "create" and "constructor" methods are growing in parameters. Is this the correct way to do it? Thanks.
When you have to inject many services in one class, be it a controller or a block, it usually tells that the class is not well designed because you are (probably) trying lots of things in just one class.
However, I've seen many controllers which inject multiple services in their constructors, so it doesn't seem an unusual practice anyway. "Every rule has an exception".
In the end, I think it is a matter of balance, build a class that is responsible for doing one logical thing, and its dependencies in the same way.
I'm trying to get my feet wet with ASIO and thought a good first project would be a simple web crawler: download an html page, find the links in it, download all the links.
I have tried modifying the ASIO http client example to use enable_shared_from_this instead of a raw pointer so that I can spawn new async task from within the handler of the previous task without having to worry about the resources getting deleted in the middle of my work.
The problems start when I tried to subclass my client to handle different pages in different ways. The compiler complains that the type of the shared_ptr doesn't match the type of this.
Does anybody know how this is solved? I haven't been able to figure it out by myself.
This is unrelated to Asio.
If you inherited a base class from enable_shared_from_this, but need it in the derived one, use boost::static_pointer_cast:
struct base : enable_shared_from_this<base>
{
};
struct derived : base
{
shared_ptr<derived> shared_from_derived()
{
return static_pointer_cast<derived>(shared_from_this());
}
};
Recently I was listening to a tech talk on clean coding. The speaker was a test engineer, who emphasized on avoiding the "if" statements in the code and use polymorphism as much as possible. Also he advocated against global states.
I quite agree with him, yet i need a clarification on replacing the global state and "if" statement using polymorphism for the below scenario,
I have 3 states in my document. I want to change the state of the UI components based on the document state. Right now, i use "if" blocks and an enumeration type holding the current state of document to transition the states of UI components.
eg:
enum DOC_STATE
{
DOC_STATE_A = 0,
DOC_STATE_B,
DOC_STATE_C
};
void QMainWindow::handleUi(_docState)
{
switch(_docState)
{
case (DOC_STATE_A):
{
menu.disable();
....
}
case (DOC_STATE_B):
{
menu.enable();
...
}
case (DOC_STATE_C):
{
...
}
}
I think i can have separate child classes for each state and have the handleUI() method in each class. Calling handleUi() method calls the right method call. But say i maintain these objects in my doc, how do i switch from one object to other each time there is a transition in state?
In other words, how to handle UI transition by tracking the change in state of document without using a global state and "if" or Switch statements?
I use Qt. Thanks.
If you are using Qt, take a look at The Qt State Machine Framework and the State Machine Examples. No need to re-invent the wheel when your framework already provides a sports car :)
I don't think I understand the problem because the answer is too trivial: you replace the pointer to your state instance with a new state instance and discard the old one.