|
|
Posted by Richard Levasseur on 06/26/06 17:29
Henk Verhoeven wrote:
> IMHO private declarations are too rigid and therfore decrease
> reusability. I agree that it can be very usefull to know the intentions
> of the developer of some code one is evaluating to call or some member
> variable one is avaluating to access. But every now and then there are
> good reasons to do it anyway, even if it was intended to be private. For
> example lazy initialization and default reasoning both are often
> implemented using direct access to member variables. Another example is
> using a visitor to implement persistency.
>
> Now maybe you would say that i should change these member variables to
> protected or public. There are two problems with this:
> 1. It may not be my own code. Then if i get an upgrade of this code,
> these member variables will once again be private, unless i re-apply my
> changes. This is uneccessary overhead.
> 2. By changing the private declaration the intension of the other
> developer gets lost. Now i could put a comment in that it was intended
> to be private, but in that case: why not put the @private marker in the
> comment in the first place?
>
> The fundamental point is: With these private and protected declarations
> you get stuck with the uneccessarily limitations introduced by the
> author. Object-orientation can lead to more reusability then
> conventional parameterized code exactly because the code can be
> overridden and extended in ways the original author did not provide for.
> private and protected declarations are a step backwards that is only
> reasonable if you assume that future developers that will maintain or
> reuse your code will ignore your intentions becuase they are fools. If
> this is the case, i think you should tell your boss that you are
> limiting the reusability of your code because you are aniticipating him
> to hire fools and let them work on/with your code ;-)
>
> Greetings,
>
> Henk Verhoeven,
> www.phpPeanuts.org.
Its nice to see someone share this opinion (mostly). I agree that
private declarations are a hinderance more often than not. If I'm
going through the trouble of heavily extending a class, I will more
than likely need or want access to the member variables for ease of use
and efficency - and besides, you should be allowed to hack away at
things if you really want to; I think extending a class is a decent
enough prequisite that you're aware of whats going on.
One bad practice based on good intentions is code reuse when the
underlying implementation will pose a problem (ie, it uses a linear
search but you need something faster). Its a good reason to use
protected more often than private. Unfortunately, during my entire
education, I've never had a teacher mention protected other than in
passing, let alone encourage its use.
I have to disagree with not having public, though, it helps enforce
proper use of the class and prevent hack n' slash methods which are so
common in web development. You can encourage discipline and practice
all you want, but mistakes and disregard happens. Its safer to require
them to do it a certain way. Also, if you are using 3rd party packages
from pear or whatnot and they modify the underlying implementation,
then your code is broken or highly suspect. Getter and setter methods
can return a reference/pointer to the original data if they need to
access it directly, and they can have a ball with it then.
What would be nice is a mechanism for overriding protection by casting
or something. (unprotected) $this->data. Sorta like friend but not
requiring the declaration in the original source. I'm of the opinion
that if you're willing to cast something, then you're aware of the
implications it has and should be allowed to.
I think a distinction should be made between maintaining code and
reusing code. Maintaining means you're going to change it, reusing
means you're going to use whats already there, without modifying it.
If you're maintaining it, then yes, you should definately know what the
intentions are; you're probably going to be modifying the source in the
future.
(Aside: Chances are you're going to maintain some code and think 'Man,
what a fool.' Meanwhile, 'This guy's an idiot' is being thought by
your replace back at your old job. Just say no to Programmer Hubris.)
However, reusing code should not require an understanding on why the
author did what. Thats part of the purpose of OOP. So, HTML_Table
changed from using a complete associative array to a sparse linked list
matrix. Do I really care? I shouldn't have to.
Woo, my caffine rush just kicked in. I'm going to get some work done.
Navigation:
[Reply to this message]
|