Style/Structuring question: One vs. multiple global objects

[Henning Hasemann]

Deewiant <deewiant.doesnotlike.spam at gmail.com> 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?

itile.d:
interface ITile { }

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

ientity.d:
interface IEntity { }

entity.d:
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:
http://keyserver.ganneff.de:11371/pks/lookup?op=get&search=0xDDD6D36D41911851
Fingerprint: 344F 4072 F038 BB9E B35D  E6AB DDD6 D36D 4191 1851