Private methods - Follow Up
Posted on 23/8/08 by Felix Geisendörfer
Hey folks,
as I expected almost everybody disagreed with my views on private methods. Here is the deal:
If you can use the private / protected feature of your language to do more good than evil in the world, all power to you.
If you have doubts ... read on.
First I have to make some confessions. I have not studied computer science. I have not done much Java. I have little trust in theory that I cannot apply to the real world. I do not think modern programming is much of a scientific endeavor. I believe the best code is no code at all. And I think there are lots of reasons to question anything people call fundamentally true.
But more than everything else, I believe the following:
We are in the stone age of programming. We are really just talking Fire, Water, Wind and Earth here.
It has only been 50 years since modern programming appeared. Chances are that 100 years from now most of what we consider good ideas and best practices will seem like a joke. But here I go lecturing you people with what in reality isn't more than a bunch of hunches and ideas of some guy without formal education in the field.
But ... I do have some experience with applications heavily using private functions. Once upon a time I worked on a CakePHP application. It was big. 300++ database tables. We're talking about what is probably the biggest CakePHP install out there. The previous programmers seemed to love private methods. They made sure to put 4-5 in at least every controller for good measure. I refactored this code, at least a lot of it. And I noticed a consistent pattern: 9 out of 10 times private methods were used as a rug that shit the programmers didn't want to architect properly was swept under.
Now this is just one example Felix, you might say. You haven't seen my glorious use of this most awesome of all OOP concepts. And you are right. I haven't. But I want my theory to be true. I feel I'm onto something. I saw this pattern to emerge every time I looked at private functions. And I either want you guys to proof me that I'm an idiot (I can live with that, no worries) or see the elegance of avoiding private methods yourself.
So I decided to join Nate Abele's I will insult your code challenge. Send me some CakePHP code that you cannot imagine to be elegant without private or protected methods / properties. Limit yourself to a class or two tops (like controller + model). Send this code to me. I will either refactor it to my idea of beauty and elegance or admit my mistake : ).
This is not exactly going to be a scientific proof or anything close, but as long as I might be able to convince or get myself convinced somebody is going to learn from it!
-- Felix Geisendörfer aka the_undefined
Did you like this blog post? If so, please consider subscribing to the Blog RSS feed.
You can skip to the end and add a comment.
Take one of the core components of cakephp like email or cookie which make use of "private" methods ;-)
I wrote a responce about why I think private/protected methods might be a necessary evil, but pingbacks didn't get through (might be my wordpress installation...), but here's the link: http://fluffigt.com/2008/08/23/private-methods-in-php-programming-response/
regards,
Micke
Mikael Löfstrand: We are currently working on pingbacks and trackbacks. This blog is custom developed with CakePHP. No wordpress, nothing. Expect something soonish.
Obviously as you said, your idea is not shared by community.
So *you* have to prove you're not an idiot we do not have to do so.
So, you are wrong until you prove and we (the community) admit you are right.
You didn't study computer science, you don't know Java you are young (an I right?) and you don't have a long strong programming experience. Sorry, but you really have to prove your idea !
You are quite good at PHP, you're discovering the beginning of OOP, great ! Welcome to the developper community, study more, work hard on other languages and OOP and then come back and share your global vision.
Until then, continue to share with us your great PHP and CakePHP vision but please, do not try to explain us we are *all* wrong on things you admit yourself not to know 100% :-)
@tagada: Hah! Since it's his blog, I'm pretty sure he can put the burden of proof on whoever he wants. If you don't agree, you don't have to participate.
@Felix: Awesome idea, can't wait to see the refactoring. For the record, I'm sometimes okay with protected, but never with private.
Well, I think the deal here is that most code you'll get here is going to be "End-user" cake code. I don't think there's generally much value to private or protected methods there. I think the primary place for such formal code protection is in library code that is widely distributed. Where the "private" keyword is basically a signal of "don't even try to use this method, because we're likely to change, remove or alter it in any release." It's just a formal way of enforcing a public interface, so that people don't accidentally use pieces of your library which you want the freedom to change, without breaking anyone's code that uses your library.
That reminds me of a quote: "Those who say it cannot be done should be quiet and get out of the way of those who are doing it."
@Chris
Your explanation makes more sense to me than anything else I have read :)
I tend to agree with your theory in the context of MVC. The functionality of private methods in controllers is almost always crying to be refactored into a model or component. Then I'd argue your thoughts could be thrown on top of the fat model skinny controller debate.
It could also be argued that your realization is also a realization of the limits of the PHP language itself and its lack of effective functional programming and function-as-object constructs that languages like Python or Ruby have.
You've become a bit of a joke for that previous post, so I'm surprised to see you beating this dead horse. Here's something like the example you were given last time, that I didn't see an adequate response to:
class Airplane
{
private $altitude = 1000; // meters
public function requestAltitudeChange($newAlt)
{
if ($newAlt < 0) throw new BlewUpPlaneException();
if ($newAlt >= 100000) throw new InSpaceException();
$this->altitude = $newAlt;
return true;
}
}
@Eric Lawless:
Stupidly simple.
class Cessna extends Airplane {
// Lower default altitude for a prop plane
protected $altitude = 500;
}
Making it private is dumb, because it can't even be accessed or overridden in subclasses. Let's say Cessna needed to extend and add some extra checks to requestAltitudeChange. What then?
Besides, if you'll notice, the title reads "Private *methods*", not "Private *properties*". Pay attention next time and you won't come off as such a joke.
@Nate Abele
"Private / protected methods and properties are one of the most stupid concepts of OOP." - Felix Geisendörfer
Big letters, top of the page, previous post. Bravo.
Your now wonderfully extensible class does exactly the same thing mine does in terms of encapsulation; where's the counter-example?
Private methods consolidate code that you don't want other classes calling, but which you want to reuse/abstract inside the class. Continuing the example:
class Airplane
{
protected $altitude = 1000; // just for you Nate Abele ;)
protected function changeAltitude($newAlt)
{
if (checkFlaps() && doOtherCrapIDontKnow() && seriouslyImNotAPilot()) {
$altitude = $newAlt;
return true;
}
return false;
}
public function requestBankingTurn($direction, $requester)
{
if (is_a($requester,"Hobo")) throw new YoureAHoboException();
if (!in_array($direction,array("left","right"))) throw new IllegalDirectionException();
return changeAltitude(max($this->altitude - 100,0)) // sure, airplanes can bank on the ground
&& turnAirplaneAndCrap($direction);
}
public function requestAltitudeChange($newAlt, $requester)
{
if (is_a($requester,"Hobo")) throw new YoureAHoboException();
if ($newAlt <= 0) throw new BlewUpPlaneException();
if ($newAlt >= 100000) throw new InSpaceException();
return changeAltitude($newAlt);
}
}
Tim Koschützki: Sounds nice! I'd love to see that code sometime... But maybe you should remove the pingback tag (link hrel=pingback etc) in the html headers 'til you are done with the functionality? :)
pingback :
[...] more and more amateur programmers are landing on the OOP - Object Oriented Planet - without having even scripted before, what is nice because they are starting in a well known and mature concept wich rules most of great application’s design, but is also evil, because they don’t really know something, and so they can’t tell what is really going on in the whole [...]
http://rafaelbandeira3.wordpress.com/2008/08/24/new-agemisconceptioned-private-methods
> But ... I do have some experience with applications heavily using private functions.
Experience ? At 20 ? (no offense intended, I'm not much older)
The only way you can have enough experience without a formal background in my opinion is to have at least ten years of experience in various projects.
Mind you, some won't achieve this in 40 years and others won't get any benefit from studies either because they merely go through them without thinking once. However, courses include things so dull that you would never read about them otherwise but which are still useful to see where we're going and why (state machines anyone ?).
In short : I don't doubt you saw awful uses of protected and private methods, but I can say the same about public methods. And OOP. And any programming paradigm I worked on.
This post is too old. We do not allow comments here anymore in order to fight spam. If you have real feedback or questions for the post, please contact us.
nice concept of refactoring service.
If this get tons of response you can actually charge or have a micro payment as "thank you" token for fixing their codes.