<html>
<head>
<!-- Template generated by Exclaimer Mail Disclaimers on 03:01:48 Friday, 6 June 2014 -->
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style type="text/css">P.ae431132-9d17-4a38-b6b5-634369783623 {
MARGIN: 0cm 0cm 0pt
}
LI.ae431132-9d17-4a38-b6b5-634369783623 {
MARGIN: 0cm 0cm 0pt
}
DIV.ae431132-9d17-4a38-b6b5-634369783623 {
MARGIN: 0cm 0cm 0pt
}
TABLE.ae431132-9d17-4a38-b6b5-634369783623Table {
MARGIN: 0cm 0cm 0pt
}
DIV.Section1 {
page: Section1
}
</style>
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<p class="ae431132-9d17-4a38-b6b5-634369783623"></p>
<div id="bloop_customfont">So this is an issue that’s been heavily discussed recently in the PHP community.</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">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: <a href="http://verraes.net/2014/05/final-classes-in-php/">http://verraes.net/2014/05/final-classes-in-php/</a></div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">Here’s a tl;dr executive summary:</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_customfont">- <b>Open/Closed principle</b>. 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.</div>
<div id="bloop_customfont"><br>
</div>
<div id="bloop_sign_1402060791092946944" class="bloop_sign">- <b>Providing an API is a responsibility</b>: 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. </div>
<div id="bloop_sign_1402060791092946944" class="bloop_sign"><br>
</div>
<div id="bloop_sign_1402060791092946944" class="bloop_sign">- <b>Future-proofing</b>: the fewer behaviours and extension points we expose, the more freedom we have to change system internals. This is the idea behind encapsulation.</div>
<div id="bloop_sign_1402060791092946944" class="bloop_sign"><br>
</div>
<div id="bloop_sign_1402060791092946944" class="bloop_sign">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
<i>meant</i> 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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Jamie</div>
<br>
<p style="color:#000;">On June 5, 2014 at 6:24:52 PM, Matthew Farina (<a href="mailto:matt@mattfarina.com">matt@mattfarina.com</a>) wrote:</p>
<blockquote type="cite" class="clean_bq"><span>
<div>
<div></div>
<div>Some recent reviews have started to include the use of the private <br>
keyword for methods and talk of using final on classes. I don't think <br>
we have consistent agreement on how we should do this. <br>
<br>
My take is that we should not use private or final unless we can <br>
articulate the design decision to intentionally do so. <br>
<br>
To limit public the public API for a class we can use protected. <br>
Moving from protected to private or the use of final should have a <br>
good reason. <br>
<br>
In open source software code is extended in ways we often don't think <br>
of up front. Using private and final limits how those things can <br>
happen. When we use them we are intentionally limiting extending so we <br>
should be able to articulate why we want to put that limitation in <br>
place. <br>
<br>
Given the reviews that have been put forth I think there is a <br>
different stance. If there is one please share it. <br>
<br>
- Matt <br>
</div>
</div>
</span></blockquote>
<p></p>
<p class="ae431132-9d17-4a38-b6b5-634369783623"> </p>
<p class="ae431132-9d17-4a38-b6b5-634369783623">
<table border="0" cellpadding="0" width="504">
<tbody>
<tr>
<td style="WIDTH: 270px" class="LEFT_ALIGNED"><span style="font-family:Verdana; font-size:small; ">Jamie Hannaford</span><br>
<span style="font-family:Verdana; font-size:x-small; ">Software Developer III - CH</span></td>
<td style="WIDTH: 281px"><img alt="experience Fanatical Support" align="right" src="cid:imageb53739.JPG@a3a4e177.42852be3" width="159" height="17"></td>
</tr>
<tr class="LEFT_ALIGNED">
<td colspan="2"><img alt="LINE" src="cid:imageb7c9da.JPG@328ac280.47b490e5" width="504" height="4"></td>
</tr>
<tr>
<td class="CONTACTINFO"><span style="font-family:Calibri; ">
<table class="ae431132-9d17-4a38-b6b5-634369783623Table">
<tbody>
<tr>
<td><span style="font-family:Verdana; font-size:x-small; ">Tel: </span></td>
<td><span style="font-family:Verdana; font-size:x-small; ">+41434303908</span></td>
</tr>
<tr>
<td><span style="font-family:Verdana; font-size:x-small; ">Mob: </span></td>
<td><span style="font-family:Verdana; font-size:x-small; ">+41791009767</span></td>
</tr>
</tbody>
</table>
</span></td>
<td class="RIGHT_ALIGNED"><img alt="Rackspace" src="cid:image4a768b.JPG@ac0499d4.4b8259fd" width="280" height="60"></td>
</tr>
<tr class="LEFT_ALIGNED">
<td class="CONTACTINFO" colspan="2"><img src="cid:imagea8b675.JPG@d3f45804.4a8ccb80" width="504" height="3"></td>
</tr>
</tbody>
</table>
</p>
<p class="ae431132-9d17-4a38-b6b5-634369783623"> </p>
<p class="ae431132-9d17-4a38-b6b5-634369783623"></p>
<span style="font-size: 11px;">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<br>-<br>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<br>-<span style="font-size: 11px;"></span><br>Rackspace US, Inc, 5000 Walzem Road, San Antonio, Texas 78218, United States of America</span><br><span style="font-size: 11px;">Rackspace US, Inc privacy policy can be viewed at www.rackspace.com/information/legal/privacystatement</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">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.</span><br><span style="font-size: 11px;">Rackspace Limited privacy policy can be viewed at www.rackspace.co.uk/legal/privacy-policy</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">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.</span><br><span style="font-size: 11px;">Rackspace Benelux B.V privacy policy can be viewed at www.rackspace.nl/juridisch/privacy-policy</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">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.</span><br><span style="font-size: 11px;">Rackspace Asia Limited privacy policy can be viewed at www.rackspace.com.hk/company/legal-privacy-statement.php</span><br><span style="font-size: 11px;">-</span><br><span style="font-size: 11px;">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@rackspace.com and delete the original message. Your cooperation is appreciated.</span></body>
</html>