Style/Structuring question: One vs. multiple global objects

[Deewiant]

Henning Hasemann wrote:
> Deewiant <deewiant.doesnotlike.spam at gmail.com> wrote:
>> Henning Hasemann wrote:
>>> Well the dependency-inversion thingy I found 
>>> (http://www.objectmentor.com/resources/articles/dip.pdf) was really 
>>> enlightning, maybe it helps you too. The basic idea is to misuse
>>> interfaces to simulate some of the benefits of C++'s header files.
>> It incurs runtime penalties and makes the code too cluttered, IMHO.
> 
> How big are those penalties? What are the extra steps your machine has
> to do when you compare acces through an interface with direct access to
> an object?

Probably tiny enough to be unnoticeable on even modern cellphones. I'm not sure
how inheritance works at the asm level. But it's a matter of principle: when all
I want is to remove dependencies, why do I need to create a slew of objects?

BTW, I just realized that when I mentioned "external interfaces" in my original
response I was alluding to the same kind of abstraction talked about in the
dependency inversion article, I just had the wrong terminology and forgot about
it later.

But I still don't advocate the kind of trash mentioned in the article. For
instance, there's code with a Button object and a Lamp object. Fine. But then he
goes on to create a ButtonClient and ButtonImplementation object? The hell?!
This, IMHO, leads to extremely complicated and obtuse interfaces like the Java
Platform APIs, where you have String, StringBuffer, StringBuilder, StringHolder,
etc. Or ImageInputStream, ImageInputStreamImpl, ImageInputStreamSpi, and the
same ImageOutput*, and ImageReader, ImageWriter, ImageReaderSpi, ImageWriterSpi,
 ImageReaderWriterSpi, ImageIO. So if you have no clue how to read an image from
a file there are 6 classes which might be able to do what you want, based on
their names.

Besides, for an application it makes less sense to do such than for a library.
Why make a ButtonImplementation and ButtonClient if you _know_ there's going to
be only one type of Button?

>> One thing I came up with was doing the "tile_and_entity.d" like so:
>>
>> module tile_and_entity;
>>
>> mixin(import(tile.d));
>> mixin(import(entity.d));
>>
>> Should work, but quite hacky.
> 
> Looks like a good idea for such situations with two modules that need
> each other, but if I understand correctly that wouldnt be able to
> handle all the things that DIP can, or?
> 

If you put your whole program in one module, it can! <g>

I'm not sure, but combined with the other techniques it should help things,
because that's the only case I've run into so far which can't really be solved well.

How would you do this with DIP?

-- 
Remove ".doesnotlike.spam" from the mail address.