|
|
Posted by Jerry Stuckle on 07/23/07 19:25
Michael Fesser wrote:
> .oO(Jerry Stuckle)
>
>> In a true OO system, the parent is initialized before the child. In
>> true OO languages such as Java and C++, this can be performed by passing
>> a parameter to the base class.
>>
>> It's incorrect here because you 1) are not initializing the base class
>> first, and 2) are exposing the base class implementation.
>>
>> Now what happens to the derived class(s) if you change the name of your
>> base class variable?
>
> What if I change the name of a base class method? Same thing.
>
You can't change the base class method - by definition, it's part of the
interface. But the variable is part of the implementation. In a proper
design you can change the variable (and, of course, the BODY of
functions which reference it) without changing the interface - and the
child classes.
>> Part of the OO design is the derived classes are
>> independent of the base class implementation.
>
> class A {
> private $data;
>
> protected function getData() ...
> protected function setData($data) ...
> }
>
> class B extends A {
> protected function initData() {
> $this->setData('foo');
> }
> }
>
> Where's the problem?
>
There's nothing wrong with this method.
>>> It's not always possible to initialize an object just by passing all the
>>> required data to the constructor, sometimes you have to perform
>>> additional task in separate methods. That's not a problem. And calling a
>>> child's method from a parent's method is not only allowed, but very
>>> common and important (virtual methods, polymorphism, things like that).
>> It is ALWAYS possible to initialize the base object via constructor
>> parameters in a properly designed OO system.
>
> Of course you can initialize it with constructor parameters to bring it
> into a consistent and working state. But it might still be necessary to
> call further methods to "fine-tune" its behaviour. You can't always pass
> it all to the constructor, especially when there are things that are
> entirely optional. You don't want to have a constructor with a hundred
> arguments, taking into account every possible situation.
>
No, but then if you need a constructor with a hundred different optional
arguments, you should rethink your design.
> Additionally there might be cases, where the object A needs informations
> or a connection to another object B, which is not yet available while
> running A's constructor.
>
Not in a proper OO implementation, there isn't.
>> But we're not talking about polymorphism here. That's an entirely
>> different subject.
>
> It is, but also plays a role here.
>
Not in the construction of the object.
>>>> Additionally, in proper OO, A::data would be
>>>> private to the base class.
>>> Sure, can be done. But I prefer to declare my properties as protected,
>>> if they are supposed to be accessed in derived classes. I don't want to
>>> write getters and setters for every single member variable. While it
>>> would be "true OO", it's usually too much work for nothing. Things are a
>>> bit different when properties should be accessible from the outside, but
>>> even then I sometimes simply declare them as public.
>> Which is a classic example of overuse of "protected". Protected members
>> should be used rarely, if at all.
>
> Says who and why?
>
> Micha
Check out some of the "experts" in the field - like Booch, Rumbaugh and
Stroustrup.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|