Tags:
create new tag
, view all tags
I don't know if design patterns are considered strictly an object oriented thing, if they are, I think that's overly restrictive (or I'm missing the point).

My attempt at a definition of a design pattern (surely based on things I've read and heard from others):

A design pattern is a pattern (model, framework, blueprint) for the implementation of a piece of software functionality that may be useful in more than one application.

As an example, it is common to have a need to go through some collection of items and do something with each one of them — thus the "iterator" pattern.

A design pattern may be just a pattern (that is, an english language, UML, or similar description of software functionality), or may actually be implemented in code (possibly as a built in function in a particular language, or a sample implementation in a particular language) — IIUC, Perl includes built in iterators for some or all of the built in datatypes (??) like arrays and hashes.

A non-object-oriented example of the iterator pattern is the common scripting construct that does something for each file in a particular directory, characterized by statements like:

for f in . do <something>

The value of a design pattern includes that many of the things that you will need to consider in developing that particular function for your particular instance (potential gotchas) are already highlighted by the pattern.

The reasons a design pattern is not always presented as code (or implemented as a built-in function in a language) include:

  • In most cases patterns are applicable to multiple languages, thus a non-code description is more universal, and more easily understood by non-native "speakers" (coders) of any particular language
  • Exclude patterns expressed in UML from the "more easily understood" comment above wink
  • Code may be too specific a presentation of the required logic — if you are writing objects for an object oriented application, the pattern may have to be slightly different for some of those objects (the principles the same, but the actual implementation different) (this despite the fact that the object-oriented features like inheritance ideally should allow you to minimize such differences between objects (or maybe (rather) make such differences easier to handle, because you can inherit what is "identical" and then modify the minimum that must be different)

IIUC, the iterator pattern suggests that you need a way to know when the iteration is done (when next is empty), to obtain the value of the current item, etc. The iterator example is fairly simple without too many "gotchas" — part of the point of the pattern, though, is to show where those gotchas are before you start coding. (On the other hand, if the pattern is already implemented in a language (or in a toolkit, or whatever, presumably those gotchas have already been addressed).))

(I didn't entirely make this stuff up, I found some resources recently that helped me get the idea (as always, I should add a disclaimer, like "if I got the idea"). I should record those resources on this page. Unfortunately, I "fat fingered" (thank you, Dennis Williams) those resources away — hopefully I'll find them again.

The iterator may be almost too simple an example to show the benefits of the design pattern, I may want two examples — the iterator to provide a very simple example (although it gets more complex depending on what you are trying to iterate through) and a more complex example. I guess if I studied the factory pattern (which, IIUC, somehow helps you (your program) create objects as necessary), one of the gotchas that would be dealt with in the pattern would be the allocation of memory when the object is created, and the deallocation when the object is destroyed.

See:

Contents

Notes

Contributors

  • () RandyKramer - 22 Aug 2003
  • If you edit this page: add your name here; move this to the next line; and if you've used a comment marker (your initials in parenthesis), include it before your WikiName.

Page Ratings

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2003-08-25 - RandyKramer
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by PerlCopyright 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding WikiLearn? WebBottomBar">Send feedback
See TWiki's New Look