On 2013-05-10 12:00, Steven D'Aprano wrote:
But either way, that's fine. You've found an object where it does make
sense to have an explicit "make it go" method: first one entity has
permission to construct the object, but not to open the underlying file.
Another entity has permission to open the underlying file, but not to
create the object. I have no idea whether this is a reasonable security
design or not, it actually sounds a bit rubbish to me but what do I know?
So let's treat it as a reasonable design.
As I've said, repeatedly, that's not what I'm talking about.
When you DON'T have useful things that can be done with the object before
calling "enable", then it is an anti-pattern to require a separate call
to "enable" method, and the enable functionality should be moved into the
object constructor. If you DO have useful things that can be done, like
pass the object to another entity, for security, then that's a whole
'nuther story.
I'd be curious to see in-the-wild instances of the anti-pattern that you are
talking about, then. I think everyone agrees that entirely unmotivated "enable"
methods should be avoided, but I have my doubts that they come up very often. Do
programmers have a natural tendency to make an extra, completely unnecessary
method? I would think that they have a natural tendency to the opposite.
In my experience, everyone has a reason in mind when they follow a
pattern/anti-pattern. It is pretty rare that someone just does some specific,
nameable thing for no reason at all. There is no need to call out an
anti-pattern for which no one has a reason to do it. But there is a continuum of
reasons. Some reasons are better than others. Some reasons only apply in a small
set of circumstances but seem like they would apply more generally, at least to
novice programmers. Programmers can be wrong about what they think the
(anti-)pattern actually achieves. The whole point of naming an anti-pattern is
to discuss those reasons, show where they are misapplied, where YAGNI, why
novices overuse it, other patterns that should be used instead, and also the
circumstances where it is actually a good pattern instead.
To artificially limit the discussion of the anti-pattern to the trivial,
entirely unmotivated case forbids most of the interesting and instructive parts
of the conversation.
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
--
http://mail.python.org/mailman/listinfo/python-list
