Archived

This topic is now archived and is closed to further replies.

Shannon Barber

Are design patterns language neutral?

Recommended Posts

Are design patterns language specific idioms, or do they transcend programming languages, and apply equally to C++, Java, SmallTalk, Python, etc.. & even to the CLOS? My view-point is the later, that the GoF patterns are abstract enough to apply to any object-oriented design in any environment. A decent example is the creational design pattern the ''factory method''; it''s use is demonstrated by the following code:
msg = deserialize(data);
 
msg is assigned to some object that deserialize determines using a moniker-to-class mapping. The moniker is contained inside of ''data'', and deserialize creates a known class from this information (else it generates an error). Possible implementations are to sub-class and provide a method to return a class object and then create an instance of it (SmallTalk), sub-class to build an explicit mapping and create a default instance (C++), or use parametric polymorphism and call a pre-determined method given a set of classes (Python).

Share this post


Link to post
Share on other sites
I''ve read some books on the subject that does not have even a single line of pseudo-code. I think that design patterns are a guide for good designs and its up to you to adapt the design to the language you are going to use, if it''s possible.

Share this post


Link to post
Share on other sites
quote:
Original post by Magmai Kai Holmlor
Are design patterns language specific idioms, or do they transcend programming languages, and apply equally to C++, Java, SmallTalk, Python, etc.. & even to the CLOS?

There are two ways of looking at it. Many of the GoF patterns are very language-specific. For example, they even point out in the book that CLOS doesn''t need Visitor, and they explain (I think) in the introduction that if they were writing the book with C, then single despatch would be a pattern. So, even GoF admit this. Disclaimer: I don''t have the book in front of me to confirm the exact wording, but that should be a sufficient paraphrasing.

The second way of looking at this is to consider that, just because we cannot find a language that doesn''t require a particular pattern doesn''t mean that the pattern transcends languages. It might mean simply that we don''t know of a "better way". It''s important to recognise the underlying purpose of Design Patterns, which has been discussed in NotAnAnonymousPoster''s recent thread. It''s fairly apparent to me (and not just me) that GoF''s patterns are not what Alexandrian patterns are about. It is better to call them idioms, even if we consider that some of them are language agnostic idioms (which is quite a hard claim to support). What''s in GoF is at no different a level to what''s in Coplien''s Advanced C++, the O''Reilly cookbooks or even something like the "Effective" books. Patterns are supposed to be different to that.

Share this post


Link to post
Share on other sites
I think design patterns fall into two parameterized categories: language -non-trivial and language -trivial. Let''s take my favorite design pattern: "addition of integral numbers". Probably your language of choice makes using the "addition of integral numbers" pattern pretty trivial. But if you program on a Turing machine, or in a pure lambda calculus, or even Brainf*ck, then the "addition of integral numbers" pattern becomes non-trivial.

Consider single dispatch. In C you need to set up your function pointer tables and copy the pointers to the tables manually. In C++, you just add the virtual keyword in a few places and you''re done. Single dispatch might be considered C-non-trivial and C++-trivial.

Consider the factory method of serialization/deserialization. In C++ you need to set up a system of type id''s, generate a mapping somehow, make sure the right functions get called, etc. In C#, you slap the [Serializable()] attribute on a class, and you''re done. So the factory method might be considered C++-non-trivial and C#-trivial.

The fact that a given language makes fill-in-the-blank easy, doesn''t make fill-in-the-blank less of a pattern. If anything, it validates its existence as a pattern. After all, if it''s not worth doing, why make doing it easier? And if it''s a really great pattern, we might start hardware accelerating it. E.g. math co-processors for the "floating point addition" pattern, or 3d acceleration for the "draw a triangle" pattern.

Oh, and I was kidding. "Addition of integral numbers" isn''t my favorite pattern; "halting program execution" is my favorite pattern.

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
Disclaimer: I don''t have the book in front of me to confirm the exact wording, but that should be a sufficient paraphrasing.



"The choice of programming language is important because it influences one''s point of view. Our patterns assume Smalltalk/C++-level language features, and that choice determines what can and cannot be implemented easily. If we assumed procedural languages, we might have included design patterns called "Inheritance", "Encapsulation" and "Polymorphism". Similarly, some of our patterns are supported directly by the less common object-oriented languages. CLOS has multi-methods, for example, which lessen the need for a pattern such as Visitor. In fact, there are enough differences between Smalltalk and C++ to mean that some patterns can be expressed more easily in one language than the other."



Share this post


Link to post
Share on other sites
quote:
Original post by SiCrane
Let''s take my favorite design pattern: "addition of integral numbers".

Let''s not. It''s not a design pattern, which is the point I''m trying to make. There''s two issues. I think Magmai is asking "are GoF patterns/idioms/whatever language agnostic?" rather than "are patterns language agnostic?". I''m pointing out that GoF "patterns" are neither language agnostic nor even patterns. Once we stop considering GoF patterns to be correct patterns, we can stop being surprised when we find things out about them such as "CLOS doesn''t need Visitor", and we can get on and assess them in a more rational manner. As long as we insist they are something more than language-specific idioms, we continually run the risk of abusing languages and idioms. This is the reason some people consider GoF, or rather the aura surrounding GoF, to be harmful.

Share this post


Link to post
Share on other sites
Could one say that the GoF "patterns" are in fact establishing a sort of basic vocabulary of software engineering - a set of language concepts that are useful, probably necessary, but not always available directly through the language?

It could explain why the book is so popular among C++ programmers, because it completes their vocabulary, making them more versatile programmers.

Share this post


Link to post
Share on other sites
I''d like to see someone implement a factory in LISP, I could probably do it in BASIC but not in FORTRAN.

So my answer is no. The GoF patterns are not language agnostic (nor are they thread safe).

But then again define a computer language. Some languages are marely subsets and used for educational purposes only (well they did when I was in school), and others have specific uses (ADA). So really we need to define what are qualifying langauges, after all the Ti rang of calculators have a language as well.

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
Let''s not. It''s not a design pattern, which is the point I''m trying to make.

Ok, I''ve yet to see you post this, but what exactly is your definition of a design pattern, and why wouldn''t this be a pattern? Or, if your definition is an entire book taking 500 pages because you want it that precise, what clauses of your definition is it violating?

quote:

There''s two issues. I think Magmai is asking "are GoF patterns/idioms/whatever language agnostic?" rather than "are patterns language agnostic?". I''m pointing out that GoF "patterns" are neither language agnostic nor even patterns.


Even Richard Gabriel has been known to refer to the GoF "patterns" as patterns. (Maybe it was a moment of weakness, who knows?) However, for better or for worse, many people, including Doug Lea, classify language-specific idioms as patterns. Albeit, patterns that have context clauses like: "AND you''re using a brain dead language".

quote:

Once we stop considering GoF patterns to be correct patterns, we can stop being surprised when we find things out about them such as "CLOS doesn''t need Visitor", and we can get on and assess them in a more rational manner. As long as we insist they are something more than language-specific idioms, we continually run the risk of abusing languages and idioms. This is the reason some people consider GoF, or rather the aura surrounding GoF, to be harmful.

I agree that the GoF book is an imperfect example of design patterns. However, I do so, not because I consider the patterns not to be patterns, but because the patterns possess implicit restrictions not specified in the context/motivation portions of the pattern descriptions. Moreover, the alternatives to when those implicit restrictions are gone are not presented (or at least not adequately presented).

And I think that far fewer people would be confused about the visitor pattern, had they named it after the problem it was meant to solve instead of a clever metaphor for how the solution is implemented.

Here''s a question for you: do you consider any of the GoF patterns to be "real" design patterns? Or does the whole thing go in the rubbish bin of idiom?

It could just be that we need to agree that we disagree on what "design pattern" means. In my definition, you have the umbrella set "Patterns". "Patterns" then has the subsets "Software Patterns" and then "Architecture Patterns", "Stuffed-animal Patterns" etc. In "Software Patterns" you have the subsets "Design Patterns", "Analysis Patterns", "Development Patterns", etc. In "Design Patterns" you have "Programming Idioms", "Algorithms", "Data Structures", "Protocols", etc. Of course these aren''t necessarily disjoint subsets. "Algorithms" has a non-empty intersection with "Data Structures"

Share this post


Link to post
Share on other sites
quote:

So my answer is no. The GoF patterns are not language agnostic (nor are they thread safe).


They''re as thread safe as you make them. I don''t recall any of the GoF patterns being inherently thread unsafe.

Share this post


Link to post
Share on other sites
I think the term ''Pattern'' in this context does not apply to a certain type of behaviour - as would be implied in "adding integral numbers" or indeed "halting program execution". Design patterns are more about how to arrange the high-level building blocks of a programming language in order to solve a whole class of problems.

My answer to Magmai is encoded in the above reply to SiCrane: I think patterns are highly language-dependent, and not just because of what the GoF have said. My view on the matter is that patterns are a way of abstractly representing the mapping of a programming language to a generic software development problem. Some languages don''t require a given pattern to achieve a certain goal.

To follow the given example, whether you call the Factory Method a pattern or not really depends on how lenient you want to be. At one extreme you could consider malloc() to be a factory method, as it is a parameterised function that returns a newly-allocated object. Therefore I think that the essence of the pattern is in the arrangement of classes and objects, meaning that the need for given patterns will vary according to the functionality of the underlying language.

[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost

Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
There are two ways of looking at it. Many of the GoF patterns are very language-specific. For example, they even point out in the book that CLOS doesn''t need Visitor, and they explain (I think) in the introduction that if they were writing the book with C, then single despatch would be a pattern. So, even GoF admit this.


That doesn''t change the fact that a dispatch pattern exists. It’s just a specific variation (single dispatch) implemented by the programming language for you and given a special name in that context (virtual function, or method). The fact that it is built into the language makes the pattern that much more useful to identity and understand so you can exploit the language feature.

You could explain the inheritance pattern to a C programmer by showing them the difference between nesting structures and using nesting as a means to extend a previously defined structure. That the OO "class classEx : OldClass" and the C "struct structEx {OldStruct s;};" are both code artifacts of the inheritance pattern.

I''m entirely willing to thrash the GoF patterns, and their methodology for describing the patterns from such an OO centric view-point, but by simply scrubbing off the OO color you have sufficiently abstract patterns to work with.

quote:

The second way of looking at this is to consider that, just because we cannot find a language that doesn''t require a particular pattern doesn''t mean that the pattern transcends languages.

Just because a language does not require user-code infrastructure to realize, does not mean the pattern is non-existent in the context of that language.

quote:

It''s important to recognize the underlying purpose of Design Patterns, which has been discussed in NotAnAnonymousPoster''s recent thread. It''s fairly apparent to me (and not just me) that GoF''s patterns are not what Alexandrian patterns are about. It is better to call them idioms, even if we consider that some of them are language agnostic idioms (which is quite a hard claim to support).


It’s not clear to me how we can draw any sort of mapping from the “Street Café” pattern to software design, nor any of the more abstract Alexandrian patterns, such as “Identifiable Neighborhood”. How are they any more universal to architecture, than the factory method is to software design?

quote:

What''s in GoF is at no different a level to what''s in Coplien''s Advanced C++, the O''Reilly cookbooks or even something like the "Effective" books. Patterns are supposed to be different to that.

Indeed, there''s very little material about design in any of the effective books. Advanced C++ will presumably be focused on C++ semantics which will have some overlap with OO semantics, and outside of demonstration purposes, have nothing to do with patterns.

quote:

I think Magmai is asking "are GoF patterns/idioms/whatever language agnostic?" rather than "are patterns language agnostic?"


Well, both. Design patterns should be language agnostic. If any or all of the GoF patterns are not agonistic, then we should reject them as patterns (or refine them so that they are acceptable).

quote:
I''m pointing out that GoF "patterns" are neither language agnostic nor even patterns. Once we stop considering GoF patterns to be correct patterns, we can stop being surprised when we find things out about them such as "CLOS doesn''t need Visitor", and we can get on and assess them in a more rational manner. As long as we insist they are something more than language-specific idioms, we continually run the risk of abusing languages and idioms. This is the reason some people consider GoF, or rather the aura surrounding GoF, to be harmful.


Ok, what is a language neutral pattern? And why does Lisp not needing visitor mean it’s not a pattern? In isolation it is not good evidence– Python does not require the inheritance pattern, so inheritance is not a pattern?
What’s a pattern that Lisp does require? If it requires none, then by your reasoning, would that not mean no patterns exist?

How do we determine that CLOS doesn’t need the visitor pattern? Because it has a built-in facility to accomplish the same thing? What is this built-in facility called? When you use that facility to accomplish the same thing the visitor pattern does, you’re using the visitor pattern. If a language has multi-methods built-in, and you pass a multi-method two different objects – you’re using the double dispatch pattern.

Share this post


Link to post
Share on other sites
The GoF patterns are patterns, on multiple levels ... just not ALL levels.

If you are a cloth designer interested in fusing ideas from two different types of dresses, you will pull in knowledge from what it means to be "clothes" "dresses" the two categories in question "formal evening dresses" and "victorian dresses" (just an example), and then some specific dress patterns in said themes.

The GoF book attempts to start at the top level "Design Patterns" and define a few subsets "Creation Patterns" ... and within the subsets provide specific categories/patterns "Chain of Command" "Composite" ... and within these, provide actual code and model templates corresponding to specific examples of them (a particular dress == a particular widget or maze building example) ...

The fact that this set of patterns, at all levels, has limits on its relevance / applicability / usefullness, does not make them non-patterns. It makes them fall under the realm or domain-specific knowledge, instead of domain-general knowledge, just like nearly everything else we know about any form of computing, science, math, or physcology. The are patterns in the sense that they are NOT components, and NOT code, but instead are more like heiuristics or algorithms for organizing or creating code, and as such, they are only valuable in solving problems within certain domains.

A heiuristic / algortihm to solve equations is competely uneeded by a programmer using a language with such features already built in, but that does not mean it is not a heuiristic ... just not relevant.

Share this post


Link to post
Share on other sites
quote:
Original post by Kylotan
I think the term ''Pattern'' in this context does not apply to a certain type of behaviour - as would be implied in "adding integral numbers" or indeed "halting program execution". Design patterns are more about how to arrange the high-level building blocks of a programming language in order to solve a whole class of problems.


"halting program execution" was tongue-in-cheek, hence the smiley I stuck there.
Unfortunately "adding two integral numbers" was not tongue-in-cheek. As neither the basic Turing machine nor pure lambda calculus have a notion of integers inherent in their specification, you have to build a representation of integers and then define some set of operations in order to combine the representations into an addition subroutine. And as there are no unique representation schemes for integers in these cases, you''d need to call the addition of two integral numbers a family of solutions for these languages. In fact there are at least three different representations of integers for the basic Turing machine, so it satisfies the "Rule of Three." Which is starting to add up to a pattern by most definitions. I suppose I can see it, if someone doesn''t want to prepend the "design" word, though.

Share this post


Link to post
Share on other sites
Magmai Kai Holmlor:
Not exactly the question you asked but here are some links on how the GoF patterns fare in Lisp/Dylan/Scheme:

Peter Norvig''s classic presentation, at least it gets linked to a lot on newsgroups:

http://www.norvig.com/design-patterns/ppframe.htm

Specifically pay attention to slide number 10. (And please note that he says "invisible or simpler" which in no way imply that they actually stop being patterns.)

Gregory Sullivan''s paper commenting on the GoF patterns in Scheme/Lisp/Dylan:

http://www.ai.mit.edu/~gregs/aim-2002-005.pdf

Here''s a quote from page 42, specifically on the Visitor pattern:
quote:

While many people dismiss the Visitor pattern as being "nothing more than double dispatch," there are still design issues related to how to traverse composite objects in the graph. Having multiple dispatch available gets rid of some of the tedium of the Visitor pattern, but does not address all the design and implementation issues.

Share this post


Link to post
Share on other sites
I view patterns as agony of OOP, that will put the end to OO programmers pseudo-elitist dreams of object hegemony, and will result in revolution, after which OO and non-OO paradigms will learn to co-exist in peace and harmony.

I have the following complaints about patterns :

1. I don't think they represent common programming problems, they appear to be chosen randomly. It's trying to find some application of objects, rather then solve real practical problems (that is, creating the tool first, then seaching what can be done with it, it's just awkward).

2. Even if the PROBLEMS identified by patterns are real, I don't think it's possible to came up with universal SOLUTIONS for such generic problems as object creation, state machines or multiple dispatch. IMO, the best that can be done are some universal GUIDELINES for such problems (making patterns useless).

3. Most of the solutions proposed by patterns I have seen (not that I have seen much of them) are ugly hacks that attempt to fix the non-flexible nature of C++, Java or similar languages (and as a result they ARE language dependant).

4. Pattern solutions tend to enforce the "everything is object" doctrine to the paranoid degree. You can download Bruce Eckel's "Thinking in Patterns" and look at his state machine code. Every state is defined as a separate class, resulting in a 300 lines of unreadable, unmaintainable mess for a trivial problem, which can be solved by 30 lines of code (accompanied with the remark, that for more complex situations you can write program that generates the source code - from a more compact representation, I guess, but then - why convert it to bloated Java code instead of using it directly?).

5. If the result of applying patterns in real life look like Java's Swing library (it's completely written in Java, heavily using OOP), then it's better to return to assembly coding, rather than continue this madness. Why in the world they replaced well-tried event loop approach with multithreaded mess made of object calling each other without any order? This "everything before objects was wrong" attitude sucks.


[edited by - Advanced Bug on March 19, 2003 3:51:57 AM]

Share this post


Link to post
Share on other sites
quote:
Original post by SiCrane
Ok, I''ve yet to see you post this, but what exactly is your definition of a design pattern, and why wouldn''t this be a pattern? Or, if your definition is an entire book taking 500 pages because you want it that precise, what clauses of your definition is it violating?

There''s more about that in this thread.
quote:

Even Richard Gabriel has been known to refer to the GoF "patterns" as patterns.

I suppose you could build an argument that they are patterns in some sense or other, particularly as there is no formal definition of "pattern". However, it''s more important to consider the spirit of Alexander''s ideas, and I don''t feel that GoF is really in the right spirit. Consider also that Alexander had to continually revise his ideas of patterns as he went deeper into his investigation. I suggest we do something similar, and don''t stop with thinking GoF is somehow the embodiment of what is being searched for.
quote:

Here''s a question for you: do you consider any of the GoF patterns to be "real" design patterns?

Perhaps, but no so much in the individual patterns. For example, there appears to be a pattern in the idea of construction policies in general. If you add in something about how an expert designer would decide on constructional policies within a particular problem, then you have something closer to what I consider as a pattern. For example, in Magmai''s OP, what judgements led to creating a "deserialise" method? What does it do? Why does it do it like that? What else needs to be in place for it to work how it does? That''s a pattern. If you then go and consider the associated bits and pieces, such as "well, there is a message repository which deserialise accesses to find a class, and the repository was built like this... and for this reason..." then you are approaching a pattern language.
quote:

Or does the whole thing go in the rubbish bin of idiom?

Please don''t caricature my position in that way. You''re implying I think idioms have no worth, which is not at all the case. I''ve never contested outright that GoF patterns are useless. After all, I use them myself. The issue is that patterns are supposed to impart good advice to less experienced developers so that they might write better programs. GoF provides the mechanisms, but it is missing much of the rationale. This means that GoF mainly benefits those who are already good designers, and does not help less experienced designers think like a good designer. That''s why I disregard them as patterns.

Share this post


Link to post
Share on other sites
quote:
Original post by Magmai Kai Holmlor
That doesn''t change the fact that a dispatch pattern exists.

Only if you are being consistent with the view that what is described in GoF are really patterns. Since I''ve said I don''t believe they are, it should be apparent I wouldn''t admit to dynamic despatch being a pattern.
quote:

Just because a language does not require user-code infrastructure to realize, does not mean the pattern is non-existent in the context of that language.

Patterns aren''t of code, they are of people.
quote:

Indeed, there''s very little material about design in any of the effective books. Advanced C++ will presumably be focused on C++ semantics which will have some overlap with OO semantics, and outside of demonstration purposes, have nothing to do with patterns.

Well, a large part of Advanced C++ is about emulating other languages, such as incorporating the metaclass concept. In that regard, it''s rather consistent with much of GoF.
quote:

Well, both. Design patterns should be language agnostic.

Yes, but we shouldn''t be looking for language agnostic implementation constructs. They are language agnostic because they aren''t about implementation.
quote:

If any or all of the GoF patterns are not agonistic

Nice typo.
quote:

then we should reject them as patterns (or refine them so that they are acceptable).

That''s exactly what I''m suggesting. I''m not saying they''re not useful. From an alternate viewpoint, the idea is that you shouldn''t so much be making conscious decisions to employ patterns as "just designing" and perhaps ending up with patterns in your code without consciously using them. That''s what separates good designers from average designers, and it''s what Alexander is trying to capture.

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
From an alternate viewpoint, the idea is that you shouldn''t so much be making conscious decisions to employ patterns as "just designing" and perhaps ending up with patterns in your code without consciously using them. That''s what separates good designers from average designers, and it''s what Alexander is trying to capture.

And for people learning to be good designers, it should be about spotting a particular problem and identifying whether a documented pattern might be a good solution. This includes not being afraid to design something totally different. One problem I''ve seen is people who are eager to use patterns before they have a real need for one... like a carpenter running around with a new hammer, frantically searching for a nail.



[ MSVC Fixes | STL Docs | SDL | Game AI | Sockets | C++ Faq Lite | Boost

Asking Questions | Organising code files | My stuff | Tiny XML | STLPort]

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
I suppose you could build an argument that they are patterns in some sense or other, particularly as there is no formal definition of "pattern".


Actually, there seem to be several well used, accepted, definitions of the term "pattern" that qualify the things presented in the GoF book as "patterns," but we''ll ignore that for the moment. The one definition of "pattern" I''ve seen you admit to seems to allow idiom as a "pattern," so obviously it''s a simplification of the actual ideal of "pattern" you seem to hold.

Aside from your contradictatory definition, your posts seem to drift between either patterns as the Tao: "The Pattern that can be defined is not the real Pattern" or patterns as pornography: "I can''t tell you what one is, but I''ll know it if I see it."

And seeing as how patterns are primarily about communication, this seems self-defeating.

quote:

However, it''s more important to consider the spirit of Alexander''s ideas, and I don''t feel that GoF is really in the right spirit. Consider also that Alexander had to continually revise his ideas of patterns as he went deeper into his investigation. I suggest we do something similar, and don''t stop with thinking GoF is somehow the embodiment of what is being searched for.


I don''t think anyone here as said that the GoF patterns are the end-all, be-all of patterns.

quote:

Here''s a question for you: do you consider any of the GoF patterns to be "real" design patterns?

Perhaps, but no so much in the individual patterns.


I cannot find any source - book, published paper, or even serious website - that supports your view that the individual GoF "patterns" are not patterns. The best I can find is that the GoF patterns are not "design patterns" but are instead are categorized as a different kind of pattern.

Can you point me to any reputable source that supports your view that the individual GoF patterns are not actually patterns?

quote:

Please don''t caricature my position in that way. You''re implying I think idioms have no worth, which is not at all the case.


Seeing as you haven''t said a single good thing about the GoF patterns or idiom previously, it''s easy to see how I could believe that you think that way.

quote:

The issue is that patterns are supposed to impart good advice to less experienced developers so that they might write better programs.


Then, how does that make idioms not patterns? This is part of what led me to believe that you thought idiom was a rubbish bin. Effectively, by saying idioms are not patterns, you say that they aren''t good advice.

quote:

GoF provides the mechanisms, but it is missing much of the rationale. This means that GoF mainly benefits those who are already good designers, and does not help less experienced designers think like a good designer. That''s why I disregard them as patterns.


Ok, We agree that the GoF book needs work, but, even if I agreed with your statement that they don''t help less experienced people, just because the context/motiviation/rationale sections need work, doesn''t make them less of patterns; it just makes them poorly presented/written patterns.

Does a pattern, to you, refer to the abstract idea presented in a document, or the document itself?

Share this post


Link to post
Share on other sites
quote:
Original post by SabreMan
That''s exactly what I''m suggesting. I''m not saying they''re not useful. From an alternate viewpoint, the idea is that you shouldn''t so much be making conscious decisions to employ patterns as "just designing" and perhaps ending up with patterns in your code without consciously using them. That''s what separates good designers from average designers, and it''s what Alexander is trying to capture.


That''s completely backwards! The good designer "just designs" and the average one is introspective about the design?

quote:
SabreMan
Original post by Beer Hunter
The Hyphen
That''s an excellent example of a pattern.


That''s a horrible example from a different problem domain (English grammar). My instinct is that it is too specific to be a pattern, but a good designer knows to hold their instinct in check. The more serious issue is that the hyphen is used for (at least) two different problems. It is used to indicate the continuation of the same word across a logistical barrier, and the concatenation of two different words to avoid ambiguity. This is a resounding alarm for either a designer or architect - it demonstrates a lack of conceptual integrity in the design. The lack of conceptual integrity is preeminent when these different uses of the hyphen coincide, which I will demonstrate after I identify the patterns involved.

I would term it an idiom to distinguish it from a pattern; it''s a means to implement a pattern. The hyphen idiom is overloaded as is used with different meanings to solve different problems. I would hazard to call the most common pattern "Line Justification", and one solution is to break words using hyphens to optimize the use of the available text-space (how''s that for irony), a more aesthetic solution is to send the entire word onto the next line but this consumes more text-space (a design trade-off). "Line Justification" is similar to the "Pagination" pattern, but they operate a different level of scale (lines vs. paragraphs). They both are sub-patterns of a parent abstraction, that we could call "Logistical Justification".

A second pattern is "Compound Words", and comes in both "Compound Adjective" and "Compound Noun" flavors. It can be implemented by hyphenation (half-time, dark-blue), concatenation (eyebrow), or contraction (smog). Compound adjectives are always hyphenated, whereas compound nouns are both concatenated and hyphenated with the occasional use of contraction. The use is inspired by convention, rather than some architectural goal (maximize use of text-space vs. make it easy to read). This pattern is trivial (uninteresting) for conventional cases (since there is no design decision to be made). It is only relevant to a word-smith when they are inventing a new term (such as text-space).

The conceptual integrity crack is visible when a hyphenated compound word is also subjected to a logistical barrier. The pathologically consistent result is to use two hyphens, but this is aesthetically gross and inconsistency results from the use of one hyphen. Ambiguity then results since we cannot distinguish between word continuation and a spurious dual occurrence. We must now resort to an exhaustive search to determine which case it is. The writer has to break the design to meet his ‘aesthetically pleasing’ architectural goal.

Abstractions that maximize conceptual integrity are the essences of a good design, and consequentially a good designer must be able to find them. By naming ‘small-pieces-of-abstraction’ (by naming patterns) we can facilitate communication. The communication can be maximized by using a common set of distinct terms.

Share this post


Link to post
Share on other sites