Open Stack

So this is an issue that’s been heavily discussed recently in the PHP community.

Based on personal opinion, I heavily favor and use private properties in software I write. I haven’t, however, used the “final” keyword that much. But the more I read about and see it being used, the more inclined I am to use it in projects. Here’s a great overview of why it’s useful for public APIs: http://verraes.net/2014/05/final-classes-in-php/

Here’s a tl;dr executive summary:

- Open/Closed principle. It’s important to understand that “Open for extension”, does not mean “Open for inheritance”. Composition, strategies, callbacks, plugins, event listeners, … are all valid ways to extend without inheritance. And usually, they are much preferred to inheritance – hence the conventional recommendation in OOP to “favour composition over inheritance”. Inheritance creates more coupling, that can be hard to get rid of, and that can make understanding the code quite tough.

- Providing an API is a responsibility: by allowing end-users to access features of our SDK, we need to give certain guarantees of stability or low change frequency. The behavior of classes should be deterministic - i.e. we should be able to trust that a class does a certain thing. There’s no trust whatsoever if that behavior can be edited and overridden from external code.

- Future-proofing: the fewer behaviours and extension points we expose, the more freedom we have to change system internals. This is the idea behind encapsulation.

You said that we should only use private and final keywords if there’s an overwhelming reason to do so. I completely disagree. I actually want to flip the proposition here: I think we should only use public keywords if we’re CERTAIN we want to encourage and allow the inheritance of that class. By making a class inheritable, you are saying to the outside world: this class is meant to be extended. And the majority of times this is not what we want. Sure there are times when inheritance may well be the best option - but you can support extension points in different, often better, ways. Declaring explicitly what the extension points are is part of the contract your code has with the rest of the system. Final classes help to enforce this contract.

To summarize, we have nothing to lose by favoring private and final keywords. We gain the above advantages, and if we later decide to open up that class as an extension point we can remove the keywords without any issues. Should a valid reason come up to open it up, it will be easy to do so, because nothing depends on it being closed. On the other hand, if you start by making everything open or inheritable, it will be very hard to close it later.

Jamie


On June 5, 2014 at 6:24:52 PM, Matthew Farina (matt at mattfarina.com<mailto:matt at mattfarina.com>) wrote:

Some recent reviews have started to include the use of the private
keyword for methods and talk of using final on classes. I don't think
we have consistent agreement on how we should do this.

My take is that we should not use private or final unless we can
articulate the design decision to intentionally do so.

To limit public the public API for a class we can use protected.
Moving from protected to private or the use of final should have a
good reason.

In open source software code is extended in ways we often don't think
of up front. Using private and final limits how those things can
happen. When we use them we are intentionally limiting extending so we
should be able to articulate why we want to put that limitation in
place.

Given the reviews that have been put forth I think there is a
different stance. If there is one please share it.

- Matt



Jamie Hannaford
Software Developer III - CH     [experience Fanatical Support]

Tel:    +41434303908
Mob:    +41791009767
        [Rackspace]



Rackspace International GmbH a company registered in the Canton of Zurich, Switzerland (company identification number CH-020.4.047.077-1) whose registered office is at Pfingstweidstrasse 60, 8005 Zurich, Switzerland. Rackspace International GmbH privacy policy can be viewed at www.rackspace.co.uk/legal/swiss-privacy-policy
-
Rackspace Hosting Australia PTY LTD a company registered in the state of Victoria, Australia (company registered number ACN 153 275 524) whose registered office is at Suite 3, Level 7, 210 George Street, Sydney, NSW 2000, Australia. Rackspace Hosting Australia PTY LTD privacy policy can be viewed at www.rackspace.com.au/company/legal-privacy-statement.php
-
Rackspace US, Inc, 5000 Walzem Road, San Antonio, Texas 78218, United States of America
Rackspace US, Inc privacy policy can be viewed at www.rackspace.com/information/legal/privacystatement
-
Rackspace Limited is a company registered in England & Wales (company registered number 03897010) whose registered office is at 5 Millington Road, Hyde Park Hayes, Middlesex UB3 4AZ.
Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy
-
Rackspace Benelux B.V. is a company registered in the Netherlands (company KvK nummer 34276327) whose registered office is at Teleportboulevard 110, 1043 EJ Amsterdam.
Rackspace Benelux B.V privacy policy can be viewed at www.rackspace.nl/juridisch/privacy-policy
-
Rackspace Asia Limited is a company registered in Hong Kong (Company no: 1211294) whose registered office is at 9/F, Cambridge House, Taikoo Place, 979 King's Road, Quarry Bay, Hong Kong.
Rackspace Asia Limited privacy policy can be viewed at www.rackspace.com.hk/company/legal-privacy-statement.php
-
This e-mail message (including any attachments or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com and delete the original message. Your cooperation is appreciated.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140606/9940f3d8/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageb53739.JPG
Type: image/jpeg
Size: 3124 bytes
Desc: imageb53739.JPG
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140606/9940f3d8/attachment.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageb7c9da.JPG
Type: image/jpeg
Size: 990 bytes
Desc: imageb7c9da.JPG
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140606/9940f3d8/attachment-0001.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image4a768b.JPG
Type: image/jpeg
Size: 6844 bytes
Desc: image4a768b.JPG
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140606/9940f3d8/attachment-0002.jpe>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagea8b675.JPG
Type: image/jpeg
Size: 1074 bytes
Desc: imagea8b675.JPG
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140606/9940f3d8/attachment-0003.jpe>