|
|
Posted by Steve on 12/05/07 05:05
"Willem Bogaerts" <w.bogaerts@kratz.maardanzonderditstuk.nl> wrote in
message news:4753bcbd$0$239$e4fe514c@news.xs4all.nl...
>>> The main problem is that they do not abide the Law of Demeter: they do
>>> not come in through the interface of your objects.
>
>> Willem - could you explain that last sentence, please?
>
> The Law of Demeter is a set of rules to reduce tight coupling in
> object-oriented programs.
>
> Passing the necessary related objects through the interface (methods,
> constructor) ensures that your object stays modular. This has a few
> advantages: they can be used in more general applications and (even
> better) they can be tested with unit tests.
>
> Suppose you have an object that references the Singleton "Database". You
> would have a hard time to write a unit test that provides a mock
> database or a test database object, because the object does not recieve
> a database; it will locate that itself. And there is the problem. The
> object is _hardwired_ to the Database object.
not a good example. you assume we construct 'database' the same way you
would. a singleton is instanciated upon the first call to one of it's
interfaces. giving that interface a param, like a connection string, would
not only instanciate the object but let it connect and utilize a db.
i don't understand 'because the object does not receive a database'. a db
class SHOULD locate that itself, imo...that goes to encapsulation. in fact,
if you don't let the db class handle everything about the db to which it
communicates, you actually tightly couple some other facility to work in
conjunction with the db class.
again, not a good example.
> Or suppose you want the same object, but now for a different database.
> You would have the same problem.
no problem at all.
db::initialize('server name', 'db name', 'user', 'password',
dbTypes::mySql);
or you can name 'initialize' to 'connect'. dbTypes::mySql gives a namespace
to supported db types and is itself, a singleton.
your base db object and specific implementations implements a db interface
and, when you 'connect', your main db object creates a specific instance of
the db type you want. there's no problem there *at all*.
> By the way, because of the amount of legacy code that I encountered that
> were completely hardwired all around, I wrote a pattern to migrate the
> use of such a Singleton to something more testable: the Half-a-Singleton
> pattern (see http://www.w-p.dds.nl/pathalfs.php?STYLE=4)
interesting. singletons weren't actually supported in php < 5. there is a
way to mimic it in previous versions, but an upgrade and running a script
that uses the convention will quickly show you where the problem is...by
kindly blowing up. :)
> I often draw an analogy of objects to electronic components: if you see
> a wire welded from your CD drive to the speaker, for instance, they have
> effectively become one component. If it is plugged, they are still
> separate, but connected. The interface of an object is in a lot of ways
> like a plug in hardware.
sorry willem, this just shows you haven't gotten your EE credentials. the
wire and the cd are seperate components. you may well need to replace either
one, however, replacing one doesn't require altering the other. finally,
it's called 'soldering'...not welding. and any less-than-dim person would
know to *solder* a connector to the wire and one to the cd drive...and yes,
the connectors are separate components.
an interface less like a plug in hardware than it is a tool in a swiss army
knife. :)
Navigation:
[Reply to this message]
|