Dependency Injection: The Top Level

For many people, dependency injection implies the use of tools like Swing which allow configuration files to be used by a framework to sever the application code proper from direct dependency on concrete types.

Dependency injection is not restricted to that model. C++, like any language which supports polymorphism, can do dependency injection. (See Dependency Injection Principles, Practices, and Patterns, by Steven van Deursen and Mark Seemann, for extensive treatment of this general application of the term and for much useful coverage of details.)

The top level of the simple breviary app is, more or less, what dependency injection looks like.

int main(int argc, const char **argv)
{
JSBUtil::CommandLineOptions options(argc, argv);
if (options.isSingleArg("?"))
{
printUsage(argv[0]);
return 0;
}
std::unique_ptr<BreviaryLib::IDateCalculator> dateCalculator
= BreviaryLib::DateCalculatorFactory(options).create();

std::unique_ptr<BreviaryLib::IConfigSource> config
= ConfigFileName(options).generateConfig();

Log::ConsoleLogger logger;
std::unique_ptr<BreviaryLib::IPsalter> psalter
= BreviaryLib::PsalterFactory(*config).create(logger);

BreviaryLib::Kalendar kalendar(
*dateCalculator,
BreviaryLib::SaintsDaySetFactory(*dateCalculator, *config, logger)
.create());

BreviaryLib::FileHymnSource hymnSource(*config, logger);

BreviaryLib::CommandLineArgs args(options);

auto [day, month, ymd] = args.getOfficeDateInfo();

std::unique_ptr<BreviaryLib::IDayRecordSource> records
= BreviaryLib::DayRecordSourceFactory(*config, *dateCalculator, day,
month)
.create(*psalter);

std::unique_ptr<BreviaryLib::IEncapsulatedOfficeFormatter> formatter
= BreviaryLib::OfficeFormatterFactory(*config, options).create();

std::string name = kalendar.getFeast(day, month).name;
if (name.empty())
name = dateCalculator->getFerialName(day, month).first;
formatter->formatDayTitle(name);

BreviaryLib::FullOfficeGenerator generator(
name, dateCalculator->getDay(day, month),
dateCalculator->getSeason(day, month), config->getUse(), *formatter,
*psalter, hymnSource, args.isPriest());

BreviaryLib::FullOfficeAssembler(*records, *dateCalculator, generator,
kalendar, *psalter, config->getUse())
.assembleOffice(ymd, logger);
return 0;
}

The top level's functionality is almost all factories. (The FileHymnSource is an exception, but actually hides a delegation mechanism which makes it, essentially, an interface wrapper around a changeable delegate. It's a different way of doing the same thing, but the idiom is not that of dependency injection.)

Resources get set up based on configuration and command line. The actual types selected by those options are not visible at the top level: they are buried in the factories.

Once all the resources are set up, the last two explicit lines do all the real work, having the resources passed into then to use.

Note that this is, essentially, a demo program. It is fairly light on error reporting controls: normal output goes to the console, and so do any errors which generate exceptions. In a more production-style case there would be more error handling, and though the console application is genuinely useful a more user-friendly one would use a GUI to capture options and to display the resulting text. But that just makes the role that simple setup plays more visible, because there's much less to distract attention from it.

Comments

Post a Comment

Popular posts from this blog

Boundaries

Imagine that you have a well-designed application, possibly using dependency injection. It will almost always have a very thin layer visible in main() - capturing command-line parameters and environment variables, mainly[1], and then a call to an Application class which manages the rest of the initial logic - setting up resources such as logging, doing substantive validation of parameters, and creating and running the objects on the next level down which actually carry out the work of the application. This is simply following the SRP at a high level.
Read more

State Machines

Almost any program can be modelled as a state machine. I say "almost any" because it is, just, possible to think of a program which cannot easily be resolved into anything more than a one-state state machine. Consider a command interpreter with no support for loops or function definitions (like the old DOS command.com) and with no internal commands, only the ability to execute external commands. It loops forever and does only one thing for every line it reads.    If it does no error handling, the execution is a single line, a call to execve or one of its relatives. There are internal stages inside the C library call, but they are effectively invisible to the program.  However, it's not a very useful program. Neither is any version of HelloWorld. The echo application does have its uses. Once one gets beyond this, even simple programs have at least two states: setup and execute. A simple version of cp has to open two files for input and output before beginning to copy data....
Read more

Considerations on an Optimization

An application – actually, successive pair of applications – is meant to process (in the end) about three hundred or so entries to convert a simple markup into complex LaTeX markup. It also enhances the data with information drawn from a flat-file text database (i.e. literally a set of .txt files in a single directory). This application was originally written in rust, which is not my favourite language, but one worth exercising to a degree. The rust application covered a limited subdomain, and generally avoided unsafe rust code, although in some cases it had to use cell mechanisms which converted compile-time to runtime safety. The initial iteration had the text database as one large file, with some logic allowing for extended seeking through chapters. It soon became apparent, after extending my dataset to about twenty or so items, that this was going to result in an unacceptable runtime — it was taking longer to process than the later TeX processing took, and although in theory this w...
Read more