From: Thorsten Ottosen (nesotto_at_[hidden])
Date: 2004-10-06 09:28:15
"John Torjo" <john.lists_at_[hidden]> wrote in message
| > |
| > | Another problem, IMO, is that client code will need to be more
| > | complicated, in order to find out if a value is null or not.
| > I don't understand that. One of the objectives of a null object is that
| > don't have to
| > worry about a value being null.
| I thought the purpose of null was to say "there's no object here. You
| can't do anything with me other than compare other pointers to me."
in the above a "null object" is an intance of a class and "null" is 0.
have you read the referenced paper?
| > | > | And, for each new (virtual) function you add, you should update the
| > | > | null_object class - which I think can turn into a maintenance
| > :(
| > | >
| > | > if your inheritance hierarchy contains N distinct classes, you would
| > to
| > | > add N implementations of that virtual function anyway, right?
| > |
| > | Not necessary... I can add one implementation, and some of those
| > | distinct N classes don't have to override it ;)
| > you could insert the null object class between the abstract base class and
| > leaf classes.
| I've never seen a design like this, would never do something like this
why not? It is quite common to have some class like this since we want to keep
base class fully abstract (as you would like to ensure minimal rebuilds).
| and I think I would really dislike any design that exibits this.
Anyway, I don't really see how adding *one* extra function is a maintenance
track of 0's seems much closer to a maintenance nightmare since it affects
*all* function calls on the container.
| > It might be worth to have the existing interface if users want to try
| > from vector<string> to ptr_vector<string>
| > just to see what happens.
| I don't like phrases like "hey, let's change from std::vector to
| std::map, just to see what happens" (I know I exagerated a bit). When
| you change something, you should have a reason, and know what you're
| doing (tradeoffs, etc.).
Ross Boylan thought it was important.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk