(eg
Song : ISongSetup
ISongSetup : ISong
ISongFactory)

If you dont like exposing the IOC Container to the factory, just create your own wrapper around the container.

perhaps you could split it into two objects. SongInfo which is newable, and a Song which is also newable but which you get asking the repository

Song s = songRepository.get(new SongInfo());

This way you have a clear separation between the object which you can create and which needs to be populated by the system.

I believe that that injectable option that Misko is describing isn’t to make the Song an injectable but is instead to inject an injectable (in the form of a Song factory) that will then create the Song.

The first option (pass the loader into each method) does not appeal to me much for the stated reasons. But I think that the other approach (inject the loader into Song) is flawed as well. Please correct me if I am wrong:

a) The Song is an Injectable now, but it has state – Seems wrong to me. Is it ok?

b) The Song does not fit to any DDD category now – The Song class with the Loader field reference is neither a service (it has state and overall it does not look like a service) nor an entity (or is it?). Will this mixed nature of the Song class backfire at some point?

c) We are breaking our ground rules here – “…Injectable can never ask for a non-Injectable (Newable) in its constructor…”. When the Song was a Newable, we could easily pass primitives or other newables to its constructor to initialize it. But this should be a ‘NO NO’ for Injectables.

All the three points seem to be intertwined and maybe it’s just three guises of the same issue. Anyway I am baffled. (I hope you say that my conclusions are wrong. Otherwise it would seem that the newable/injectable scheme cannot be fitted to a very simple model?)

Your analysis of the problem is very good. What you are asking for is not possible, since new-ables can not have a field reference to an injectable. You have two choices

1) pass the loading service into each method. (That seems like a bad idea, and puts too much work on the user of your class, and probably breaks Law of Demeter)
2) change the object from newable to injectable. So the user will say songFactory.create() rather then new Song(). The factory can then set the field.

There really are no other options, unless you go to the dark side and create a global variable, which is always a bad idea.

Let’s continue in your example and take the Song as an entity. Song has member properties Song.id (unique song id), Song.loaded (boolean) which indicates if the song has been loaded (e.g. from DB or disk). I also have a field reference to Loader object which does the actual loading (I know this is bad). And finally there are class members for other song properties: song data, author, year, etc.

Every setter and getter first checks if the object has been loaded and if not it calls this.loader.load(this). This way I have lazy loading transparent to the client and I can use very ‘light’ Song objects in my system, which get loaded only when needed. Until then they are just empty shells with only id set.

Now I want to factor out the Loader service object (injectable) from the Song (newable) and keep the lazy loading transparent to the client (so that client can call e.g. song.getAuthor() as usual). And I am stuck here. How to invoke the loader service object from getters and setters and not keep a field reference to it in Song? It would be possible to pass the loader to every getter and setter (string Song.getAuthor(Loader loader)) but it seems a lot of hassle and it complicates things for the client.

Is there a better way? Or am I missing something completely? Thanks for any hint.

Note 1: Sorry for my terminology and notation. I am a PHP guy and I am just guessing the Java equivalents.

Note 2: This blog is excellent! Thanks Misko. I wish this kind of knowledge was available also in the PHP world.

I am not a C++ expert, but what you are proposing sounds like the right thing to do. I think you are on the right track.

I’m a big fan of the CleanCodeTalks presentations and follow their guidelines when I’m writing Java code.

I’d like to apply these same guidelines when writing C++ code.

In particular I’m looking to understand the best way to follow the dependency-injection and testability guidelines in order to:

a. structure code to have object construction kept inside factories,

b. keep calls to ‘new’ out of constructors,

c. make it obvious to any user of a class
what the dependencies of the class are
just by the user looking at the parameter list
of the constructor.

My question is what is the best way to design a C++ class which has a field that has a “complex-type”, as the constructor for my class will have to invoke the constructor for the field.

I’ve reviewed the guidelines and here’s what I’m thinking.
To follow these guidelines I should:

1. replace fields that have “complex-type” with a “pointer-to-complex-type”

2. in the constructor declare a parameter of type “pointer-to-complex-type”.

3. in the factory use ‘new’ to construct an object of type “pointer-to-complex-type”
and pass that to the constructor of “my-class”.

[ IIRC, I think the guidelines recommended that if the field had a "complex-type" that was a collection type - like std::vector - then there's no need to construct it externally from "my-class" constructor. ]

I assume that as a general rule it wouldn’t be good design to keep the field as a “complex-type” and have the constructor declare a parameter of “ref-to-complex-type” as the copy-constructor for the “complex-type” is likely to be too expensive or possibly prohibited by the “complex-type” declaring it private.

As an example, for a ‘MyFileLogger’ class that needs to access a ‘std::ofstream’ object, if I follow the guidelines (a, b, c) then the ‘MyFileLogger’ class that I might have written as:

class MyFileLogger
{
std::ofstream theFileStr;
….
public: MyFileLogger(const char* aFilename) : theFileStr(aFilename) {}
….
};

I’m guessing that I should instead write it as:

class MyFileLogger
{
std::ofstream* theFileStr;
…
public: MyFileLogger(std::oftream* aFileStr) : theFileStr(aFileStr) {}
…
};

and construct it in the factory method:

const char* theFilename = “logfile.txt”;

// might be wise to wrap the ‘std::oftream*’ in a smart-pointer
// object to manage it’s destruction properly.
//
std::ofstream* aFileStr = new std::ofstream(theFilename);

MyFileLogger theFileLogger(aFileStr);

I would welcome your advice on whether this is the right approach.

Cheers,

Steven

I would solve this in this way

interface Output;
class Speaker implements Output;
class Headset implements Output;
class OutputSelector(Speaker, Headset) implements Output;
class MusicPlayer(Output);

s = new Speaker()
h = new Headset()
os = new OutputSerector(s, h);
mp = new MusicPlayer(os);

os.seletOutput(…);
wp.play();