The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Design Patterns: Friend or Foe?

Hello all,
I am a senior C++ software engineer.
At my work place there is a younger programmer.
He is clever and hard working.
However he often design in terms of first choosing which pattern to apply. Often he ends up rewriting his code several times. I think the problem is that when you have invested a lot of effort in learning a new pattern you want to apply it, even if it is not the right one for the task at hand. Myself I always try to come up with a solution all of my self, if that so happens to be a pattern: great! Earlier I read a bit about patterns but found myself doing the same thing as the younger programmer.
I remember that when reading about design patterns part of the motivation was to faciliate communication between programmers. I do not see that happening. The younger programmer might try to explain his design his by referring to a pattern, but I seldom remember the name of the patterns. If I do I often think the pattern is not appropriate for the task or sometimes I think he has misunderstood the pattern. 
I guess If we all were pattern experts the facilitating communication point would be valid.
However I do not think it is worth the effort.
In my mind improved design mainly comes trough experience designing real software.

Any thought on this?
Thanks in advance for any replies!
Anon for this one
Saturday, March 10, 2007
 
 
Not enough information to render a judgment.

Is it taking him longer than estimated to complete his tasks?  Does he tend to take longer than other people on comparable work?  If so, is his code of better quality as a result?  Is it easier to read and understand, and does it work better and with fewer bugs?  Producing good-quality code is often a matter of short-term losses in favor of long-term gains.  So if his code is better, you won't necessarily see a tangible benefit immediately.

On the other hand, if he's taking longer and producing _worse_ code, or if his code is harder to understand than other people's, or if it's producing more bugs on average than most developers', then his manager should have a talk with him.

However, I gather that his manager is somebody else, not you.  In such cases I've usually found it better to focus on my own work and keep my mouth shut.  If someone's not productive, or is creating problems for other people, the truth will gradually become clear.  In the meantime, complaining about people to management may get results, but usually doesn't reflect well on the complainer.

If you need to explain how his work is causing you problems, do it in such a way that you leave his name out.  ("It took me a while to finish because I had to troubleshoot a lot of bugs in the XYZ module"; don't mention who coded the XYZ module.)
Kyralessa Send private email
Saturday, March 10, 2007
 
 
Patterns are essentially recipes.  The problem comes when you spend too long tinkering with your code in an attempt to exactly match a pattern as described in a book.

Instead you should approach the as a chef does a recipe and use them as a guideline and to understand the basics of a mechanism.  It can be very compelling, the desire to perfectly implement some interesting new idea.  Alas, this often takes too long and every bell and whistle doesn't end up adding much actual value in the real world.
Dan Fleet Send private email
Saturday, March 10, 2007
 
 
Refactoring in itself isn't bad...  refactoring regularly can be very good as it keeps the code a bit fresher in your mind and you have the opportunity to look at problems fresh each time.

If he's trying to force a Pattern to meet his usage, that can be bad/difficult, but it doesn't seem like that's the problem...
KC Send private email
Saturday, March 10, 2007
 
 
"I guess If we all were pattern experts the facilitating communication point would be valid.
However I do not think it is worth the effort."

I worry that I will feel the same way as I grow older.
dev1
Saturday, March 10, 2007
 
 
(about learning new things)
dev1
Saturday, March 10, 2007
 
 
As a fairly senior developer myself, I really like patterns. They give me a mental language for thinking about a problem at a higher level of abstraction than code but a lower level than requirements. They codify common designs. Think about them as a library for design.

If written in the style of GOF, they also provide contexts, pros and cons for each particular pattern to guide in their use. Perhaps the junior developer doesn't have the experience to utilize this part of the patterns effectively.

They not only facilitate thinking about a problem but talking about it, if everyone understands them. It sounds like some of the reason you're not getting this benefit is because you aren't as familiar with them as the other developer.

Perhaps some of the slowness and rework you're seeing him do is due to his inexperience overall combined with using a new tool. Maybe you could familiarize yourselve with patterns more so you have a better grasp on them and then the two of you together could work through some of the issues he's struggling with. You'd be using your greater expertese and experience to guide him so he doesn't thrash around so much. Along the way you'd be picking up a new tool for your toolbag too.

Hope this helps.
Harley Pebley Send private email
Saturday, March 10, 2007
 
 
I completely agree with you, Anon. For me, the word "pattern" means something universal what will never perfectly suit my needs. Of course, they can give me a solution of a problem or I can adapt them to my needs but I will never think like "which design pattern would be the best for this project?" in a design process. And I think that they often kill our creativity. It's just easier to implement a ready pattern than to think about our own ideas.
Grzegorz Kędzierski Send private email
Saturday, March 10, 2007
 
 
Anon,

I also agree with you.  To me the right process is: (a) figure out a good solution to the problem (b) if you recognise some parts of it as named design patterns, then great, you have names for those parts.  If not, that's fine.

The wrong process it so start with the goal of "choosing some design patterns" in the forefront of your mind.

John
John Rusk Send private email
Saturday, March 10, 2007
 
 
My primary dislike for patterns relates to the fact that, generally, if you need a pattern, it's a sign your development environment is lacking an abstraction.  When I start seeing a lot of patterns in my code, I start getting annoyed at Java or C++ and wish I could earn a living with Lisp, Smalltalk, or whatever, and no one wants to be that guy.

The classic example is the visitor pattern -- multiple dispatch alone would eliminate this pattern.
Art Send private email
Saturday, March 10, 2007
 
 
I don't understand why people have problems with patterns. Seems obvious that the software development field needs a mechanism to capture proven designs.

What would architecture be like if every time an archtect sat down and needed a mechanism for people to go from one room or another they sat down and tried to figure out the problem themselves. Each time coming up with a different solution. Walking around a building would be a nightmare.

Software doesn't have anywhere near enough patterns or standards.

In building, not only are there patterns, there are enforced standards for the way things are done too. So, doors are a standard size, have a certain level of fire proofing etc. It is about time we had the same in software.

If you are a senior engineer, why is this kid so far ahead of the game than you? Senior engineers are supposed to be senior because of their capabilities not because they've been in the job for a given amount of time.
Jack Send private email
Saturday, March 10, 2007
 
 
Harley and dev1 both make very good points.

Never assume that because you don't know/understand something that it's rubbish. That's how almost every poor manager I've ever had got to be so poor. I still remember an early technical battle I had with one manager:

"Don't use C. Assembler is the only true way to tell the  processor what you want it to do. Anyway, C just makes the code bigger and harder to read. And it forces you to work the way it wants to (using it's patterns) rather than the way you want to."

 -- Of course, this guy didn't know C and was never going to learn...

I believe that there are really good reasons for learning the "patterns" of software and using them. I am far more productive in C than assembler and I make far fewer mistakes (because I'm working at a higher level). It's also much easier for me to discuss issues with other developers in this language (compared to assembler). I can still use assembler if I want/need to.

That argument just keeps "boiling upwards". There are loads of languages available today for programming and you can find a zealot for each who'll tell you that theirs is the best. It's all rubbish. Computer languages are just tools, and there is no "golden hammer".

Good design patterns are _nearly_ language independent. You can code a Singleton in assembler and C++ - but the intent is the same in both. There-in lies their strength, they are a language independent mechanism for sharing concepts.

Of course I've found that over the years as you are reading code from hundreds of different sources that it becomes easier to see the intent of developers in their code. These are "patterns" which I've absorbed from experience. These too are valuable.

So in summary - I believe continuous learning and experience make for a good designer. An experienced programmer who won't learn new paradigms (i.e. the assembler manager) probably won't be a good designer except for in his one small, highly specialized area.

And the reverse is also true. The new guy out of uni with all the new lingo and techniques is just going to make mistakes when tries to naively apply his knowledge in areas it was never supposed to work.

-- My 2 cents
Coopsnakes Send private email
Saturday, March 10, 2007
 
 
I think that design patterns are overrated. Too many programmers think that using "pattern speak" makes them sound cool, and that they have to employ as many patterns as possible in their software. The patterns they choose are usually inappropriate for the problem they are trying to solve, which makes their solution far from optimal.

Design patterns are like lego bricks which help teach young children how to build things, but are totally useless to adults.

When I am building an application it is described as a series of user transactions or "units of work". Design patterns are therefore the wrong level of abstraction as they have no meaning when describing the transaction to the user or the programmer. This is why I favour the use of transaction patterns and have designed my framework around them. I have also build a transaction generator which allows me to apply any transaction pattern to any database table just by pressing a button. You cannot do this with design patterns, which is why design patterns are useless.

I do not consciously use design patterns at all. You may see evidence of some paterns in my framework, but that is by accident and not a deliberate design decision.
Tony Marston Send private email
Sunday, March 11, 2007
 
 
Quote:

---
"I have also build a transaction generator which allows me to apply any transaction pattern to any database table just by pressing a button. You cannot do this with design patterns, which is why design patterns are useless."
---

Um, what do I do if I don't have/need/want any databases in my software...?
Coopsnakes Send private email
Sunday, March 11, 2007
 
 
"When I am building an application it is described as a series of user transactions or "units of work""

'Unit of Work' is a design pattern. 

Patterns are simply recognizing common methods for solving a problem.  They talk about the design of the solution, not about specific implementation.  Patterns are not necessarily deep, profound insights.  They are simply a way of saying "if you're facing problem X, here's how its been solved by many different people in the past, and they all came to roughly the same idea."

You shouldn't set out intending to use patterns.  You should look at them when you realize "hey, maybe someone's done something like this before."  Then, when someone else has to maintain your code, they'll go "oh hey, this is a Unit Of Work, I know how these operate" and be on steadier ground.  It is a maintainability issue as much, or more than, an optimal design issue.


They're not a panacea, nor are they intended to be.  Patterns are simply a way of specifying solutions to common problems in a somewhat agnostic manner.
Dan Fleet Send private email
Sunday, March 11, 2007
 
 
Sadly, I have the feeling that annon for this could be my boss.  Hopefully not...

Sunday, March 11, 2007
 
 
It is reading threads like this that one understands why so much software doesnt work properly, is late, over budget...

If software was being delivered on time, to budget and worked then I could understand the skeptisism.

But, as we all know, that couldnt be further from the truth. The way software is constructed today is very poor.
Jack Send private email
Sunday, March 11, 2007
 
 
"The way software is constructed today is very poor."

This is an interesting point, we should be looking at software construction techniques and stripping away jargon.
Dan Fleet Send private email
Sunday, March 11, 2007
 
 
< Um, what do I do if I don't have/need/want any databases in my software...? >

My framework is for administrative web applications, and these applications ALWAYS use a database.
Tony Marston Send private email
Monday, March 12, 2007
 
 
< 'Unit of Work' is a design pattern. >

There may be a design pattern with that name, but you cannot build a piece of code with that pattern and then apply it to every "unit of work" (transaction) that you encounter in a large database application.

I have never heard of a transaction builder that allows to to link a design pattern or patterns with a resource so it can build a fully-functioning transaction which operates on that resource.

You can with transaction patterns. If you study large numbers of transactions you should notice a common theme - each transaction can be described in terms of (a) structure, (b) behaviour and (c) content. Patterns arise where different transactions have the same structure and behaviour, but different content. So if transaction A "does something" with TableA and transaction B "does the same thing" but with TableB then the only difference between the two transactions is that they operate on different tables (content).

The first trick is to identify all the different combinations of structure and behaviour and catalog them.

The second trick is to implement each of these patterns as a series of reusable modules so that every instance of a pattern uses exactly the same piece of code. In this way if you need to modify the workings of a pattern you change just one piece of code.

The third trick is to have transaction generator which allows you to link a pattern with one or more resources and have it generate the initial working code for you. In my framework all transaction patterns are pre-written and built in, and the resources (content) are generated from my data dictionary in the form of a single class file for each database table. It is therefore possible to generate a fully functioning transaction without writing a single line of code.

This type of thing cannot be done with design patterns as they are too primitive, which is why I hold the view that design patterns are dead and transaction patterns are the new kid on the block.
Tony Marston Send private email
Monday, March 12, 2007
 
 
>This type of thing cannot be done with design patterns as >they are too primitive, which is why I hold the view that >design patterns are dead and transaction patterns are the >new kid on the block.

So you are saying that design patterns are dead, right? And that the transaction **PATTERN** is the new kid on the block?

LOL
Jack Hughes Send private email
Monday, March 12, 2007
 
 
This is off topic but I raise the argument again...

I don't have/want/need databases in my software. So how is your transaction pattern going to help me?

Anyhow - this thread is dead. Like most software debates it's turned into "gut feel", "likes" and "dislikes". No science, no engineering, no metrics, no nothing.

:-)
Coopsnakes Send private email
Monday, March 12, 2007
 
 
"This type of thing cannot be done with design patterns as they are too primitive, which is why I hold the view that design patterns are dead and transaction patterns are the new kid on the block."

It seems you are misapprehending what a design pattern is.  The "Unit Of Work" design pattern is a transaction.  It does not apply specific to databases.  It is not 'primitive'; on the contrary, it is a higher order concept.  You can have a transaction concept that has nothing to do with databases and still implement it to the Unit of Work concept.  A design pattern is only "primitive" in the sense that by itself it can't do anything.  This is because it is an abstract design, not a concrete implementation.

A Unit of Work, as a design pattern, simply implies that you can cache a set of changes to some set of resources to a single unit that will either get applied in its entirety, or rolled back in its entirety.

I'm not sure what you mean about 'transaction patterns', though.  It sounds to me like you are analyzing certain database operations and classifying them, then providing generic implementations for each type.  This is an implementation level realization, and not a design pattern level concept.  It might help me to have a clearer description of what different 'types' of transactions you are working with. 

In my experience, you can still wrap all transactions (db or otherwise) up in the concept of a unit of work.  Doesn't matter if one user interaction makes a change to table A, and a different user interaction makes a change to Table B, invokes a stored procedure, then updates three registry files.  You might choose to implement this as two distinct transaction classes, but they are both still adherent to the Unit of Work as a design pattern.

Remember, don't think of design patterns as magical, nor as implementation specific.  They're simply a way of documenting a solution design for a given problem, and hanging a label off of it.
Dan Fleet Send private email
Monday, March 12, 2007
 
 
Contrary to some previous posts, there *are* actually a great many standards used by software developers all the time.  For instance, XML, HTML, SQL, C, ASCII, TCP/IP, huge quantities of ISO, ANSI, IEEE standards, etc, etc... Every day, without even realizing it we make use of standards in our programming.  Fortunately in many cases, the development tools we use take care of the details of these for us.  The net result is that there *are* standard ways for software to interact with users, the operating system and other programs.

This is similar to the building architect.  They also have many standards in their field.  Also, they too have software tools that shield them from the implementation specifics of the standards.  The software (e.g. AutoCAD) will allow them to add a standard door without them actually needing to know the exact measurement.

Now the argument was previously made that the lack of design patterns and 'standards' are the reason there is so much crappy, poorly designed, software out there.  This argument does not hold water.  Have a look around outside in the city in which you live...

Sad to say, despite all the architectural standards, there are a lot of ugly, disfunctional buildings out there as well.  Sure they meet the building code perfectly...they just don't have that certain something that makes it a great building. 

You see, just simply applying standards does not guarantee a good  result.  A lot comes down to the experience and ability of the architect (not to mention the budget of the  client).

In reality, the good architects of the world, those who make great buildings understand a lot more than just a bunch of standards.  They know about people and their habits, their way of working, their psychology.  They know the history of architecture and the time context in which something was built.  They constantly critically examine features they like/dislike about the buildings they encounter.  They know the politics involved in the current building project.  And of course, they know through hard experience across a lot of different projects, that not everything that sounds great on paper (or in a textbook), will work well in practice.

In precisely the same way, good software architecture/design is much more than just the application of a bunch of standards.  That's why if Tinkabel the Fairy waved her magic wand and miraculously all programmers across the earth sudddenly knew all the GoF Design Patterns in all their resplendent glory and implemented them religiously to letter of the law...

...doh, there would still be a lot of crappy software out there.
ChrisB
Monday, March 12, 2007
 
 
>Sad to say, despite all the architectural standards, there are a lot of ugly, disfunctional buildings out there as well.  Sure they meet the building code perfectly...they just don't have that certain something that makes it a great building.

Ugliness is very subjective...

Not many buildings fall over...not that many leak...not many, even after a hundred years subside...not many flood...not many catch fire...

Most buildings are fit for purpose...not much software is.

So, don't write off standards just yet :)
Jack Hughes Send private email
Monday, March 12, 2007
 
 
>Most buildings are fit for purpose...not much software is.

Unfortunately, fitness for purpose has very little to do with standards.  This has much more to do with understanding your customer's requirements.  No amount of design patterns will make your software 'fit for purpose' if you don't understand what your customer really wants/needs.


> Not many buildings fall over...not that many leak...not many, even after a hundred years subside...not many flood...not many catch fire...

Actually, a surprising high number do!  The courts are full of cases where people suing the builder for defects in their building. 

But, the real reason we have so much poor quality software, is that buyers have shown themselves far more willing to pay for and tolerate badly designed software, compared to what they will accept when paying for a building.


> don't write off standards just yet

There is certainly no suggestion of 'writing off' standards.  As I pointed out previously, we use standards everyday as programmers.  These standards allow our programs to be compiled into a runnable form, they allow our programs to be stored, transmitted and to communicate with users, the operating system and other programs and devices.  Getting rid of standards would be a disaster!

However, as I have shown, the argument that the large amount of poor quality software products on the market being due to a lack of wide-spread use of design patterns is simply wrong.
ChrisB
Monday, March 12, 2007
 
 
<tony>
My framework is for administrative web applications, and these applications ALWAYS use a database.
</tony>

what framework are you using in you web applications?
jhanx Send private email
Monday, March 12, 2007
 
 
< So you are saying that design patterns are dead, right? And that the transaction **PATTERN** is the new kid on the block? >

Correct. I have been bulding applications containing many user transactions for several decades, and in all that time I have recognised recurring themes in these transactions. In case you don't know, a "recurring theme" is also known as a "pattern" or a "template". A transaction pattern can therefore be applied to a whole transaction whereas a design pattern can only be applied to a small part of a transaction. When I want to build a complete transaction I prefer to use a pattern that allows me to do it in a single step, not a series of small steps.

You sound like one of these clueless newbies who won't accept anything as a pattern unless it's described in the GoF book.
Tony Marston Send private email
Tuesday, March 13, 2007
 
 
< It seems you are misapprehending what a design pattern is.  The "Unit Of Work" design pattern is a transaction. >

When I use the word transaction I am talking about a "business transaction" and not a "database transaction". The two are entirely different, although the first may contain the second. The "unit of work" design pattern does not describe a complete business transaction, therefore it is of no use to me.

< I'm not sure what you mean about 'transaction patterns', though.  It sounds to me like you are analyzing certain database operations and classifying them, then providing generic implementations for each type.  This is an implementation level realization, and not a design pattern level concept. >

Transaction patterns describe complete business transactions, whereas design patterns describe only small parts of business transactions. A transaction pattern may be comprised of any number of smaller design patterns.

When describing a business transaction to a user it is far easier to base that description upon a transaction pattern. Nobody but a complete geek would talk to users in the language of design patterns.

In theory once a pattern/template has been described it should be possible to say "apply this pattern to that resource" and produce a piece of working code, with different implementations in different languages. This cannot be done with design patterns, but it can with transaction patterns because I have done it, twice, in two different languages.

The first is documented at http://www.marston-home.demon.co.uk/Tony/uniface/templates/index.html

The second is docuented at http://www.tonymarston.net/php-mysql/dialog-types.html
Tony Marston Send private email
Tuesday, March 13, 2007
 
 
< what framework are you using in you web applications? >

One that I designed and built myself. You can find it at http://www.radicore.org/
Tony Marston Send private email
Tuesday, March 13, 2007
 
 
<One that I designed and built myself. You can find it at http://www.radicore.org/>

Can you give us your definition of "design pattern" ?
MVC is a design pattern right? And the site you gave
specifically mentions that it uses MVC design pattern.
So why do you say "design patterns" are too primitive?
Is it like saying the framework you created
uses a primitive technique?
I believe the transaction pattern which you authored
is still a design pattern. Maybe this argument is just
a matter of definition...
jhanx Send private email
Tuesday, March 13, 2007
 
 
>This type of thing cannot be done with design patterns as they are too primitive, which is why I hold the view that design patterns are dead and transaction patterns are the new kid on the block.

[quote by Tony Marston]

Tony, you were the one saying that you thought patterns were dead because they are too primitive.

I was merely pointing out that, as the thing you think should replace them is a pattern itself that you are perhaps being a little bit premature to suggest that patterns are dead.

I have in no way suggested that the transaction pattern is not a pattern.

You are very kind to suggest I am a clueless newbie...I'm sure my Mother will be thrilled to have another accolade for her living room wall. :)
Jack Hughes Send private email
Tuesday, March 13, 2007
 
 
off a poster in my work area (from the book "Head First Design Patterns"):

Then Zen of Patterns

Beginner Mind:
The beginner uses pattern everywhere.  This is good:  the beginner gets lots of experience with, and practce using patterns.  The beginner also thinks "the more patterns I use, the better the design".  The beginner will learn this is not so, that all designs should be as simple as possible.  Complexity and patterns should only be used where they are needed for practical extensibility.

Intermediate Mind:
As learning progresses, the intermediate mind starts to see where patterns are needed and where they aren't.  The intermediate mind still tries to fit too many square patterns into round holes, but also begins to see that patterns can be adapted to fit situations where the canonical pattern doesn't.

Zen Mind:
The Zen mind is able to see patterns where they fit naturally.  The Zen mind is not obsessed with using patterns; rather, it looks for simple solutions that best solve the problem.  The Zen mind thinks in terms of the object principles and their trade-offs.  When a need for a pattern naturally arises, the Zen mind applies it, knowing well that it may require adaptation.  The Zen mind also sees relationships to similar patterns and understands the subtleties of differences in the intent of related patterns.  The Zen mind is also a beginner mind - it doesn't let all that pattern knowledge overly influence design decisions.
Another Anonymous Coward
Tuesday, March 13, 2007
 
 
+1 Anonymous Coward, your post about the Beginner, Intermediate and Zen mind put into words what was in my mind to say.

I see patterns as tools in my toolbox, just an extension of the basic constructs we learned in our Intro to C courses back in school: loops, structs, arrays, are patterns not just more advanced constructs to help us with the task of building software? Use the right tool for the job. No matter how cool a tool is reputed to be, you shouldn't try to hammer in nails with your 24V cordless drill.

Singleton for this, abstract factory for that, and on up to larger modelling patterns, these are all just tools, each one with it's use.

I work with some young programmers who are zealots when it comes to their patterns, and that is fine. I am certain they look at my hodge-podge of methodologies as archaic, which, I recall, is exactly what I thought of the seniors I was around when I was a newblet!

I find that they wind up huddling over the computer for the better part of an hour arguing about at what level they need to implement something... sometimes out of fear of telling me they need to spend more time refactoring working code (which I do not mind if it is required), but often because of a slavish adherence to a pattern as outlined in an essay. I don't make myself a slave to the pattern, I pick and choose the patterns that will give me the framework I need to accomplish the task of writing the software I need to get written. If I need to deviate, then I will. I find they code themselves into some corners, or wind up with an interface that is nicely architected all the way through to the database - but it isn't what the customer wants! And when you make them give the customer what he wants, they hate it! Sacrilege! The horror! My design! A wart on it! The customer is an idiot, this is against XXX principle! (A bit exaggerated, but that is the essence of it.)

I do admire beautifully architected software that implements "pure" patterns, and where practical, I draw from these concepts to improve my own design skills. I read the articles and essays and examine the designs, but I am wary of the fellow who talks to me of a particularly popular pattern he follows like a zealot talking of his religion... It makes me wonder what is more important to the programmer, adherence to a pattern, or software that works well and is delivered in good time?
I still code in Delphi
Tuesday, March 13, 2007
 
 
< Can you give us your definition of "design pattern" ? >

It's one of those thingies you can read about in the GoF (Gang of Four) book, or the PoEAA book by Martin Fowler (http://www.martinfowler.com/books.html#eaa)

< MVC is a design pattern right? And the site you gave
specifically mentions that it uses MVC design pattern. >

If you read a little more deeply you will see that I did not have the MVC pattern in mind when I built my framework, it just happened by accident. The only pattern that I used as a starting point was the 3 Tier Architecture. I do not read about patterns and then try to implement them, I just write code that works. There may be design patterns buried in there somewhere, but I don't bother looking for them.

< So why do you say "design patterns" are too primitive?
Is it like saying the framework you created uses a primitive technique? >

You are not reading deep enough. I may have used design patterns when bulding my framework, but I now use my framework to build applications which contain lots of user transactions. I build these transactions from transaction patterns, not design patterns. Each of my transaction patterns may be comprised of any number of low-level design patterns (such as model, view, controller and DAO), but I never describe a transaction in terms of the design patterns that it may use, only the single transaction pattern on which it is based.

< I believe the transaction pattern which you authored
is still a design pattern. Maybe this argument is just
a matter of definition... >

You will not find any of my transaction patterns documented in any book on design patterns, therefore they cannot be considered as design patterns.

The biggest difference is that in my framework I can generate a complete working transaction from a single transaction pattern just by pressing a button. Can you do that with a low-level design pattern? I think not.
Tony Marston Send private email
Tuesday, March 13, 2007
 
 
< Tony, you were the one saying that you thought patterns were dead because they are too primitive.

I was merely pointing out that, as the thing you think should replace them is a pattern itself that you are perhaps being a little bit premature to suggest that patterns are dead. >

Design patterns are dead to me. When I build transactions for my end-user applications I use high-level transaction patterns, not low-level design patterns. I have a library of transaction patterns built into my framework from which I can generate working transactions at the touch of a button. I cannot do the same with design patterns as they are too low-level.

I *may* have used low-level design patterns in creating my framework, but I now use that framework to build user transactions from high-level transaction patterns.
Tony Marston Send private email
Tuesday, March 13, 2007
 
 
Tony, you wrote:

<You sound like one of these clueless newbies who won't accept anything as a pattern unless it's described in the GoF book.>

And then:

<It's one of those thingies you can read about in the GoF (Gang of Four) book, or the PoEAA book by Martin Fowler>

Sounds conflicting to me.

If many of us will use your "transaction pattern" because it is great, and then it becomes so popular, then maybe there would be some chances that it will be included in one of those books(future releases).
Would you disagree if I say your "transaction pattern" is just a whole new design pattern you invented, or maybe an improvement to other existing/documented design patterns, just like you created a new framework(radicore) for some other reasons. Now, you wont say that radicore is not a framework because other frameworks may not be capable of what radicore can offer (sounds like since existing design patterns do not suit your need, you made a new design, and then that new design cannot be categorized as a design pattern--since it is not listed in any book?)?  If I pick 10 similar projects, check their implementations, and find out common implementations how they solved similar problems, I'd call that a design pattern, listed or not in any book, no matter if it is low-level or high-level(though I don't exactly know what you meant when you mentioned about the low and high-level).

You have also mentioned:

<I do not consciously use design patterns at all. You may see evidence of some paterns in my framework, but that is by accident and not a deliberate design decision.>

Is the process of choosing the design pattern to solve my software problem completely different from choosing the framework I will use to build my web application?

As to the OP, having knowledge of these documented design patterns is an advantage. Would you rather spend several days(weeks?) designing your desktop GUI application(w/o database, how does "transaction pattern" apply here?), and then come up with an MVC-like design pattern, or exactly the same, than already having knowledge of the MVC design pattern, which would spare you from wasting those precious time? It's just a matter of choosing the right tool, as others have pointed out.  If there is no such pattern that suits your need, maybe you can create your own.  If there is an existing/documented design pattern but you think is not sufficient enough, maybe you can improve it, or just make your own design (which may or may not become a design pattern)
jhanx Send private email
Tuesday, March 13, 2007
 
 
< Tony, you wrote:

<<You sound like one of these clueless newbies who won't accept anything as a pattern unless it's described in the GoF book.>>

And then:

<<It's one of those thingies you can read about in the GoF (Gang of Four) book, or the PoEAA book by Martin Fowler>>

Sounds conflicting to me.>

Where is the conflict? Many people do not consider my patterns to be "design patterns" because they do not appear in any books on design patterns. They do not have names that they can look up in the index. Because they have not been officially recognised they do not officially exist. That is why I call them transaction patterns and not design patterns.

< Would you disagree if I say your "transaction pattern" is just a whole new design pattern you invented, or maybe an improvement to other existing/documented design patterns, >

I would most definitely disagree. Design patterns describe low-level components within a transaction, whereas a transation pattern desctribes the whole transaction. Using the automotive industry as an as an analagy, a design pattern may describe a carburettor or a gearbox, but a transaction pattern describes a two-seater sports car or a four-seater saloon. One is a low-level component, the other is a complete thing.

I have built an entire framework around transaction patterns, and I can generate working transactions very quickly simply by linking a pattern with a resource. I have NEVER seen the same thing done with design patterns (have you?). It is because of this difference that I claim that transaction patterns are compleely different from design patterns. One is not merely an extension of the other. I can do things with transaction patterns that I cannot do with design patterns, therefore they are different.

< Is the process of choosing the design pattern to solve my software problem completely different from choosing the framework I will use to build my web application? >

Yes. Design patterns are completely different from frameworks. One is a low-level component that on its own is completely useless, the other is a collection of low-level components which actually achieve something.

< As to the OP, having knowledge of these documented design patterns is an advantage. >

Not necessarily. It is how you apply those patterns that counts. Applying the wrong pattern, or implementing the right pattern badly is worse that not using a pattern in the first place. I have first hand experience of a large government project which failed because the system architects went completely overboard with their usage of design patterns. They thought that using as many patterns as possible would be really "cool", but the end result was unacceptable to the paying customer.

Experienced programmers like myself carry working "patterns" around in our heads. We don't need to refer to officially recognised patterns in order to get the job done. And it is "getting the job done" which is more important than implementing a bunch of fashionable design patterns.
Tony Marston Send private email
Wednesday, March 14, 2007
 
 
<Where is the conflict?>

In the first statement, you seem to suggest that some design can be called a design pattern eventhough it is not listed in any design pattern book. In the second statement, it clearly states "It's one of those thingies you can read about in the GoF". In other words, a particular design, no matter how many times it was used to solve recurring software problems, cannot be called a design pattern because it is not listed in any design pattern book. I am just trying to understand your definition.

Regarding your analogy, is it wrong to say that a one-seater F1 racing car is a design pattern? Who would have designed a two or four-seater car for that matter? Is it also wrong to say that a two-seater sports car is a common design for sports cars, hence it becomes a design pattern when making sports cars?

<Experienced programmers like myself carry working "patterns" around in our heads. We don't need to refer to officially recognised patterns in order to get the job done. And it is "getting the job done" which is more important than implementing a bunch of fashionable design patterns.>

On the other hand, I seem to agree with this, if you already are an experienced programmer--because probably you have learned your lessons the hard way. But hey, isn't it better if you can also learn from others success/failure? And how about if someone is not as experienced as you are? Let's say you have two developers who have just learned GUI programming.
Eliminating other variables, let's say two developers who are equally capable: developer A knows the MVC design pattern (and some other patterns which he/she can use to solve the problem), and developer B does not.  If both have to make the same GUI application, which one do you think would have an advantage? Which one would probably finish first and with elegant code? Don't tell me you will place your bet on developer B.
Of course one should avoid that thinking process that relates design patterns to "fashion".
jhanx Send private email
Wednesday, March 14, 2007
 
 
<<Where is the conflict?>

In the first statement, you seem to suggest that some design can be called a design pattern even though it is not listed in any design pattern book. In the second statement, it clearly states "It's one of those thingies you can read about in the GoF". >

You are not reading my comments properly. I said that the patterns which *I* created are dismissed as not being design patterns because they do not appear in any books on design patterns. That is why I call them transaction patterns.

My response "It's one of those thingies you can read about in the GoF" was to your question "What is a design pattern?"

< Regarding your analogy, is it wrong to say that a one-seater F1 racing car is a design pattern? >

Some people may, others would not. Again you are missing the point I am trying to make. A "design" pattern is a low-level thingy which can be used as a component within a user transaction, but which on its own cannot be used to describe a complete user transaction. A "transaction" pattern, on the other hand, is used to describe a user transaction in its entirety. A high-level transaction pattern may be comprised of any number of low-level design patterns.

If you don't believe me, then try writing a transaction generator which allows you to link a pattern with a resource in order to create a fully functioning transaction. You will find that it cannot be done with design patterns, but it *can* be done with transaction patterns. That is the difference.

< And how about if someone is not as experienced as you are? >

An inexperienced programmer will not succeed if all he does is read about design patterns and try to implement them. The problem with design patterns is that they are just that - designs. They can be implemented in many different ways in different languages, and sometimes many ways within the same language. Knowing the name of a pattern is irrelevant unless you get the implementation right, and that is not possible without tuition from a more experienced programmer who can provide differen code samples that wrk in different circumstances.

< Of course one should avoid that thinking process that relates design patterns to "fashion". >

I agree. But the problem with a lot of today's programmers is that they feel that they must litter their conversations with the names of as many patterns as possible in order to appear "cool" and "with it". By concentrating on the patterns they are instead of the result which they are tying to achieve they invariably produce something which sucks. I know, because I have witnessed it.
Tony Marston Send private email
Thursday, March 15, 2007
 
 
We probably shouldn't bother learning about fancy things like object-orientated design either. Just another fashion that's not needed; as long as you're experienced.

;-)

Personally I find reading about things like design patterns to be really useful. They often show me ways of solving problems which I never would have come up with in the limited time I have.

At the end of the day I take a professional interest in almost all design information (be it published design patterns or just looking at someone else's source code).

I'm experienced enough now to release that there's always 100 ways to solve a problem, there's almost nothing 'new' in software... Balancing all the variables to choose the best approach is what we do for a living. We can only make these judgment calls using our experience - which is why extending it through continuous learning is important.

I'd never rubbish someone else's concepts, be they design patterns or transaction patterns. I don't care if they're fashionable or not. If they helped someone solve a problem then I can learn from that experience and improve my own depth of knowledge. Calling design patterns useless is painfully naive, you might not use them but I certainly have to great effect in many projects.
Coopsnakes Send private email
Monday, March 19, 2007
 
 
True potential of Patterns can be realized if they are available as ready to use packages, like there is signal-slot (publisher-subscriber) in Boost.
Sopan Send private email
Thursday, March 22, 2007
 
 
Foe.
Tim Patterson Send private email
Thursday, March 22, 2007
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz