note 119485 added to language.oop5.visibility
| From: | noeldarlow | Date: | Sat, 18 Jun 2016 20:20:01 +0000 |
| Subject: | note 119485 added to language.oop5.visibility | ||
| Groups: | php.notes | ||
| Request: | Send a blank email to php-notes+get-205752@lists.php.net to get a copy of this message | ||
After having the how explained, many people will still be left wondering about the why. How should
the different kinds of visibility be used in practice?
Some kind of labelling for the public and private parts of an interface is certainly necessary. We
need to be clear which methods will be part of the public interface and which are only used
internally .
In older versions of php notionally-private functions were prefixed with an underscore - a much
simpler and more elegant solution to the labelling problem. "Protected" adds clutter which
affects readability. It adds a lot of unnecessary typing to what is already a keyboard-intensive
job.
As for enforcement.. no-one ever got mixed up about public/private so long as they were clearly
labelled. As such, "protected" is an attempt to solve a problem which simply did not
exist.
Private is even worse. It specifically encourages bad object-oriented code with the use of
inheritance in places where you should be thinking about separate, co-operating objects.
A feeling that classes which inherit from each other need to hide some of their bits from each other
is a sure sign that you need to break the code up into separate objects. This is exactly what
encapsulation is for. It doesn't make any sense to try to encapsulate bits inside an
inheritance tree. Classes which extend other classes must always be free to override whatever it is
they need to override in their parent classes.
In short, use protected if you must, do not use private at all. Do not try to squeeze too much new
functionality into an inheritance tree: create networks of co-operating objects with clearly-defined
responsibilities instead.
It's a real shame that php took the decision to implement private and protected. They add
nothing to our ability to write good quality OO code; they simply make that code more difficult to
write and to understand. Clarity and simplicity are incredibly important in programming but now
both php programmers and php developers are stuck with these unnecessary layers of complexity.
----
Server IP: 72.52.91.14
Probable Submitter: 212.159.44.241
----
Manual Page -- http://php.net/manual/en/language.oop5.visibility.php
Edit -- https://master.php.net/note/edit/119485
Del: integrated -- https://master.php.net/note/delete/119485/integrated
Del: useless -- https://master.php.net/note/delete/119485/useless
Del: bad code -- https://master.php.net/note/delete/119485/bad+code
Del: spam -- https://master.php.net/note/delete/119485/spam
Del: non-english -- https://master.php.net/note/delete/119485/non-english
Del: in docs -- https://master.php.net/note/delete/119485/in+docs
Del: other reasons-- https://master.php.net/note/delete/119485
Reject -- https://master.php.net/note/reject/119485
Search -- https://master.php.net/manage/user-notes.php