quote:Original post by Kylotan
fallenang3l (and clum, to an extent) - The black box concept isn''t all that useful when applied to the template method. Bear in mind that the template method pattern is not so much about ''being object oriented'' as it is about exploiting the polymorphism system to customise parts of a system. You need to be very familiar with the templated algorithm in order to appreciate which functions to override in the subclasses. Naming and understanding individual components wasn''t a problem here, but having program flow split over several files and hidden in the polymorphism implementation was.

Perhaps the template method pattern wasn''t the one to use. The template method has a schizophrenic mandate as it has to accomodate both the client programmer and the writer of the specific algorithms derived from the base. In effect, as you said, it relies on polymorphic behavior so heavily that by calling a method you don''t have a clue what gets called.
What I''d have done is split up the responsibilities into two classes. One class is the specific algorithm (in fact, it not need to be a class, it can be a free function) that a reference to the worker class. The worker class might be an ABC providing just an interface so you can derive more specific workers, but it not need to be. So in your code you see what actual algorithms are invoked and what specific workers you pass in, so it should be clear what happens without delving deep into the implementation details. Not as totally automated, true, but still clear, generic and flexible.

quote:Original post by Kylotan
I made a choice, but it was the wrong choice. I was designing to solve a problem that I didn''t really have, adding in flexibility and safety that I didn''t yet need. It gave me some potential benefits in return for some definite downsides.

I think that you hit the nail on the head here. What''s wrong is not the design, but that it was applied before it was needed, if it would ever be. So many people get caught up in the power and flexibility of abstraction and polymorphism that they subconsciously perceive future problems or scenarios that will require certain design patterns to overcome. You get so used to thinking about problems in a specific way that some solutions seem naturally correct, and only once you''ve applied them do you get the opportunity to test your "assumptions." I guess this brings us back to the rigid way of thinking, as you say. However, I wouldn''t put anyone at fault for this. Everyone has their own instinctive sense of how design should be approached that was picked up somewhere along their programming career. We find something that suits our fancy and stick with it. It''s not being rigid that''s the problem, it''s being stubborn; actively refusing potentially better solutions or suggestions. In this case, copy-and-paste turned out to be that better solution, but with all the peer pressure surrounding avoiding such a method in addition to what I know about it, I would too refuse such an approach It''s only ironic that something relatively quite low on the "food chain of design" turned out to work better than something relatively high on the chain.

I suppose, when everything is said and done, there is no absolute design solution to any one problem. It''s just human nature for the mind to settle on something, and subconsciously perceive things in a way that suits what we already think rather than change. Especially when we learn new things, we like to try and utilize the most powerful tools for the simplest of problems. For example, I sometimes find myself using differential Calculus to solve algebraic word problems, just because that''s the most recent mathematics I know that can still solve the problem.

But I''ll stop rambling right here.