Just to give an example, Doctrine 2 has almost no protected only private variables and strictly prevents inheritance in many cases:
What this enabled us to do in our development of 2.1 is to refactor the internals of many of our central classes to allow for much better performance and tons of new features that needed adjusting central parts of the Doctrine classes. With protected variables all this would not be possible, because we would have to break BC. There are very real benefits of the closed principle even for frameworks and if they are maintained very well and bugs get fixed fast then there is no problem. Frameworks like ZF need protected stuff because frankly most of ZF components go into production releases where an "alpha" tag would be useful. However the level of detail that went into the Symfony API and also compared to other frameworks the "few tasks" it tries to solve (focus on the relevant!) using private properties is actually a positive step towards future enhancements of the framework. One HUGE benefit here is the DI Container, almost everything in Symfony has an interface. Just exchange the whole implementation! Yes you need to copy the code, yes its more ocmplex to maintain FOR YOU. but in contrast, the framework is much easier to maintain for us core developers and this will benefit EVERYONE in the long run. greetings, Benjamin On Wed, 9 Mar 2011 17:19:55 -0500, Bulat Shakirzyanov <[email protected]> wrote: > This change is for the best. > > For people that disagree, read up on > http://en.wikipedia.org/wiki/Open/closed_principle > <http://en.wikipedia.org/wiki/Open/closed_principle> > <http://en.wikipedia.org/wiki/Open/closed_principle>Allowing all properties > and methods to be hijacked in subclasses and allowing subclass anything > opens the system to modification, as any of the core system behavior can be > changed. > The correct approach is to provide contracts for extension (interfaces) and > concrete closed implementations that are well-tested and work, and can be > changed internally at any time, without breaking user-land code that > interacts with them (think refactoring). > > If user-land code relies on some internal behavior however, the whole > system > is much more error prone with any change to the core class, as it ripples > through all of its descendants. > > My advice to all framework users is to provide alternative implementations > of pre-defined interfaces, instead than relying on overloading of core > classes. > Same applies to mocking - mock interfaces and not actual implementations. > > Final and private are underused in PHP, which is the result of programmers > not thinking of providing explicit ways to extend their framework. Instead > of defining extension points, they simply leave the whole framework open to > modification, which leads to unexpected behavior. The fact that methods and > properties are becoming declared as private means that the framework is in > the stage of its maturity, where we think of opening legit ways for its > extension, while eliminating possibility of hacks. > > Best, > > On Wed, Mar 9, 2011 at 5:42 AM, Martin Hasoň <[email protected]> > wrote: > >> For API is only public visibility (see >> http://api.symfony-reloaded.org/master/). Protected visibility is for all >> others. Private visibility is only for very very special method. Public >> visiblity is for user, protected visibility is for programmer and private >> visibility is for black box. For example framework Django doesn't have a >> private method. >> >> -- >> If you want to report a vulnerability issue on symfony, please send it to >> security at symfony-project.com >> >> You received this message because you are subscribed to the Google >> Groups "symfony developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/symfony-devs?hl=en >> > > > > -- > *Bulat Shakirzyanov* | Software Alchemist > > *a: *about.me/avalanche123 > *e:* [email protected] -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en
