Private methods are often the symptom of breaking a simple rule of thumb: if your class description contains an “AND”, your class does too much and should be broken.

It is the case of your example: The account class record the data and validate it and publish the events.

Public, private, protected has more to do with writing clean code than source code contract.

Public, private, protected has more to do with writing clean code than source code contract.

First they dismiss static, then access levels… What will come next? Constructors?

For those that are arguing that they cannot change the database and override __updateRecord, well that’s exactly what is intended! If you change the database then you are responsible for overriding _updateBalance and providing your own equivalent of the private _updateRecord() method that “knows” about your version of the database.

As an example, lets assume I wanted a version of account that stored 15% of the deposits as ‘sales commission’, then I would override _updateBalance() that split off the 15%. I would then call parent::_updateBalance() with the remaining 85%, and write my own _updateCommissionRecord() that knows where to save my custom database value!

The teller has methods that are considered public, any customer can access them. They are abstractions and aggregates of other functionality the teller must perform in order to satisfy the expectations of the customer. The depositMoney method for example makes a call to the banks protected method verifyCheck to ensure the check has been endorsed and is in fact real. Once the teller has satisfied it’s own inherited prerequisites for the check to be deposited, they put it into the machine that the bank manages to initiate the withdraw and deposit. The teller does not know how this works in the same sense that the customer doesn’t know all the details of the verification process the teller performs.

The bank will need to perform many actions to setup the withdraw and deposit, and these actions will no doubt change in the future. But the teller need only pass the check to the private initiateWithdrawAndDeposit method of the bank to initiate this process. The teller may incorporate their own verification methods depending on their training and expertise to ensure the check isn’t fraudulent and the customer is following the banks standards and requirements.

In the end, the customer is only exposed to the functionality they need, in this example actually depositing a check. The teller is given discretion as to how the verification of the check happens, and the bank dictates the deposit process without exposing it to teller or customer.

Public, protected, and private.

Composition and encapsulation are core tenets of OOP. In this scenario, if everything had been public, and the customer had invoked a particular method of withdraw and deposit, or if the teller had done this the bank would be forced to always support that particular method for backwards compatibility. Maintaining backwards compatibility becomes an exponential liability as eventually there comes a time compatibility is usually broken, and either refactoring starts to creep in or you end up with project forking and divergent code bases.

And for those asking for “different backend” can look at “Strategy Pattern” (http://en.wikipedia.org/wiki/Strategy_pattern).

In your example, i could redeclare (overload if you will) the _updateBalance() and not call the parent, but just call my own definition of __updateBalance (or __overloadedUpdateBalance, ___updateBalance whatever) just by having it private is by no means a ‘hard’ lock in that every one of your derivatives will adhere to the given standard…

I do agree with you that some form of bottom line should be defined, but that should be defined on a per-project-basis… This shouldn’t be a discussion on _all_ PHP projects should do this or that… but MY project does this… not that.

Again that also goes for the point of ‘forking’ instead of ‘hacking’: thats just bypassing the whole discussion. The choice of VCS or the fact that the project is OpenSource or not, has IMHO nothing to do with it… It is about the choices made by the original developer of what contract is available to you as user/developer of the application. The use is to be documented along with usecases and examples. The fact that you can peek inside the code is a plus, the fact that you can alter the actual code is just room for disaster. Forking could ba solution, but has long term issues. Just live by the contract or if you really have to change it, overload the function and stick to it… This exact problem is why the great thinkers of the past thought up the programming by contract paradigm. Define the contract, extend what you like, but keep the contract..

The argument of unittesting seems trivial: the given example is an ideal candidate for stubbing/mocking and via dependency injection so that every part (including the privates of sending out events) could (and should be btw) easily be tested

The fact remains: symfony made a decision. Any decision should be adhered when using the framework, just like their choice for a certain class signature, this is just part of the project. Live with it or live without it.. It’s just that simple… (or am I now the one over simplifying it…?)

Oh and for the record, i am not a true symfony user, though a great fan of Mr. Potencier’s work! I will therefore be looking forward to his say in this…