Re: NVI idiom and patterns such as Decorator and Proxy
On Jun 11, 7:54 pm, Christian Hackl <h...@sbox.tugraz.at> wrote:
James Kanze ha scritto:
On Jun 11, 3:17 pm, Christian Hackl <h...@sbox.tugraz.at> wrote:
The print() call in this piece of code is what bugs me. I cannot call
decorated_printer_'s doPrint() because it is non-public in this contex=
t,
but calling print() means that all parameter checking performed in
Printer::print() is uselessly duplicated, and it would be duplicated
again for all further decorators or proxies I might add.
Why do you say "uselessly duplicated"? Isn't PrinterDecorator a
client of Printer, as well as being an implementation? Is the
author of PrinterDecorator somehow protected from making the
same stupid errors as other clients might make, and so not need
the same protection.
Hmmm...
Good point, I guess. I must say I didn't think of it that way. So you
mean subclasses could do something like this:
void PrinterDecorator::doPrint(char *str)
{
decorated_printer_->print(0); // very contrived; but the method may
// do some more complicated stuff that
// could accidentally result in calling
// print() with a null pointer
}
Obviously, it could.
In the end, I think, the question is whether the decorators are
part of the same subsystem as Printer, developed with it, and
seen as an ensemble by other users, or whether they are
independent code, which is developed by other users. In the
first case, I'd probably go with an AbstractPrinterDecorator
base class, which was a friend of Printer; in the second, I'd
definitly require all accesses to Printer to go through the
standard public interface. I'm not about to let a user that I
don't know off the hook just because he chooses to name his
class Decorator:-).
In fact, I thought of a possible solution. If I gave Printer an
additional protected "print" method that took a Printer object and that
did *nothing* but delegate to doPrint(), I could call that protected
method from the decorator:
But this supposes that *all* Printer have the behavior of a
Decorator.
You mean because that protected method would be put in the base class
even though it's not part of the abstraction shared by all subclasses,
hence violating OOP principles?
Exactly.
I think I understand. You are right, on
second thought that isn't exactly very nice.
Putting it in Printer is probably not a good idea, but I can see
it (and have done something similar in the past) in an abstract
base class of the decorators, which is a friend of Printer.
I see. Well, thanks for all those insights ... I guess my error was
indeed that I considered "PrinterDecorator" a special client of
"Printer" regarding the function call, when it actually isn't.
Well, it might be. There is no one right answer. If it is a
special client, privileged in some way, then friend is an
appropriate solution.
But it's a question I would definitly ask myself. As I said
above, just because some random user decides to name his class
Decorator (or use my class in a design pattern of his own)
shouldn't give him any special rights or trust.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34