Prev: Do You Get What You Measure?
Next: Difference between Design and Architecture
From: tailorma_de on 10 Apr 2006 08:00
It's easy to call a method for some objects that resist in a
collection. For example the Dispose method could be called for each
object in an array. But how could this be done for methods in a class
hierarchy?

Let me consider a virtual method myMethode as an example. A class A
gets implented and has the myMethode method. This method does the stuff
that it has to do for this class. Development on class A is completed.
Later, I create a class B that is inherited from A. Class B overrides
myMethode of Class A.

Usualy one would call the myMethode method of class A within the
myMethode method of class B:

class B extends Class A
{
public void myMethode()
{
super.myMethode()
}
}

However, is this how it should be? Now the myMethode method of class A
can only hope that the implementer of class B does not forget to call
the upper method.

So this is my question: How can I make sure that the myMethode method
of a base class is called if another class overrides the method? Or how
can I develop class A and can be sure that it always works, independent
from later developed, inhereting classes. And furthermore, to come back
to my initial question, how can I achieve that a certain method of
each 'layer' i.e. class of a class hierarchy is called? Independently
of the number of 'layers'.
I guess this may depends on the used programming language, but possibly
there's an abstract view.

My concrete case: I would like to implement an invalidating method that
sets all attribute to invalid values if it is called. A class should do
this only for itself. Later I might extend the class and then I want to
lean back with knowing that the base class works. Then I can implement
the invalidation method for the new class that only cares about this
class.
However, I would like to know it in general if this is possible or not.


Does this have anything to do with impl methods? Could anyone give a
brief exlpanation please.

Or do I consider anything in wrong? Is it the right way that a sub
class method has to call a base class method if it's required?

Thanks in advance,
Robert

From: I. Munoz on 10 Apr 2006 08:44
There's a design pattern, the "Template Method", which addresses the issue
you're describing. In brief, you create a method in the base class which
always does the prologue and the epilogue you want always to be done, and in
that method you call the virtual method that derived classes could override
in its entirety.



"tailorma_de" <tailormade(a)gmx.net> wrote in message
news:1144670438.413778.129920(a)j33g2000cwa.googlegroups.com...
> It's easy to call a method for some objects that resist in a
> collection. For example the Dispose method could be called for each
> object in an array. But how could this be done for methods in a class
> hierarchy?
>
> Let me consider a virtual method myMethode as an example. A class A
> gets implented and has the myMethode method. This method does the stuff
> that it has to do for this class. Development on class A is completed.
> Later, I create a class B that is inherited from A. Class B overrides
> myMethode of Class A.
>
> Usualy one would call the myMethode method of class A within the
> myMethode method of class B:
>
> class B extends Class A
> {
> public void myMethode()
> {
> super.myMethode()
> }
> }
>
> However, is this how it should be? Now the myMethode method of class A
> can only hope that the implementer of class B does not forget to call
> the upper method.
>
> So this is my question: How can I make sure that the myMethode method
> of a base class is called if another class overrides the method? Or how
> can I develop class A and can be sure that it always works, independent
> from later developed, inhereting classes. And furthermore, to come back
> to my initial question, how can I achieve that a certain method of
> each 'layer' i.e. class of a class hierarchy is called? Independently
> of the number of 'layers'.
> I guess this may depends on the used programming language, but possibly
> there's an abstract view.
>
> My concrete case: I would like to implement an invalidating method that
> sets all attribute to invalid values if it is called. A class should do
> this only for itself. Later I might extend the class and then I want to
> lean back with knowing that the base class works. Then I can implement
> the invalidation method for the new class that only cares about this
> class.
> However, I would like to know it in general if this is possible or not.
>
>
> Does this have anything to do with impl methods? Could anyone give a
> brief exlpanation please.
>
> Or do I consider anything in wrong? Is it the right way that a sub
> class method has to call a base class method if it's required?
>
> Thanks in advance,
> Robert
>


From: ralph on 10 Apr 2006 09:07
In Java the only way to prevent a subclass from replacing
myMethode() [override and don't call it from within the
overriden method] is to make myMethode() final. But then
the designer of the base class must provide hooks for
extending the method (see Template Method design pattern).

ralpe

From: tailorma_de on 10 Apr 2006 10:00
Thanks for you answers. However I think you get me wrong. Maybe you
should provide a small example.

BTW: Is it correct that the template method has something to do with
those impl methods (I guess 'impl' is just a convention for naming such
methods)?

Let me explain again. This is the usual approach I think:

/* Developed at first */
class A
{
private object something = <an object>;
public void doInvalidation()
{
something = null;
}
}

/* Developed a year later */
class B extends A
{
private object anotherSomething = <an object>
public void doInvalidation()
{
anotherSomething = null;
super.doInvalidation();
}
}

/* Developed another year later */
class C extends B /***** not A !!!!! *****/
{
private object totallyDifferentSomething = <an object>
public void doInvalidation()
{
totallyDifferentSomething = null;
super.doInvalidation();
}
}


The disadvantage is now that whenever I call doInvalidation on such an
object the most 'inherited' (sorry for my English if this is wrong)
method is called. In this example that in class C. It is not assured
that the invalidating method of class A is called anymore. Nor of B.

I think the template method is not right thing here since when I'm,
developing class A I do not know how many sub classes will be developed
in future. Something like a Impl method can only refer to one sub class
(if I understand the impl thing right). Correct?

So is there a way to make sure that the method of class A is called? I
think the missing thing is like the finally part of a try-finally
block. A couple of finally blocks may be executed if an exception
occures - not only one specific block. So it seems what I expect is
something like a 'multi-call'. I call the myInvalidation method of an
object and in each class (layer) the corresponding method is called.

Finally, all has something to do with vertical encapsulation. Sub
classes should only care about their things. Not the things above. So
making the private attributes protected and touching them from below
shouldn't be allowed. However, I started the discussion about protected
vs. private on this group some weeks ago and maybe this shows me that
the default use of private has disadvantes and is a wrong view on
inheritence.


Robert





I. Munoz schrieb:

> There's a design pattern, the "Template Method", which addresses the issue
> you're describing. In brief, you create a method in the base class which
> always does the prologue and the epilogue you want always to be done, and in
> that method you call the virtual method that derived classes could override
> in its entirety.
>
>
>
> "tailorma_de" <tailormade(a)gmx.net> wrote in message
> news:1144670438.413778.129920(a)j33g2000cwa.googlegroups.com...
> > It's easy to call a method for some objects that resist in a
> > collection. For example the Dispose method could be called for each
> > object in an array. But how could this be done for methods in a class
> > hierarchy?
> >
> > Let me consider a virtual method myMethode as an example. A class A
> > gets implented and has the myMethode method. This method does the stuff
> > that it has to do for this class. Development on class A is completed.
> > Later, I create a class B that is inherited from A. Class B overrides
> > myMethode of Class A.
> >
> > Usualy one would call the myMethode method of class A within the
> > myMethode method of class B:
> >
> > class B extends Class A
> > {
> > public void myMethode()
> > {
> > super.myMethode()
> > }
> > }
> >
> > However, is this how it should be? Now the myMethode method of class A
> > can only hope that the implementer of class B does not forget to call
> > the upper method.
> >
> > So this is my question: How can I make sure that the myMethode method
> > of a base class is called if another class overrides the method? Or how
> > can I develop class A and can be sure that it always works, independent
> > from later developed, inhereting classes. And furthermore, to come back
> > to my initial question, how can I achieve that a certain method of
> > each 'layer' i.e. class of a class hierarchy is called? Independently
> > of the number of 'layers'.
> > I guess this may depends on the used programming language, but possibly
> > there's an abstract view.
> >
> > My concrete case: I would like to implement an invalidating method that
> > sets all attribute to invalid values if it is called. A class should do
> > this only for itself. Later I might extend the class and then I want to
> > lean back with knowing that the base class works. Then I can implement
> > the invalidation method for the new class that only cares about this
> > class.
> > However, I would like to know it in general if this is possible or not.
> >
> >
> > Does this have anything to do with impl methods? Could anyone give a
> > brief exlpanation please.
> >
> > Or do I consider anything in wrong? Is it the right way that a sub
> > class method has to call a base class method if it's required?
> >
> > Thanks in advance,
> > Robert
> >

From: Dmitry A. Kazakov on 10 Apr 2006 10:21
On 10 Apr 2006 05:00:38 -0700, tailorma_de wrote:

> It's easy to call a method for some objects that resist in a
> collection. For example the Dispose method could be called for each
> object in an array. But how could this be done for methods in a class
> hierarchy?
>
> Let me consider a virtual method myMethode as an example. A class A
> gets implented and has the myMethode method. This method does the stuff
> that it has to do for this class. Development on class A is completed.
> Later, I create a class B that is inherited from A. Class B overrides
> myMethode of Class A.
>
> Usualy one would call the myMethode method of class A within the
> myMethode method of class B:
>
> class B extends Class A
> {
> public void myMethode()
> {
> super.myMethode()
> }
> }
>
> However, is this how it should be? Now the myMethode method of class A
> can only hope that the implementer of class B does not forget to call
> the upper method.

In general case you can't. You need method extension rather than complete
overriding. This is how constructors and destructors are composed out of
user-defined and predefined parts. Some languages offer extensions of
user-defined method.

> So this is my question: How can I make sure that the myMethode method
> of a base class is called if another class overrides the method? Or how
> can I develop class A and can be sure that it always works, independent
> from later developed, inhereting classes.

So general as you have it stated, it becomes equivalent to LSP. The short
answer is again - no way. However there exist patterns to make life a
little bit easier. Make myMethode class-wide (non-overridable.) Implement
it in A. Add a myMethode_Impl method called from there. A::myMethode_Impl
would be empty. B::myMethode_Impl could then be any. Of course, it works
only once for any two types in the hierarchy. If you need three types, you
should repeat the pattern. For four types you would need it tripled etc.

> And furthermore, to come back
> to my initial question, how can I achieve that a certain method of
> each 'layer' i.e. class of a class hierarchy is called? Independently
> of the number of 'layers'.

That's easy. See Ada's OO model, which ensures proper contracts. I.e.
methods implemented for A would never dispatch in their bodies.

> I guess this may depends on the used programming language, but possibly
> there's an abstract view.

Yes. The view is a strongly typed contract model. When you call to a method
(=a dispatching subprogram), the contract of its body is that you have the
object of exactly that type. I.e. if you landed in A::myMethode, then it is
A you are dealing with and nothing else. So when you call Foo from there it
shall not dispatch. Unfortunately most of OO languages did it wrong.

> My concrete case: I would like to implement an invalidating method that
> sets all attribute to invalid values if it is called. A class should do
> this only for itself. Later I might extend the class and then I want to
> lean back with knowing that the base class works. Then I can implement
> the invalidation method for the new class that only cares about this
> class.
> However, I would like to know it in general if this is possible or not.

It is possible with extensible methods. As a poor-man solution one could
implement invalidating via assignment. That would involve construction,
which is truly extensible.

> Does this have anything to do with impl methods? Could anyone give a
> brief exlpanation please.
>
> Or do I consider anything in wrong? Is it the right way that a sub
> class method has to call a base class method if it's required?

If your language does not support extensible methods and you badly need it.
You could consider replacing inheritance with aggregation + delegation. It
solves this problem but brings others, so you should really consider what
is worse.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
 |  Next  |  Last
Pages: 1 2
Prev: Do You Get What You Measure?
Next: Difference between Design and Architecture