Pattern V/s Anti-Pattern

[Rishi Singh]

Hi All,
When we apply a particular pattern to a solution and try to model it accordingly, we say we implement so and so pattern.Now after doing so we realized the code needs some changes and start refactoring it and come out with a solution which works fine performance wise but it has deviated from the original pattern...do we term this as an antipattern.
Now what I wd like to ask whether we start coding based on some pattern OR just start coding and then try to get closer to a pattern.
Ideally what should be the approach.Is Anti-pattern more sucessful in real life project implementation

[Bear Bibeault]

Rishi, as I understand it, the term antipattern has come to mean, not legitimate patterns that deviate from established patterns, but rather practices and common errors that have been proved to be less than advantageous.
Does this jive with how others understand the term?
bear

[Rishi Singh]

Hi Bear,
"practices and common errors that have been proved to be less than advantageous."
Does that mean using a stringBuffer in place of strins for string manipualtion, using an ArrayList in place of vector is following anti-patterns...seems confusing.

[Junilu Lacar]

Rishi,
Refer to some of the other recent threads about anti-patterns. You'll find links to websites that provide good discussions of the basics. You could also Google for "anti-patterns".
Patterns and anti-patterns are more on a higher level of abstraction than what you're thinking of with StringBuffer and such. They pertain to the way the different pieces of your design are related to each other and their combined effect on characteristics of your application like maintainability, extensibility, flexibility, robustness and performance. As with patterns, anti-patterns are "common solutions" only patterns have a positive effect whereas anti-patterns have negative effects. As such, I see anti-patterns as really being "common screw-ups".
Does this help clear things up a little?
Junilu

[Junilu Lacar]

Originally posted by Rishi Singh:
a solution which works fine performance wise but it has deviated from the original pattern...do we term this as an antipattern.
If it has negative effects, yes.

Now what I wd like to ask whether we start coding based on some pattern OR just start coding and then try to get closer to a pattern.

The beauty and power of patterns is that there can be many different solutions that still conform to the pattern. I am beginning to think that there is a great deal of interplay/interdependence between knowledge of good design principles and knowledge of patterns. I think either approach is feasible. If you start coding, remember to follow good design principles but keep patterns in mind so that if you notice that your code seems to be following one, then you can start shaping your design towards it. If you start with patterns, then keep good design principles in mind so that you avoid applying the wrong pattern or misapplying a pattern.
HTH,
Junilu

[Reid M. Pinchback]

Originally posted by Rishi Singh:
Now what I wd like to ask whether we start coding based on some pattern OR just start coding and then try to get closer to a pattern.

I haven't read it yet, but there is a book out called "Bitter Java" that apparently talks about things like that and discusses the benefits of patterns versus anti-patterns.
I've tried both applying patterns at design time, and after-the-fact to fix existing code. I don't think it is really a one-or-the-other situation.
Obviously if you wait a long time, using a pattern to fix an implementation problem could be expensive and risky. On the other hand, sometimes picking a pattern is tough before you understand the problem. The question is: when do you understand the problem? Many problems you can uncover beforehand via good requirements. Some you only encounter when working on the implementation. Some don't happen right away; they are the result of ongoing evolution of the application.
One thing I've found: make sure you really understand the pattern! Junilu is correct that there are many ways to conform to a pattern, but I've also seem people write code claiming it fits a pattern when it really doesn't.
MVC is a classic example; just because you have data and you show stuff on a GUI doesn't mean that you are using MVC (or even if you are, it could be a very badly implemented MVC).
[ June 05, 2002: Message edited by: Reid M. Pinchback ]

[Junilu Lacar]

I haven't read it yet, but there is a book out called "Bitter Java"
And it just so happens we're giving away four copies of it this week

[Corey McGlone]

Originally posted by Reid M. Pinchback:

MVC is a classic example; just because you have data and you show stuff on a GUI doesn't mean that you are using MVC (or even if you are, it could be a very badly implemented MVC).

MVC is a great architecture/design, when used appropriately. We had a discussion in this thread about a faulty implementation of this approach which Bruce refers to as a Magic Servlet approach. Granted, you might be able to implement your project using one giant servlet, but it will probably have a negative impact on your project. If this is the case, it is considered an antipattern.
Just because something deviates slightly from a pattern doesn't make it an antipattern (at least not in my mind), but if it causes some sort of negative impact on your system, then it becomes an antipattern.
The difference between an antipattern and your String/StringBuffer example is that patterns/antipatterns are (generally) design issues. A faulty design that leads to a poor system could very well be due to the presence of an antipattern. The String/StringBuffer example, however, if a programming issue. That issue could appear in any system, even one that successfully utilizes patterns in the design.
I hope that helps,
Corey

[Bruce Tate]

A pattern is a literary form of a common solution with good consequences. An analogy might be a blue print of a good plan.
An antipattern is a literary form of a common solution or behavior with decidedly negative consequences. An analogy is a bad habbit.
Three things are important:
1) Literary form means that code is not an antipattern. We're looking for a form that's easy to express...a description. An example is a writeup describing the y2K problem.
2) Common. If it happens only once, it can't be a pattern or antipattern.
3) Consequences. If the measurable consequences are negative, it's an antipattern.
Bitter Java talks about these issues, and the relationship between the two. The role of design patterns is well understood. Antipatterns are particularly helpful when you refactor, when you mentor, and when you're learning to code. Think of it this way. You can gather experience by making your own mistakes, or you can learn from someone else's mistakes. Detecting and refactoring antipatterns is what Bitter Java is all about.

[Doug Wang]

Great! Learn from mistakes! But how can I identify AntiPatterns?

[Corey McGlone]

Originally posted by Doug Wang:
Great! Learn from mistakes! But how can I identify AntiPatterns?

Even if I found that a design I had implemented was having a negative effect on my system, I doubt I'd step back, look at it, and say, "Hey, that's an antipattern!"
Rather, antipatterns are much like design patterns - they are only recognized when you see many system designed the same way. When multiple systems use the same design to implement a solution, we recognize that as a pattern. Then, you can read about patterns (or discover them yourself, I suppose) and use them in the future.
Antipatterns, in the same way, are discovered when they're used in many systems. Studying antipatterns is somewhat like studying common "gotchas" for system development and design. You can give yourself an idea of what to avoid.
That's my take on it, anyway.
Corey

[Rishi Singh]

Hi All,
can we have some examples od anti-patterns in terms of overall architecture,best practices.Is there any anti-pattern which is used extensively.And what sort of negative impact does it has on the project, and if it does why do it is followed .Can someone throw some light with an example...mat be Bruce himself.
Rishi Singh
SCJP,SCWCD

[Rishi Singh]

Hi All,
Does anti-pattern pertains to only architecture or there a can be a anti-pattern say for the development process, the overall-management, the infrastructure..after all whenever a project fails it could be b,coz of any one of these and it can be termed as an anti-pattern and when we try to take this experience and rectify it in our next project, I guess it can be classified as an anti-pattern....which is a bad practice but a clear solution to which can result in a good paractice...so my inference is evry pattern has come from an anti-pattern .Am i rite in my belief..plz do enlighten

[Ilja Preuss]

Originally posted by Rishi Singh:
Hi All,
Does anti-pattern pertains to only architecture or there a can be a anti-pattern say for the development process, the overall-management, the infrastructure..after all whenever a project fails it could be b,coz of any one of these and it can be termed as an anti-pattern and when we try to take this experience and rectify it in our next project, I guess it can be classified as an anti-pattern....which is a bad practice but a clear solution to which can result in a good paractice...

Yes, you are absolutely right.
Take a look at http://c2.com/cgi/wiki?AntiPatternsCatalog for a list of some antipatterns about design, architecture, process etc.

[Junilu Lacar]

Again, as with patterns, I suppose you can find anti-patterns in most, if not all, areas of development including management and organization.
Just take a look at the table of contents in this week's book giveaway (http://www.manning.com/tate/index.html) to get an idea of some examples of server-side development antipatterns. You might also want to take a look at the book "AntiPatterns" by Brown, et.al. which lists such colorfully named achitectural antipatterns as "Design by Committee" and "Reinvent the Wheel" (aka the "Not Invented Here" syndrome) and project management antipatterns such as "Analysis Paralysis", "Death by Planning" and "Throw it over the Wall" (sound familiar?)

[Corey McGlone]

Originally posted by Rishi Singh:
Hi All,
Does anti-pattern pertains to only architecture or there a can be a anti-pattern say for the development process, the overall-management, the infrastructure..

One of the most notorious process killers is the classic "Scope Creep." That's where, as you're working through design, or even implementation, requirements continue to be added to the system so that the developers end up really trying to design according to a "moving target." In such a case, it's only a matter of time until the design goes down the tubes.
Corey

[Wouter Zelle]

Do anti-patterns pertain only to architecture or can there be an anti-pattern for the development process, the overall-management, the infrastructure..

Patterns and anti-patterns are part of life. Humans are constantly trying to relate the current event with their experience. When you detect a pattern that worked out well for you in the past, you will want to repeat it again when you have the chance. Bad patterns are things that work out wrong and you will want to avoid. You don't want to climb on a wobbly chair if you have seen someone fall once. When you do need to reach up to something, you either climb on something else or are very careful.
For anti-patterns in projects, I suggest you check out Dilbert. The best book to read about project management is Peopleware.
[ June 06, 2002: Message edited by: Wouter Zelle ]

[Ilja Preuss]

Originally posted by Corey McGlone:
One of the most notorious process killers is the classic "Scope Creep." That's where, as you're working through design, or even implementation, requirements continue to be added to the system so that the developers end up really trying to design according to a "moving target." In such a case, it's only a matter of time until the design goes down the tubes.

Mhh, that's not my take on Scope Creep. There *are* techniques to handle changes in design according to a "moving target" - that is one of the situations where Agile Processes shine.
What is worse is when scope "creepingly" (is this a word?) increases without anybody getting attentive. That is, the customer adds a few tiny little ideas every couple of days, but doesn't expect the release date to change.
That is why most Agile Processes are *very* finicking about making the impact of changes in scope on the schedule explicit.

[Rishi Singh]

Hi Wouter,
Tahnks a lot for your postings, Iam aware that I can't become the master of Design pattern in one night, it will come through experience, reading only.By the way the example which u gave I believed was a classical case of code optimization or one may put it good coding practice.
Anyway my attempt to learn would go on and I thought java ranch is the best place for that.Iam sorry if i made some people feel that iam asking something which already has been answered..
Well I got Scope Creep as Iam undergoing that as the client do come with some new requirement when things are set for implementation stage..but would like someone to throw light on Agile Process

[Rishi Singh]

Hi All,
One of the most notorious process killers is the classic "Scope Creep." That's where, as you're working through design, or even implementation, requirements continue to be added to the system so that the developers end up really trying to design according to a "moving target." In such a case, it's only a matter of time until the design goes down the tubes.
What is the best feasible solution to get out of Scope Creep.Agile Shine was mentioned but iam not very confident what it does.Does it put an end to the requirement list

[Wouter Zelle]

What is the best feasible solution to get out of Scope Creep.

There are various solutions. An agile/XP process works by telling your customers exactly how long features are going to take. In XP you use cards for tasks. Each card takes x weeks. The cards the customers chooses for you should fit between the start of the project and the deadline. You visually show this by laying out the cards between two lines. If a customer adds a card, the cards will no longer 'fit'. The only options are to change the deadline or remove (another) card.
In non-agile project you may want to copy this by using Gannt charts. Another good tactic is too have a version 2 to direct new features to. Another tactic I've heard about is to distract the user. They can be very focussed on looks, so give them harmless decisions to make about the colors you use on the web-site. Short iterations/deadlines also help.

[Ilja Preuss]

Originally posted by Rishi Singh:
Well I got Scope Creep as Iam undergoing that as the client do come with some new requirement when things are set for implementation stage..but would like someone to throw light on Agile Process

Then take also a look at the XP and controlling "scope creep"-thread.

[Pradeep bhatt]

If I detect a anti-pattern in my system, will there be solution for the anti-pattern? Or so I have find a solution for it?

[Robert Martin]

Originally posted by Rishi Singh:
Hi All,
When we apply a particular pattern to a solution and try to model it accordingly, we say we implement so and so pattern.Now after doing so we realized the code needs some changes and start refactoring it and come out with a solution which works fine performance wise but it has deviated from the original pattern...do we term this as an antipattern.
Now what I wd like to ask whether we start coding based on some pattern OR just start coding and then try to get closer to a pattern.
Ideally what should be the approach.Is Anti-pattern more sucessful in real life project implementation

An antipattern is something you don't want to do. It's a bad habit, or a bad practice. Rather than solving a problem, an anti-pattern exacerbates it.
I'd advise against coding or designing based upon patterns. IMHO the concept of generative pattern languages has not been achieved. If you start with the patterns in mind, you are likely to miss simpler and better solutions. You are also likely to overuse the patterns.
My recommendation is to study the patterns and learn them well. Then, as you are evolving your design you will find problems that drive you in the direction of a certain pattern. If the code and design gets close enough, then change the names and structure to match the canonical pattern. This will help you, and others, understand what's going on.
For example, if you see a class named "MP3PlayerDecorator" you can expect to see the Decorator pattern in use. Since you know the pattern well, you will know what to expect from the code.
In this sense, Design Patterns are more about documentation than about design. They help you to describe your designs to others.

[Ilja Preuss]

Originally posted by Pradeep Bhat:
If I detect a anti-pattern in my system, will there be solution for the anti-pattern? Or so I have find a solution for it?

To be complete, an anti pattern has to be accompanied by a "refactored solution".

[Jeroen Wenting]

Of course something that is a valid pattern in one context can be an anti-pattern in another context.
I think most of us have seen code where patterns were applied not because they made sense but because someone decided they had to use patterns and those were the ones the designer/architect was most familiar with so they were the ones used in all situations whether appropriate or not.
Worst example of that I've seen was a C++ app that used multiple layers of multi-tier programming (frontend, backend and middle tier were each subdivided into 3 tiers themselves) with factories for each and every object (including if I remember correctly some factories that did nothing but return instances of other factories which were themselves implemented as singletons).
While each of the patterns used was in itself viable the combination was a monster.