Re^5: Private Methods Meditation

This does not strike me as a good reason.

Experience strongly suggests that if you use descriptive method names, collisions are rather rare, documentation is never accurate, and it is as easy to search code for private methods as it is documentation. (Besides, I'm always going to search the code in the end because I don't trust the documentation.)

Furthermore no amount of documentation can protect you if the base module's implementation changes and it now needs a new private method that might intersect what some subclass is using.

This is part of what I was referring to at Re^2: Private Methods Meditation. And there is no perfect solution to it. However after you use descriptive method names and have decent test suites, the problem virtually goes away. If you furthermore have somewhat decent designs, the issue becomes rare to the point of being an endangered species.

I'll continue my practice of not documenting private methods in POD. They are in source code, and possibly in regular comments when needed. That is good enough.

Comment on Re^5: Private Methods Meditation

Replies are listed 'Best First'.
Re^6: Private Methods Meditation by ihb (Deacon) on Aug 09, 2004 at 23:11 UTC
Furthermore no amount of documentation can protect you if the base module's implementation changes and it now needs a new private method that might intersect what some subclass is using. You hit the head of the nail here. That's why you shouldn't use methods calls on "private methods" (update: private methods in the java sense, not just "non-public" methods)--to avoid that intersection with any subclass. Though, you alrady have a large code base that uses `$self->_private` you can document these methods (just that they exists and are called as methods with suffice) instead of patching every methods call. (And then you of course should stop using method invocation on private methods.) `ihb` Read argumentation in its context!	[reply] [d/l] [select]
Re^7: Private Methods Meditation by tilly (Archbishop) on Aug 10, 2004 at 01:00 UTC
That's why you shouldn't use methods calls on "private methods"--to avoid that intersection with any subclass. That choice doesn't always make sense. It is common for a class to use appropriately placed method calls as convenient "hooks" to let subclasses override behaviour. In fact this is a decent design strategy, and I've been known to recommend it. But these methods are not public. That is, they are not meant to be part of the public API that the class and its subclasses present to the user. Rather it is part of the private API between the class and its subclasses. So they are private (at least to some extent). But they really have to be done as method calls, because the entire point of the method is to be overridden appropriately in subclasses. What now? Well one choice is to decide to never add such hooks once the module has been written. In fact this is exactly what the open-closed principle tells you to do. However if you maintain an evolving system over time and adhere to that strictly, then you'll find that this encourages developing a maze of classes that is a maintainance problem of its own. Another strategy is to say that you'll sometimes accept the up front risk and go ahead anyways. (Making design tradeoffs is, after all, the job of the programmer.) This makes particular sense if you have a closed code-base and are willing to grep it to make sure that you won't create a conflict. But even if you don't, it is sometimes still an acceptable cost. Particularly if you have a stated convention that all such methods will start with a particular substring. In any case it takes coordination between the maintainer of the class and subclass to make this work and continue to work. If you don't feel comfortable with that, then you shouldn't be subclassing.	[reply]
Re^8: Private Methods Meditation by ihb (Deacon) on Aug 10, 2004 at 01:22 UTC
Again, we seem to agree. But these methods are not public. That is, they are not meant to be part of the public API that the class and its subclasses present to the user. Rather it is part of the private API between the class and its subclasses. So they are private (at least to some extent). I speak of really private methods, not just private to some extend. Those methods you speak of above I refer to as protected methods, using Java terminology as Java is the only other OO language I know. Those methods I call as methods since as you say--they need method lookup. Only really private methods I don't call as methods as I know exactly which method I want to call. In any case it takes coordination between the maintainer of the class and subclass to make this work and continue to work. If you don't feel comfortable with that, then you shouldn't be subclassing. I couldn't agree more! My only addition to this is that: even though this is problematic I don't see any reason to use those simple ways already provided to make it less problematic. Calling really private methods as functions is one way for me to make it less problematic, or using your expression, making the problem virtually go away ever more. `ihb` Read argumentation in its context!	[reply] [d/l]


Pathologically Eclectic Rubbish Lister
	PerlMonks