Apart from that, I stick to using protected functions mainly, only exposing the functions that should be called outside a class. One of the main reasons for this is the experience from working in an international organisation on a volunteer basis – everyone comes from a different background, with different experiences, and there’s a high chance that you will see some code used in ways you hadn’t quite planned. If this leads to tight coupling (and it almost certainly will), then you’re headed down the nightmare path.

The more public methods a class has, the more trouble you’re looking at in terms of maintenance when you have to update the class or switch it out.

Regards
Fake

When it comes to testing, I always prepare a mock object for each class, at least so that future tests that need a mock of the given class will have one in place that was built while the new class was still fresh in my mind. Its mocked public methods are designed to return controlled responses, just like you’d want from a good mock object. In addition, I’ll create public wrapper methods that wrap around the original class’s protected methods, thereby making each protected method testable by itself. This isn’t about code coverage or the API… it’s about me being more thorough in guaranteeing the behavior of my protected methods.

By segregating logic into small units that each “do one thing and do it well”, I typically end up with many protected methods. By trying to keep my API as clean as I can, and true to my architectural intent, I limit the amount of public methods. Tests against my public methods still exercise the protected methods that they use, true enough. My insistence on the mocked object’s public wrappers allowing me to directly test the protected methods is just additional insurance, done in a way that I can more closely target each protected method’s behavior.

I’ll rarely if ever choose private for anything. Nearly all code I write is done with the expectation that it is or could be reused elsewhere… as such, I trust to protected methods for allowing child classes to do what they need to do, whether it’s decorating the parent’s protected methods or overriding them completely.

I was actually *very* surprised to see your example of a private parent method being overridden by a child class. Did the #phpc discussion touch on this being a visibility enforcement bug?

I take the view of if you are creating code, you are writing a test for it, and you make the test pass with the barest of implementations.

You come back the next day, and realise you are repeating the same pattern of checking input in a number of places – ie, a validate().

This was a hidden design problem, so you decide to implement a protected method and shift the common code up.

However, when you really think about it, shifting a method up because of a hidden design problem really means you haven’t modelled it properly; and your only real option from here is to make it another class.

That way you can break the responsibility from your first object into another object, and increase the specialisation of each.

The payoff for creating a whole new class might be minimal if all it does is validate() though; so usually I apply my Best Judgement, and simple expose the method as public / write test coverage of it, with a @todo to refactor it elsewhere or add it to an interface if it seems common enough.

Doing a Bad Thing once is unpleasant, twice is ugly, three times is a good time to refactor.

I like to help people learn about testing, if I can, and I tried to help you. I don’t understand why you should feel offended.

Exactly but you have got to be careful and not just plaster it all over the place.

The way I look at it is “public”, “private”, and “protected” provide an aid for documentation and a guide to the unwary developer as to the intended wishes of the original developer(s).

And who knows? A future version of PHP may actually fix any current issues and we do have the expected behaviour.

> Personally, I never use private or…

Personally I wish you would stop plugging your silly little testing library all over the web.

I agree TDD is important but there are already far better, more mature tools out there that do the same job… but only better.

Be gone with you McGuff.

Mocks are intended to expose internal workings but only so you can “discover” the neighbouring objects in the design. TDD is primarily about design rather than testing – although that too.

Personally, I never use private or protected. They don’t actually do anything useful. http://aperiplus.sourceforge.net/visibility.php

And he also pointed out that I had lame register and login to comment on. I’ll have to look into captcha for spam filtering but think my akismet should get it. Guess I’ll find out. Anyways, the thing I have with that statement is mostly likely due to my nubbish skills as a programmer and developer. So let me explain part of how I’ve been developing with tests.

If a public function I have contains a private function. Then while test/debugging, how do make sure that the private function or functions aren’t part of a logic error that I’m trying to debug.

The root of my issue with private functions and testing may be due to the fact that some of my function do contain more than 1 private function that may be the cause of a test failing. Having a test for each function called within another function has been a benefit of unit testing for me.