Re: Programming patterns

[McA]

Hi all,

thank you all very much for your comments. I'm really surprised that I got such much reaction on my post.

I would like to hear how someone can check code for such and other code smells. Is it really only possible with experience? Or is there a way to work down a kind of checklist?

It's really interesting to hear the opinion that following patterns religiously can also lead to "bad" code. But at the end you hear as often: It depends. I have to live with that in the hope to learn the right feeling to avoid bad design.

Are tutorials out there which help to understand OO patterns especially for interpreted programming languages with loose types?

Best regards
McA

[BrowserUk]

I would like to hear how someone can check code for such and other code smells.

The first thing I would say is, if you are spending your time worrying about minor interface design details like these, you must have too much time on your hands.

Unless you are writing an interface for a module that is going to be reused by 100s or 1000s of people for the next decade or so, the difference such small, academic refactoring of this sort will make in the overall scheme of things are negligible.

The reality is that most classes defined by most people rarely get reused beyond the project that they are defined for. And these days, far more sins are committed in the name of methodology purity (mostly OO purity, but also FP purity; AO purity etc.), than were ever committed in the name of premature optimisation.

Is it really only possible with experience?

Yes. But it is possible to simulate some of that experience to some degree -- iff you can justify the effort.

Ie. If there is very good reason for you to realistically believe that the interface that you are designing will be reused sufficiently widely to justify the time and effort you put into it.

The way to do that, is to try and use the interface in at least two substantially different (sub)projects. That is, define the interface on paper. If possible, mock up that interface in a "compilable" module that does nothing beyond checking arguments and returning "realistic" values.

Then get a couple of people -- preferably people other than the interface designer -- to independently -- of each other and the designer -- prototype calling applications using the defined interface. With reasonably experienced people, this process shouldn't take more than 2 or 3 days. If it does, it probably means that it has found a problem.

Or is there a way to work down a kind of checklist?

Once the two prototypes are put together, get all three people in a room and go through the way the interface has been used in those prototypes. Contrasting how two people independently try to use the interface; and then contrasting those with how the designer thought it would be used. This process will usually do far more to highlight inconsistencies, omissions and redundancies in an interface design than any amount of running check lists, or other academical, criteria-driven soul searching done in isolation of actual real-use calling code.

Interface design is all about the 'user experience'. Don't read that as the overused, over-hyped marketing phrase. In this case, the users are the programmers that will use the interface; and it isn't about warm and fuzzy "feelings", it is about the interface lending itself to the use by the calling code, without forcing that code into awkward, repetitive or inefficient hoops.

The interface should be designed for the ease of learning and programming of the calling code; not the personal philosophies of the designers or the ease of internal implementation.

Remember, the neo-classical adage that programmer time is more valuable than cpu time isn't true, if the time saved by the programmer that does the internal implementation, is at the expense of every programmer that has to use that implementation.

Nor, if it makes the end users of every application written using it, sit around waiting, while it burns unnecessary cycles and power.

[dsheroh]

It's really interesting to hear the opinion that following patterns religiously can also lead to "bad" code.

The thing to remember about patterns is that they're meant to be descriptive (a way of communicating what you're doing to other programmers) rather than prescriptive (a way of telling you what you should do). Bad code frequently results when you take a list of patterns and decide to use them purely because they've been blessed as Patterns(TM) rather than analyzing your problem, looking to see the most appropriate way to solve it, and then using patterns to express that solution.

There's also the side issue that patterns are generally ways of filling gaps in the language that you're using (Perl has no patterns for finding text which has certain characteristics within a string because the language's built-in regex support is better than anything you're likely to write in your application code), so problems also arise from inappropriately applying one language's patterns in another language which has a better way of solving the problem at hand, but that seems to be a less common cause of pattern-derived bad code.

[jdporter]

Absolutely right on both counts, dsheroh. Well said.

However, I would rephrase "Perl has no patterns for..." as "Perl programmers don't need patterns for...", since, generally, patterns don't exist within a programming language. (I mean, obviously there are patterns in the design of a language, but that's a different animal.) Also, I think you should have chosen a different example than "finding text ... within a string", since, in the context of that kind of problem, the term "pattern" has another meaning, so the description of your example could be (certainly was to me at first) confusing.