Style/Structuring question: One vs. multiple global objects

Henning Hasemann hhasemann at
Tue Jul 3 00:03:07 PDT 2007

Deewiant <deewiant.doesnotlike.spam at> wrote:
> 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

Okay, fully agreed. I wouldnt not follow this pattern with *that*
enthusiasm. Atm I try to find as few cases as possible where it is
needed to break my cycles *and* I try to only create interfaces that
have a meaning that is distinguishable from the original class in
meaning as well as in naming.

For example, before I had:

class Thing { }
class Character : Thing { }

now it will become:

interface ISceneEntity { }
class Thing : ISceneEntity { }
class Character : ISceneEntity { }

(which works since there is nearly no functionality in Thing)

> 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.

Ack. Thats something nobody wants. (Except the javaists maybe)

> 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?

Another ack, but what I'm writing is a library ;-)
> If you put your whole program in one module, it can! <g>

Does putting everything in one module really avoid all forward
reference issues?

> 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?

interface ITile { }

import itile;
import ientity;
class Tile : ITile { /* use entity via interface here */ }

interface IEntity { }

import ientity;
import itile;
class Entity : IEntity { /* use tile here via interface */ }

Yes, for such a case your pattern seems better at least if you dont
find other reasons for creating IEntity and ITile.

GPG Public Key:
Fingerprint: 344F 4072 F038 BB9E B35D  E6AB DDD6 D36D 4191 1851

More information about the Digitalmars-d-learn mailing list