Yes I agree to everything you say, I was just pointing out examples. How many OO programmers understand OO ? !!!! Giving them rules to adhere to and not letting them hack the language for their own benefit, just because they don't understand the concept of the language is, to my view, better. I'm an idealist I guess, but it comes from experience of fixing problems introduced from people that have no idea of what they're doing.. Compare C++ code with Java code, which one is harder to follow most of the time?
Fab. ----- Original Message ----- From: "Marcus Börger" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Tuesday, April 09, 2002 9:19 AM Subject: Re: [PHP-DEV] Aggregation, Multiple Inheritence, pros/cons > At 13:40 09.04.2002, fabwash wrote: > >The thesis I mentionned before starts by saying this: > > > >"One of the main reasons why inheritence is a fuzzy concept in > >implementation languages is the fact that it can be used very liberally, > >allowing redefinition and even cancellation of derived properties. This is > >motivated by code reuse, where existing material has to be modified in a > >certain way in order to effectively reuse it. Such actions eventually lead > >to loss of conceptual relationships between the original and derived > >entities. Preservation of these relationships is, however, the primary > >concern in object oriented specifications [..]." > > I had a look at that thesis and it is itself a bit fuzzy and i do not expect > the author to have much expirience. But it is *good*. > > > >This is the danger of MI/Aggr. People take an object that is almost like > >what they want, then use the language to modify its properties. If the > >programmer of the object was good enough to protect his object, then there > >is no problem, but usually programmers don't really understand OO and how > >variables can be accessed from outside of the object, how functions within > >the object can be extended the wrong way. > > The worst argument you could bring: If people do not understand OO programming > concepts do not use them! I say who does not know them should not be forced > to use them. And that is one of our professions downside: Most people do > hacking > not first thinking and then programming. > > >That's why I liked the java implementation. You can only extend 1 object, > >then implement interfaces that are clearly defined. The object is > >restricted, the interfaces allow you to develop your own system. > > The most bad thing about the Java way is that you have to do the same thimg > many times. Interfaces with code, MI, aggrepgation and parametric inheritance > are all techniques to have code only once. > > > >Programmers then wanted to be able to get a bit more control of the object, > >so they invented beans, which are basically objects with strict getters and > >setters, so the programmer of the object knows how his object can be > >modified, and the programmers using the object know what are the > >limitations. > > Beans are COM for Java. And since Beans Java has properties. Enterprise > Beans make Java Applications faster by caching and communication techniques. > Beans and COM are both techiques to hide implementation details. The user > is presented a subset or wrapper class for the real implementation. > > > >MI and Aggr, to my view, allow "similarity reuse", which is against the > >basic OO, but was introduced in C++ because programmers are lazy and they > >like to have control over everything :) > > Where does C++ has aggregation? > MI and Aggregation differ in the way they achieve reuse! Aggregation can be > a runtime solution while MI can't. > > marcus > > > >Fab. > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
