|
|
Posted by Michael Fesser on 07/23/07 18:20
..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.
> 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?
>> 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.
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.
>But we're not talking about polymorphism here. That's an entirely
>different subject.
It is, but also plays a role here.
>>> 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
Navigation:
[Reply to this message]
|