Expertiza_Wiki - User contributions [en]

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-23T20:32:46Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding, though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.
<pre>class Account {
private double balance;
public double getBalance() {
return balance;
}
public void setBalance(double balance) {
this.balance = balance;
}
class AccountService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
public void credit(Account account, double amount) {
account.setBalance(account.getBalance() + amount);
}
}</pre>
As shown above the object Account acts just as a place holder for “balance”. In this model most probably some kind of service object (AccountService) sets and gets the value of the balance to reflect any changes to the balance. This is very luring because its pretty straight forward. What makes this Anemic is there is no behavior associated with this Account object itself.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.allexperts.com/e/b/ba/basebean.htm BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://www.martinfowler.com/bliki/CallSuper.html Call Super]</h3></li>
<b>Problem:</b>
Call super requires users of a particular interface to override the method of a superclass and call the overridden from the overriding method. This usage brings in two major problems.
<ul>
<li>'super' method has to be called or the program cannot be implemented. That is a very serious problem and of course, IDE's can help by providing templates for these methods, but there's no standard way of doing this and no enforcement from the underlying VM.</li>
<li>The other problem arises when a call to the 'super' method fails or an exception is thrown thereby breaking the call to the subsequent methods in the chain of command.</li></ul>

<b>Example:</b>

public class EventHandler ...
public void handle (BankingEvent e) {
housekeeping(e);
}
public class TransferEventHandler extends EventHandler...
public void handle(BankingEvent e) {
super.handle(e);
initiateTransfer(e);
}
<b>Solution:</b>
A better approach to solve these issues is instead to use the [http://en.wikipedia.org/wiki/Template_method_pattern template method pattern], where the superclass includes a purely abstract method that must be implemented by the subclasses and have the original method call that method.<br><br>
[[Image:CallSuper-fixed.png|How to avoid the CallSuper anti-pattern]]
<br><br>Here the common code would go into the abstract method of the abstract class and it would act like a container for all the other methods that need to be used by the subclasses.

<li><h3>[http://perldesignpatterns.com/?GodObject God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as [http://en.wikipedia.org/wiki/Inversion_of_control Inversion of Control] and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.
<pre>
public interface InterfaceAnalyzer {
public void setOptions(AnalyzerOptions options);
public void setText(String text);
public void initialize();
public int getOccurrences(String query);
}

InterfaceAnalyzer analyzer = AnalyzerFactory.getAnalyzer();
analyzer.setOptions(true);
analyzer.initialize();
Map<String, Integer> results = new HashMap<String, Integer>();
for(String item : items) {
analyzer.setText(item);
results.put(item, analyzer.getOccurrences);
}</pre>
This implementation is considered to be ineffective because as indicated above, it is storing state in a way that is not explicitly shown by the interface.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.

</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model - By Martin Fowler]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-23T20:19:14Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding, though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.
<pre>class Account {
private double balance;
public double getBalance() {
return balance;
}
public void setBalance(double balance) {
this.balance = balance;
}
class AccountService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
public void credit(Account account, double amount) {
account.setBalance(account.getBalance() + amount);
}
}</pre>
As shown above the object Account acts just as a place holder for “balance”. In this model most probably some kind of service object (AccountService) sets and gets the value of the balance to reflect any changes to the balance. This is very luring because its pretty straight forward. What makes this Anemic is there is no behavior associated with this Account object itself.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.allexperts.com/e/b/ba/basebean.htm BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://www.martinfowler.com/bliki/CallSuper.html Call Super]</h3></li>
<b>Problem:</b>
Call super requires users of a particular interface to override the method of a superclass and call the overridden from the overriding method. This usage brings in two major problems.
<ul>
<li>'super' method has to be called or the program cannot be implemented. That is a very serious problem and of course, IDE's can help by providing templates for these methods, but there's no standard way of doing this and no enforcement from the underlying VM.</li>
<li>The other problem arises when a call to the 'super' method fails or an exception is thrown thereby breaking the call to the subsequent methods in the chain of command.</li></ul>

<b>Example:</b>

public class EventHandler ...
public void handle (BankingEvent e) {
housekeeping(e);
}
public class TransferEventHandler extends EventHandler...
public void handle(BankingEvent e) {
super.handle(e);
initiateTransfer(e);
}
<b>Solution:</b>
A better approach to solve these issues is instead to use the [http://en.wikipedia.org/wiki/Template_method_pattern template method pattern], where the superclass includes a purely abstract method that must be implemented by the subclasses and have the original method call that method.<br><br>
[[Image:CallSuper-fixed.png|How to avoid the CallSuper anti-pattern]]
<br><br>Here the common code would go into the abstract method of the abstract class and it would act like a container for all the other methods that need to be used by the subclasses.

<li><h3>[http://perldesignpatterns.com/?GodObject God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as [http://en.wikipedia.org/wiki/Inversion_of_control Inversion of Control] and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.

</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model - By Martin Fowler]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-23T20:17:43Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding, though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.
class Account {
private double balance;
public double getBalance() {
return balance;
}
public void setBalance(double balance) {
this.balance = balance;
}
class AccountService {
public void debit(Account account, double amount) {
account.setBalance(account.getBalance() - amount);
}
public void credit(Account account, double amount) {
account.setBalance(account.getBalance() + amount);
}
}
As shown above the object Account acts just as a place holder for “balance”. In this model most probably some kind of service object (AccountService) sets and gets the value of the balance to reflect any changes to the balance. This is very luring because its pretty straight forward. What makes this Anemic is there is no behavior associated with this Account object itself.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.allexperts.com/e/b/ba/basebean.htm BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://www.martinfowler.com/bliki/CallSuper.html Call Super]</h3></li>
<b>Problem:</b>
Call super requires users of a particular interface to override the method of a superclass and call the overridden from the overriding method. This usage brings in two major problems.
<ul>
<li>'super' method has to be called or the program cannot be implemented. That is a very serious problem and of course, IDE's can help by providing templates for these methods, but there's no standard way of doing this and no enforcement from the underlying VM.</li>
<li>The other problem arises when a call to the 'super' method fails or an exception is thrown thereby breaking the call to the subsequent methods in the chain of command.</li></ul>

<b>Example:</b>

public class EventHandler ...
public void handle (BankingEvent e) {
housekeeping(e);
}
public class TransferEventHandler extends EventHandler...
public void handle(BankingEvent e) {
super.handle(e);
initiateTransfer(e);
}
<b>Solution:</b>
A better approach to solve these issues is instead to use the [http://en.wikipedia.org/wiki/Template_method_pattern template method pattern], where the superclass includes a purely abstract method that must be implemented by the subclasses and have the original method call that method.<br><br>
[[Image:CallSuper-fixed.png|How to avoid the CallSuper anti-pattern]]
<br><br>Here the common code would go into the abstract method of the abstract class and it would act like a container for all the other methods that need to be used by the subclasses.

<li><h3>[http://perldesignpatterns.com/?GodObject God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as [http://en.wikipedia.org/wiki/Inversion_of_control Inversion of Control] and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.

</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model - By Martin Fowler]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-22T04:41:58Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding, though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.allexperts.com/e/b/ba/basebean.htm BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://www.martinfowler.com/bliki/CallSuper.html Call Super]</h3></li>
<b>Problem:</b>
Call super requires users of a particular interface to override the method of a superclass and call the overridden from the overriding method. This usage brings in two major problems.
<ul>
<li>'super' method has to be called or the program cannot be implemented. That is a very serious problem and of course, IDE's can help by providing templates for these methods, but there's no standard way of doing this and no enforcement from the underlying VM.</li>
<li>The other problem arises when a call to the 'super' method fails or an exception is thrown thereby breaking the call to the subsequent methods in the chain of command.</li></ul>

<b>Example:</b>

public class EventHandler ...
public void handle (BankingEvent e) {
housekeeping(e);
}
public class TransferEventHandler extends EventHandler...
public void handle(BankingEvent e) {
super.handle(e);
initiateTransfer(e);
}
<b>Solution:</b>
A better approach to solve these issues is instead to use the [http://en.wikipedia.org/wiki/Template_method_pattern template method pattern], where the superclass includes a purely abstract method that must be implemented by the subclasses and have the original method call that method.<br><br>
[[Image:CallSuper-fixed.png|How to avoid the CallSuper anti-pattern]]
<br><br>Here the common code would go into the abstract method of the abstract class and it would act like a container for all the other methods that need to be used by the subclasses.

<li><h3>[http://perldesignpatterns.com/?GodObject God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.

</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model - By Martin Fowler]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-22T04:40:40Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding, though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.allexperts.com/e/b/ba/basebean.htm BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://perldesignpatterns.com/?GodObject God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.

<li><h3>[http://www.martinfowler.com/bliki/CallSuper.html Call Super]</h3></li>
<b>Problem:</b>
Call super requires users of a particular interface to override the method of a superclass and call the overridden from the overriding method. This usage brings in two major problems.
<ul>
<li>'super' method has to be called or the program cannot be implemented. That is a very serious problem and of course, IDE's can help by providing templates for these methods, but there's no standard way of doing this and no enforcement from the underlying VM.</li>
<li>The other problem arises when a call to the 'super' method fails or an exception is thrown thereby breaking the call to the subsequent methods in the chain of command.</li></ul>

<b>Example:</b>

public class EventHandler ...
public void handle (BankingEvent e) {
housekeeping(e);
}
public class TransferEventHandler extends EventHandler...
public void handle(BankingEvent e) {
super.handle(e);
initiateTransfer(e);
}
<b>Solution:</b>
A better approach to solve these issues is instead to use the [http://en.wikipedia.org/wiki/Template_method_pattern template method pattern], where the superclass includes a purely abstract method that must be implemented by the subclasses and have the original method call that method.<br>
[[Image:CallSuper-fixed.png|How to avoid the CallSuper anti-pattern]]
<br>Here the common code would go into the abstract method of the abstract class and it would act like a container for all the other methods that need to be used by the subclasses.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model - By Martin Fowler]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

File:CallSuper-fixed.png

2009-11-22T04:35:19Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-22T04:31:35Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding, though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.allexperts.com/e/b/ba/basebean.htm BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://perldesignpatterns.com/?GodObject God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.

<li><h3>[http://www.martinfowler.com/bliki/CallSuper.html Call Super]</h3></li>
<b>Problem:</b>
Call super requires users of a particular interface to override the method of a superclass and call the overridden from the overriding method. This usage brings in two major problems.
<ul>
<li>'super' method has to be called or the program cannot be implemented. That is a very serious problem and of course, IDE's can help by providing templates for these methods, but there's no standard way of doing this and no enforcement from the underlying VM.</li>
<li>The other problem arises when a call to the 'super' method fails or an exception is thrown thereby breaking the call to the subsequent methods in the chain of command.</li></ul>

<b>Example:</b>

public class EventHandler ...
public void handle (BankingEvent e) {
housekeeping(e);
}
public class TransferEventHandler extends EventHandler...
public void handle(BankingEvent e) {
super.handle(e);
initiateTransfer(e);
}
<b>Solution:</b>
A better approach to solve these issues is instead to use the [http://en.wikipedia.org/wiki/Template_method_pattern template method pattern], where the superclass includes a purely abstract method that must be implemented by the subclasses and have the original method call that method.
[[Image:CallSuper-fixed.png|How to avoid the CallSuper anti-pattern]]
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model - By Martin Fowler]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-22T04:27:36Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding, though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.allexperts.com/e/b/ba/basebean.htm BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://perldesignpatterns.com/?GodObject God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.

<li><h3>[http://www.martinfowler.com/bliki/CallSuper.html Call Super]</h3></li>
<b>Problem:</b>
Call super requires users of a particular interface to override the method of a superclass and call the overridden from the overriding method. This usage brings in two major problems.
<ul>
<li>'super' method has to be called or the program cannot be implemented. That is a very serious problem and of course, IDE's can help by providing templates for these methods, but there's no standard way of doing this and no enforcement from the underlying VM.</li>
<li>The other problem arises when a call to the 'super' method fails or an exception is thrown thereby breaking the call to the subsequent methods in the chain of command.</li></ul>

<b>Example:</b>

public class EventHandler ...
public void handle (BankingEvent e) {
housekeeping(e);
}
public class TransferEventHandler extends EventHandler...
public void handle(BankingEvent e) {
super.handle(e);
initiateTransfer(e);
}
<b>Solution:</b>
A better approach to solve these issues is instead to use the template method pattern, where the superclass includes a purely abstract method that must be implemented by the subclasses and have the original method call that method.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model - By Martin Fowler]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-22T04:04:41Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding, though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.allexperts.com/e/b/ba/basebean.htm BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://perldesignpatterns.com/?GodObject God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://martinfowler.com/bliki/AnemicDomainModel.html Anemic Domain Model - By Martin Fowler]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-19T04:04:08Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding, though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.wikipedia.org/wiki/BaseBean BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://en.wikipedia.org/wiki/God_object God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-19T04:02:04Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion]</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>[http://www.laputan.org/mud/ Big Ball of Mud]</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html The Gas Factory or Unnecessary Complexity]</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following [http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It YAGNI] and [http://en.wikipedia.org/wiki/Lean_software_development Lean Software Development], you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition]</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.wikipedia.org/wiki/BaseBean BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://en.wikipedia.org/wiki/God_object God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-18T23:43:07Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>Abstraction Inversion</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>Ambiguous Viewpoint</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.

<li><h3>Big Ball of Mud</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>The Gas Factory or Unnecessary Complexity</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following YAGNI(You aren’t gonna need it) and Lean Software Development, you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it.

<li><h3>Functional Decomposition</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.wikipedia.org/wiki/BaseBean BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://en.wikipedia.org/wiki/God_object God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-18T23:29:27Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>Abstraction Inversion</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>Ambiguous Viewpoint</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.<br>

<li><h3>Big Ball of Mud</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>The Gas Factory or Unnecessary Complexity</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following YAGNI(You aren’t gonna need it) and Lean Software Development, you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it .

<li><h3>Functional Decomposition</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.wikipedia.org/wiki/BaseBean BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://en.wikipedia.org/wiki/God_object God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-18T23:26:06Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>Abstraction Inversion</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>Ambiguous Viewpoint</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.<br>

<li><h3>Big Ball of Mud</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>The Gas Factory or Unnecessary Complexity</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following YAGNI(You aren’t gonna need it) and Lean Software Development, you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it .

<li><h3>Functional Decomposition</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.wikipedia.org/wiki/BaseBean BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://en.wikipedia.org/wiki/God_object God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
[http://java.sun.com/j2se/1.4.2/docs/api/java/text/MessageFormat.html java.util.MessageFormat] which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-18T23:23:43Z

Artonoops:

== Antipattern ==

An [http://en.wikipedia.org/wiki/Anti-pattern AntiPattern] describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by [http://en.wikipedia.org/wiki/Andrew_Koenig Andrew Koenig], inspired by [http://www.blackwasp.co.uk/GofPatterns.aspx Gang of Four's] book [http://en.wikipedia.org/wiki/Design_pattern Design Patterns], which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. [http://en.wikipedia.org/wiki/Agile_software_development Agile methodologies] dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>Abstraction Inversion</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>Ambiguous Viewpoint</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.<br>

<li><h3>Big Ball of Mud</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>The Gas Factory or Unnecessary Complexity</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following YAGNI(You aren’t gonna need it) and Lean Software Development, you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it .

<li><h3>Functional Decomposition</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>[http://en.wikipedia.org/wiki/Anemic_Domain_Model Anemic Domain Model]</h3></li>
<b>Problem:</b>
This pattern proposed by [http://martinfowler.com/ Martin Fowler], arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>[http://en.wikipedia.org/wiki/BaseBean BaseBean]</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>[http://en.wikipedia.org/wiki/God_object God object]</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>[http://viswiki.com/en/Sequential_coupling Sequential Coupling]</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
java.util.MessageFormat which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>[http://en.wikipedia.org/wiki/Yo-yo_problem Yo Yo Problem]</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://www.antipatterns.com/briefing/index.htm Briefing on Anti patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>
</ul>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-18T23:07:37Z

Artonoops:

== Antipattern ==

An AntiPattern describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by Andrew Koenig,[3] inspired by Gang of Four's book Design Patterns, which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. Agile methodologies dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>Abstraction Inversion</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>Ambiguous Viewpoint</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.<br>

<li><h3>Big Ball of Mud</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>The Gas Factory or Unnecessary Complexity</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following YAGNI(You aren’t gonna need it) and Lean Software Development, you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it .

<li><h3>Functional Decomposition</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>Anemic Domain Model</h3></li>
<b>Problem:</b>
This pattern proposed by Martin Fowler, arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>BaseBean</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>God object</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>Singletonitis</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>Sequential Coupling</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
java.util.MessageFormat which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>Yo Yo Problem</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==
<ul>
<li>[http://c2.com/cgi/wiki?AntiPattern AntiPatterns]</li>

<li>[http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns Overview of Software design Patterns]</li>

<li>[http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns Patterns and Anti patterns]</li>

<li>[http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html Singletonitis]</li>

<li>[http://en.allexperts.com/e/a/an/anti-pattern.htm Compilation of Anti patterns]</li>

<li>[http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html Gas Factory in detail]</li>

<li>[http://c2.com/cgi/wiki$?AbstractionInversion Abstraction Inversion Anti pattern]</li>

<li>[http://sourcemaking.com/antipatterns/ambiguous-viewpoint Ambiguous Viewpoint]</li>

<li>[http://www.laputan.org/mud/ Big Ball of Mud in Detail]</li>

<li>[http://sourcemaking.com/antipatterns/functional-decomposition Functional Decomposition Anti Pattern]</li>

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-18T23:00:42Z

Artonoops:

== Antipattern ==

An AntiPattern describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by Andrew Koenig,[3] inspired by Gang of Four's book Design Patterns, which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. Agile methodologies dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Types of Software design anti-patterns ==
<ul>
<li><h3>Abstraction Inversion</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
Abstraction Inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:<ul>
<li>If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.</li>
<li>Do not force unnecessarily weak constructs on the users. </li></ul>
For implementers of higher-level software:
<ul><li>Choose the infrastructure carefully.</li></ul>

<li><h3>Ambiguous Viewpoint</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications. These models denote an implementation viewpoint that visualizes the structure of a computer program. Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:
Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.<br>

<li><h3>Big Ball of Mud</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>The Gas Factory or Unnecessary Complexity</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following YAGNI(You aren’t gonna need it) and Lean Software Development, you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it .

<li><h3>Functional Decomposition</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>Anemic Domain Model</h3></li>
<b>Problem:</b>
This pattern proposed by Martin Fowler, arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>BaseBean</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>God object</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>Singletonitis</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>Sequential Coupling</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
java.util.MessageFormat which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>Yo Yo Problem</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==

[1]http://c2.com/cgi/wiki?AntiPattern

[2]http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns

[3]http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns - Patterns and Anti patterns

[4]http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html - Singletonitis

[5]http://en.allexperts.com/e/a/an/anti-pattern.htm - Compilation of Anti patterns

[6]http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html

[7]http://c2.com/cgi/wiki$?AbstractionInversion

[8]http://sourcemaking.com/antipatterns/ambiguous-viewpoint

[9]http://www.laputan.org/mud/

[10]http://sourcemaking.com/antipatterns/functional-decomposition

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-18T22:56:25Z

Artonoops:

== Antipattern ==

An AntiPattern describes a commonly occurring solution to a problem that generates negative consequences. The term was coined in 1995 by Andrew Koenig,[3] inspired by Gang of Four's book Design Patterns, which developed the concept of design patterns in the software field. Antipatterns are documented in detail nowadays in software design because identifying bad practices can be as valuable as identifying good practices. A well formulated AntiPattern also tells us why the bad solution looks attractive (e.g. it actually works in some narrow context), why it turns out to be bad, and what positive patterns are applicable in its stead. As an example, consider braking in a car (in the days before antilock brakes): if the conditions involve ice, solving the "I must stop" problem by firmly depressing the brake would be an AntiPattern: it seems like a good idea, but it has a fatal flaw in that firm braking on ice causes skidding and little deceleration. Studying the AntiPattern teaches you to pump the brake, a more appropriate solution Pattern.
<br>
<p>AntiPatterns identify and categorize the common mistakes in software practice, which is a target-rich environment for research in AntiPatterns . AntiPatterns also identify alternative solutions and extend the field of design patterns research into exciting new areas and issues, including: refactoring, reengineering, system extension, and system migration.</p>

== When Antipatterns are used ==

Anti-patterns come into being mostly when
<ul>
<li>Not using any design patterns during design or coding though this will work at the beginning but doubtful if it will withstand the test of times.</li>
<li>Time becomes the biggest constraint. Agile methodologies dominating the projects arena in the recent times, tend to leave design to the wayside entirely and that has become the popular belief for a proper approach. This fits in perfectly with management’s request of trying to get things done right now no matter what. Refactoring becomes a much bigger part of the process through iterations. However, not attempting to recognize components and apply patterns where applicable before “diving in” and just getting it coded can very negatively effect the project’s long term success.</li>
<li>Patterns are over used and the situation does not demand it. Just like lack of design patterns usage is an antipattern, overusing patterns is an antipattern too. Extensive use of patterns, when there is not a need makes the code nowhere near maintainable. This in turn, conflicts one of the most important goals of design patterns, code maintainability.</li></ul>

== Object-oriented design anti-patterns - A subset of Software design of Anti patterns ==
A design anti-pattern in an object-oriented program, just like in software design, is an example of design that initially appeared to be a good idea, but later turned out to be a bad one. Anti-patterns are examples of bad design and bad coding practice. Some examples of object-oriented anti-patterns:
<ol>
<li>Creating massive classes with a huge number of methods.</li>
<li>Too many utility classes that perform too many operations. A utility class is one that has only static methods, no state and which performs operations on objects that are passed in.</li>
<li>Performing excessive and unnecessary run-time type checks, rather than using the type system to do the work</li>
</ol>
Anti patterns are very many since there are numerous ways to do something 'the wrong way'. Few of the object oriented design anti-patterns are discussed below.

== Types of Software design anti-patterns ==
<ul>
<li><h3>Abstraction Inversion</h3></li>

<b>Problem:</b>
Abstraction Inversion is an anti pattern where a complicated mechanism is used to build a simple abstraction, when it would be possible to do things other way around.

<b>Example:</b>
abstraction inversion arises when users of a construct need functions implemented within it but not exposed by its interface. The result is that the users re-implement the required functions in terms of the interface, which in its turn uses the internal implementation of the same functions.

<b>Solution:</b>
For designers of lower-level software:
If the system offers formally equivalent functions, choose carefully which to implement in terms of the other.
Do not force unnecessarily weak constructs on the users.
For implementers of higher-level software:
Choose the infrastructure carefully.

<li><h3>Ambiguous Viewpoint</h3></li>

<b>Problem:</b>
The viewpoint represented by the Object oriented Analysis and Design models are usually presented without any clarifications .
These models denote an implementation viewpoint that visualizes the structure of a computer program.
Mixed viewpoints do not support the fundamental separation of interfaces from implementation details.

<b>Example:</b>
Defining a class model for a telephone exchange system will vary significantly depending upon the focus provided by the following perspectives:<br>

Telephone user, who cares about the ease of making calls and receiving itemized bills.<br>
Telephone operator, who cares about connecting users to required numbers.<br>
Telephone accounting department, which cares about the formulae for billing and records of all calls made by users.<br>

<b>Solution:</b>
There are three fundamental viewpoints for OOA&D models: the business viewpoint, the specification viewpoint, and the implementation viewpoint.<br>

The business viewpoint defines the user’s model of the information and processes.<br>

The specification viewpoint focuses on software interfaces. Because objects (as abstract data types) are intended to hide implementation details behind interfaces, the specification viewpoint defines the exposed abstractions and behaviors in the object system. The specification viewpoint defines the software boundaries between objects in the system.<br>

The implementation viewpoint defines the internal details of the objects. Implementation models are often called design models in practice. To be an accurate model of the software, design models must be maintained continuously as the software is developed and modified.<br>

<li><h3>Big Ball of Mud</h3></li>

<b>Problem:</b>
A haphazardly structured code or program is referred to as a Big Ball Of Mud .
The properties of such a code or program are as follows.<br>
1. Undefined Structure<br>
2. Unregulated Growth<br>
3. Expedient Repair<br>
4. Important information is shared throughout the system to such an extent that they become global or duplicated.<br>

<b>Example:</b>
Building sytems on code which was written as a quick fix(throw away code), which is meant to be used once rather than designing a proper, general program from the ground up is an example of Big Ball of Mud.

<b>Solution:</b>
To control such a Big Ball Of Mud projects, programmers are strongly encouraged to study it and to understand what it accomplishes, and to use this as a loose basis for a formal set of requirements for a well-designed system that could replace it.

<li><h3>The Gas Factory or Unnecessary Complexity</h3></li>

<b>Problem:</b>
In a system, when implementing some structure, we always try to make it as generic as possible to make it easy to later reuse those parts. There is normal complexity when the code is built and as it continues , complexity adds up.

<b>Example:</b>
consider building few collections and one of the collection need a special feature. The problem is when this functionality is extracted to try and make it as generic as possible so that anyone could reuse your class. That is the problem of the unnecessary complexity. Making the stuff generic for a single class, structures are added inside the code. Some of those structure might be proof tested for this specific class but might fail on other classes. Another problem is that maybe no other class will ever require this functionality.

<b>Solution:</b>
This anti pattern can be avoided by following YAGNI(You aren’t gonna need it) and Lean Software Development, you delay code and unnecessary complexity until you actually require the complexity.
For example,
If you have 2 classes that require the same functionality, extract this functionality inside a different class and make those 2 classes inherit from it .

<li><h3>Functional Decomposition</h3></li>

<b>Problem:</b>
This AntiPattern is the result of experienced, nonobject-oriented developers who design and implement an application in an object-oriented language. When developers are comfortable with a “main” routine that calls numerous subroutines, they may tend to make every subroutine a class, ignoring class hierarchy altogether (and pretty much ignoring object oriented design entirely).

<b>Examples:</b>
Classes with “function” names such as Calculate_Interest or Display_Table may indicate the existence of this AntiPattern.<br>
All class attributes are private and used only inside the class.<br>
Classes with a single action such as a function.<br>

<b>Solution:</b>
Ascertain what the basic requirements are for the software, define an analysis model for the software, to explain the critical features of the software from the user’s point of view. For each step provide detailed documentation of the processes used as the basis for future maintenance efforts.Formulate a design model that incorporates the essential pieces of the required system. Do not focus on improving the model but on establishing a basis for explaining as much of the system as possible.
</ul>

== Types of Object-oriented design anti-patterns ==
<ul>
<li><h3>Anemic Domain Model</h3></li>
<b>Problem:</b>
This pattern proposed by Martin Fowler, arises when the logic is typically implemented in separate classes, which transform the state of the domain objects. With the anemic domain model, all the logic is not given with the associated object. It’s located in the objects that use them. So the problem is unless you are using the objects that have the behavior, having the anemic domain model does not do any good. In fact, they just getters and setters with barely enough behaviour to call them objects. So in short, it looks like a model, it smells like a model but there is no behavior inside.
It brings in problems like code duplication and maintenance, since the business logic is spread across the business, all the common business logic will need to be updated all at once and validated against their respective service and validation.

<b>Example:</b>
A class with a private variable and availability of no code to persist the variable's state.

<b>Solution:</b>
The business logic has to go inside your domain model and made easy to understand. Still, if a certain part of the business needs “special” behavior, it will have to be incorporated inside the main domain model such that objects can self validate since the validation logic is located inside of the object.

<li><h3>BaseBean</h3></li>
<b>Problem:</b>
In object-oriented programming, a BaseBean is a utility object from which concrete entites are derived (via subclassing). Using inheritance causes the derived class to rely on the internals of a base class which may be out of the control of the developer. While the utility classes are typically stable and fairly similar across implementations, some innocuous change in the future could break the derived class (since the relationship is not well defined). In addition, it muddies the business meaning of the derived class.

<b>Example:</b>
A class ComboBox, whose functionality needs to be extended and is done by creating a subclass of ComboBox and adding/overriding appropriate methods.

<b>Solution:</b>
A class should not inherit from another class simply because the parent class contains functionality needed in the subclass. Instead, delegation (has-a relationship) should be used to obtain the business logic or data structure that is required. In technical terms, this case warrants composition over inheritance.

<li><h3>God object</h3></li>
<b>Problem:</b>
In object-oriented programming, a God object is an object that knows too much or does too much. Concentrating too many methods in a single class makes it the only point of contact for other classes, which want to use one of its functionalities. Instead of objects communicating amongst themselves directly, the other objects rely on the God object. Because the God object is referenced by so much of the other code, maintenance becomes more difficult than it otherwise would.

<b>Example:</b>
A class by name 'ConfigParameters' does all the functions of getting the parameters from the user and setting them in a config file to the appropriate variables and is called in several parts of the program for reading config variables.

<b>Solution:</b>
The best way this anti pattern is avoided is by breaking a big problem into many smaller problems (divide and conquer) and solutions are created for each of them. If you are able to solve all of the small problems, you have solved the big problem as a whole. Therefore there is only one object about which an object needs to know everything: itself. And there is only one problem an object needs to solve: its own.

<li><h3>Singletonitis</h3></li>
<b>Problem:</b>
Overuse of the singleton pattern is referred to as Singletonitis. The major problem with the Singleton pattern is that it creates far too many dependencies within a system. When more and more classes depend on a singleton you start to end up with spaghetti code which is hard to read, even harder to debug and pretty much impossible to unit test.

<b>Example:</b>
getInstance() method used to get the instance of the Singleton class.

<b>Solution:</b>
A good solution to this problem would be to write loosely coupled, testable and reusable components. Patterns such as Inversion of Control and the containers which implement this provide excellent alternatives to the singleton.

<li><h3>Sequential Coupling</h3></li>
<b>Problem:</b>
A class suffers from sequential coupling when the consumer of the class must call the methods in a particular sequence or suffer the consequences. This anti-pattern requires an interface that forces you to call multiple methods in the particular order when the interface isn't inherently stateful (like a Collection). In some of the scenarios, the implementation might be storing state in a way that isn't clearly indicated by the interface.

<b>Example:</b>
java.util.MessageFormat which uses temporary internal state during single method calls.

<b>Solution:</b>
This might be an anti pattern depending upon the context. In some cases, refactoring might help avoiding the expensive analysis on the data.

<li><h3>Yo Yo Problem</h3></li>
<b>Problem:</b>
The yo-yo problem is an anti-pattern that occurs when a programmer has to read and understand a program whose inheritance graph is so long and complicated that the programmer has to keep flipping between many different class definitions in order to follow the control flow of the program. It often happens in object-oriented programming. The term comes from comparing the bouncing attention of the programmer to the up-down movement of a toy yo-yo.

<b>Example:</b>
Any API that has inheritance hierarchy. With methods overridden from the parent class and new methods added to the child class.

<b>Solution:</b>
It is proposed to keep the inheritance graph as shallow as possible, in part to avoid this problem. The use of composition instead of inheritance is also strongly preferred, although this still requires that a programmer keep multiple class definitions in mind at once. Techniques such as documenting layers of the inheritance hierarchy can reduce the effect of this problem, as they collect in one place the information that the programmer is required to understand.
</ul>

== Links ==

[1]http://c2.com/cgi/wiki?AntiPattern

[2]http://en.wikipedia.org/wiki/Anti-pattern#Software_design_anti-patterns

[3]http://computerprogramming.suite101.com/article.cfm/patterns_and_antipatterns - Patterns and Anti patterns

[4]http://pragmaticintegration.blogspot.com/2006/02/singletonitis.html - Singletonitis

[5]http://en.allexperts.com/e/a/an/anti-pattern.htm - Compilation of Anti patterns

[6]http://blog.decayingcode.com/2009/03/anti-pattern-gas-factory-or-unnecessary.html

[7]http://c2.com/cgi/wiki$?AbstractionInversion

[8]http://sourcemaking.com/antipatterns/ambiguous-viewpoint

[9]http://www.laputan.org/mud/

[10]http://sourcemaking.com/antipatterns/functional-decomposition

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T17:28:19Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T17:28:07Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T00:55:40Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T00:53:22Z

Artonoops: /* When Antipatterns are used */

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T00:51:20Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T00:42:12Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T00:40:17Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T00:37:44Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T00:35:48Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-11T00:34:03Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:58:29Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:57:58Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:57:30Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:53:51Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:49:40Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:47:58Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:47:12Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:43:25Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:42:50Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:17:11Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:04:41Z

Artonoops: /* Antipattern */

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-10T21:01:07Z

Artonoops:

CSC/ECE 517 Fall 2009/wiki3 1 ab

2009-11-08T22:51:43Z

Artonoops:

** Anti patterns **

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-15T18:24:32Z

Artonoops:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

<p> The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. </p>

== Service Oriented Architecture ==

<p> [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
<br><br>

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </p>

==Example for Traditional Design==
[[Image:traditionalWebApplication.jpg|120p|alt=Traditional Design|700x800px|Traditional Design]]

==Example for SOA Design==
[[Image:soa.jpg|120p|alt=SOA based Design|700x800px|SOA based Design]]

== Design patterns ==

<p> A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul></p>

== Role of design patterns in SOA ==

<p>When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. </p>

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]</b> || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] </b>|| These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]</b> || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] </b>|| These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]</b> || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]</b> || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] </b>|| These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] </b> || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]</b> || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}

<p>
<br>

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>GoF patterns expose methods
</li>
<li><b>Level of granularity that the design patterns provide:</b>
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
<li><b>Interaction provided in the patterns:</b>
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>
</p>
<p>

==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<b>Case study example</b>

For example, Lets say a company is trying to develop an entity service, called Assessments service, which will produce a range of reports and this service needs to access a number of repositories in order to gather all the required data. There exists a component based architecture that contains a Data Controller component which executes the same logic, however this component must remain independent and cannot be altered to support the new entity service. Here, an intermediate service facade component would allow the original Data Controller Component to work independently but also allow the service facade component to utilise its logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<b>Case study example</b>

If, in the example above, the Data Controller component is modified such that it does not provide access to one of the data repositories. The data access functionality to the Assessments service is partly lost. To resolve this, the developers notice that the repository in question is part of a legacy environment that runs on mainframe technologies. So they build a new Utility service to wrap this legacy mainframe system which helps them communicate with the repository by converting messages/data to the required format.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.

<b>Case study example</b>

Continuing with the example above, with the Assessment service, new services are designed as new projects emerge. Lets say one project deals with delivering a Fines and Evaluation service. This Service needs to access the database that the Data Controller uses. A decision is made to change the Data Controller component. But the problem that arises is that the Data Controller is a standalone Java EJB([http://java.sun.com/products/ejb/ Enterprise JavaBeans]), while the Fines and Evaluation Service is standardized on the web services technology framework([http://en.wikipedia.org/wiki/XML XML] and [http://www.w3.org/TR/wsdl WSDL] schema definitions). The data controller needs to comply with this as well, thus it needs to be equipped with a decoupled service contract that exists independently from its underlying service logic and can be used as a web service.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>
</p>
<p>

== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>
</p>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-15T18:23:21Z

Artonoops:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

<p> The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. </p>

== Service Oriented Architecture ==

<p> [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
<br><br>

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </p>

==Example for Traditional Design==
[[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|700x800px|Traditional Web Application]]

==Example for SOA Design==
[[Image:soa.jpg|120p|alt=SOA based Web Application|700x800px|SOA based Web Application]]

== Design patterns ==

<p> A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul></p>

== Role of design patterns in SOA ==

<p>When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. </p>

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]</b> || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] </b>|| These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]</b> || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] </b>|| These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]</b> || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]</b> || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] </b>|| These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] </b> || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]</b> || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}

<p>
<br>

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>GoF patterns expose methods
</li>
<li><b>Level of granularity that the design patterns provide:</b>
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
<li><b>Interaction provided in the patterns:</b>
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>
</p>
<p>

==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<b>Case study example</b>

For example, Lets say a company is trying to develop an entity service, called Assessments service, which will produce a range of reports and this service needs to access a number of repositories in order to gather all the required data. There exists a component based architecture that contains a Data Controller component which executes the same logic, however this component must remain independent and cannot be altered to support the new entity service. Here, an intermediate service facade component would allow the original Data Controller Component to work independently but also allow the service facade component to utilise its logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<b>Case study example</b>

If, in the example above, the Data Controller component is modified such that it does not provide access to one of the data repositories. The data access functionality to the Assessments service is partly lost. To resolve this, the developers notice that the repository in question is part of a legacy environment that runs on mainframe technologies. So they build a new Utility service to wrap this legacy mainframe system which helps them communicate with the repository by converting messages/data to the required format.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.

<b>Case study example</b>

Continuing with the example above, with the Assessment service, new services are designed as new projects emerge. Lets say one project deals with delivering a Fines and Evaluation service. This Service needs to access the database that the Data Controller uses. A decision is made to change the Data Controller component. But the problem that arises is that the Data Controller is a standalone Java EJB([http://java.sun.com/products/ejb/ Enterprise JavaBeans]), while the Fines and Evaluation Service is standardized on the web services technology framework([http://en.wikipedia.org/wiki/XML XML] and [http://www.w3.org/TR/wsdl WSDL] schema definitions). The data controller needs to comply with this as well, thus it needs to be equipped with a decoupled service contract that exists independently from its underlying service logic and can be used as a web service.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>
</p>
<p>

== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>
</p>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-15T14:01:30Z

Artonoops:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

<p> The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. </p>

== Service Oriented Architecture ==

<p> [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
<br><br>

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </p>

== Design patterns ==

<p> A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul></p>

== Role of design patterns in SOA ==

<p>When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. </p>

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]</b> || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] </b>|| These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]</b> || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] </b>|| These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]</b> || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]</b> || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] </b>|| These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] </b> || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]</b> || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}

<p>
<br>

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>GoF patterns expose methods
</li>
<li><b>Level of granularity that the design patterns provide:</b>
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
<li><b>Interaction provided in the patterns:</b>
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>
</p>
<p>

==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<b>Case study example</b>

For example, Lets say a company is trying to develop an entity service, called Assessments service, which will produce a range of reports and this service needs to access a number of repositories in order to gather all the required data. There exists a component based architecture that contains a Data Controller component which executes the same logic, however this component must remain independent and cannot be altered to support the new entity service. Here, an intermediate service facade component would allow the original Data Controller Component to work independently but also allow the service facade component to utilise its logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<b>Case study example</b>

If, in the example above, the Data Controller component is modified such that it does not provide access to one of the data repositories. The data access functionality to the Assessments service is partly lost. To resolve this, the developers notice that the repository in question is part of a legacy environment that runs on mainframe technologies. So they build a new Utility service to wrap this legacy mainframe system which helps them communicate with the repository by converting messages/data to the required format.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.

<b>Case study example</b>

Continuing with the example above, with the Assessment service, new services are designed as new projects emerge. Lets say one project deals with delivering a Fines and Evaluation service. This Service needs to access the database that the Data Controller uses. A decision is made to change the Data Controller component. But the problem that arises is that the Data Controller is a standalone Java EJB([http://java.sun.com/products/ejb/ Enterprise JavaBeans]), while the Fines and Evaluation Service is standardized on the web services technology framework([http://en.wikipedia.org/wiki/XML XML] and [http://www.w3.org/TR/wsdl WSDL] schema definitions). The data controller needs to comply with this as well, thus it needs to be equipped with a decoupled service contract that exists independently from its underlying service logic and can be used as a web service.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>
</p>
<p>

== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>
</p>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-15T02:07:43Z

Artonoops:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

<p> The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. </p>
==Traditional Web Application==
[[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|700x800px|Traditional Web Application]]

== SOA based Web Application==
[[Image:soa.jpg|120p|alt=SOA based Web Application|700x800px|SOA based Web Application]]
== Service Oriented Architecture ==

<p> [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
<br><br>

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </p>

== Design patterns ==

<p> A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul></p>

== Role of design patterns in SOA ==

<p>When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. </p>

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]</b> || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] </b>|| These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]</b> || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] </b>|| These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]</b> || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]</b> || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] </b>|| These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] </b> || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]</b> || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}

<p>
<br>

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>GoF patterns expose methods
</li>
<li><b>Level of granularity that the design patterns provide:</b>
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
<li><b>Interaction provided in the patterns:</b>
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>
</p>
<p>

==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<b>Case study example</b>

For example, Lets say a company is trying to develop an entity service, called Assessments service, which will produce a range of reports and this service needs to access a number of repositories in order to gather all the required data. There exists a component based architecture that contains a Data Controller component which executes the same logic, however this component must remain independent and cannot be altered to support the new entity service. Here, an intermediate service facade component would allow the original Data Controller Component to work independently but also allow the service facade component to utilise its logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<b>Case study example</b>

If, in the example above, the Data Controller component is modified such that it does not provide access to one of the data repositories. The data access functionality to the Assessments service is partly lost. To resolve this, the developers notice that the repository in question is part of a legacy environment that runs on mainframe technologies. So they build a new Utility service to wrap this legacy mainframe system which helps them communicate with the repository by converting messages/data to the required format.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.

<b>Case study example</b>

Continuing with the example above, with the Assessment service, new services are designed as new projects emerge. Lets say one project deals with delivering a Fines and Evaluation service. This Service needs to access the database that the Data Controller uses. A decision is made to change the Data Controller component. But the problem that arises is that the Data Controller is a standalone Java EJB([http://java.sun.com/products/ejb/ Enterprise JavaBeans]), while the Fines and Evaluation Service is standardized on the web services technology framework([http://en.wikipedia.org/wiki/XML XML] and [http://www.w3.org/TR/wsdl WSDL] schema definitions). The data controller needs to comply with this as well, thus it needs to be equipped with a decoupled service contract that exists independently from its underlying service logic and can be used as a web service.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>
</p>
<p>

== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>
</p>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-15T02:06:23Z

Artonoops:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

<p> The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. </p>
==Traditional Web Application==
[[Image:traditionalWebApplication.jpg|120p|alt=Traditional Web Applicatioo|700x800px|Traditional Web Application]]

== SOA based Web Application==
[[Image:soa.jpg|120p|alt=SOA based Web Application|700x800px|SOA based Web Application]]
== Service Oriented Architecture ==

<p> [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
<br><br>

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </p>

== Design patterns ==

<p> A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul></p>

== Role of design patterns in SOA ==

<p>When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. </p>

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]</b> || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] </b>|| These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]</b> || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] </b>|| These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]</b> || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]</b> || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] </b>|| These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] </b> || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]</b> || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}

<p>
<br>

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>GoF patterns expose methods
</li>
<li><b>Level of granularity that the design patterns provide:</b>
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
<li><b>Interaction provided in the patterns:</b>
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>
</p>
<p>

==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A pattern frequently applied to the initial design of service architecture is the Service Façade. Drawn mostly from the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

For example, Lets say a company is trying to develop an entity service, called Assessments service, which will produce a range of reports and this service needs to access a number of repositories in order to gather all the required data. There exists a component based architecture that contains a Data Controller component which executes the same logic, however this component must remain independent and cannot be altered to support the new entity service. Here, an intermediate service facade component would allow the original Data Controller Component to work independently but also allow the service facade component to utilise its logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

If, in the example above, the Data Controller component is modified such that it does not provide access to one of the data repositories. The data access functionality to the Assessments service is partly lost. To resolve this, the developers notice that the repository in question is part of a legacy environment that runs on mainframe technologies. So they build a new Utility service to wrap this legacy mainframe system which helps them communicate with the repository by converting messages/data to the required format.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.

Continuing with the example above, with the Assessment service, new services are designed as new projects emerge. Lets say one project deals with delivering a Fines and Evaluation service. This Service needs to access the database that the Data Controller uses. A decision is made to change the Data Controller component. But the problem that arises is that the Data Controller is a standalone Java EJB([http://java.sun.com/products/ejb/ Enterprise JavaBeans]), while the Fines and Evaluation Service is standardized on the web services technology framework([http://en.wikipedia.org/wiki/XML XML] and [http://www.w3.org/TR/wsdl WSDL] schema definitions). The data controller needs to comply with this as well, thus it needs to be equipped with a decoupled service contract that exists independently from its underlying service logic and can be used as a web service.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>
</p>
<p>

== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>
</p>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T23:32:34Z

Artonoops:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

<p> The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. </p>

== Service Oriented Architecture ==

<p> [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
<br><br>

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </p>

== Design patterns ==

<p> A design pattern is a general reusable solution to a commonly occurring problem in software design.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul></p>

== Role of design patterns in SOA ==

<p>When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enable the creation of effective service-oriented solutions, but also to provide effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. </p>

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on [http://www.whatissoa.com/p13.asp service inventory architecture]. Examples: enterprise inventory, domain inventory, service normalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]</b> || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] </b>|| These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and [http://www.managingautomation.com/maonline/magazine/read/view/SOAIn_The_Know_2129939 capabilities]. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position [http://en.wikipedia.org/wiki/Service-oriented_architecture#Other_SOA_concepts contracts] as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]</b> || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] </b>|| These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]</b> || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]</b> || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] </b>|| These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] </b> || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]</b> || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}

<p>
<br>

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>GoF patterns expose methods
</li>
<li><b>Level of granularity that the design patterns provide:</b>
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
<li><b>Interaction provided in the patterns:</b>
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>
</p>
<p>

==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A key pattern frequently applied to the initial design of service architecture is the Service Façade. Inspired by the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>
</p>
<p>

== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>
</p>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T23:19:04Z

Artonoops:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

<p> The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. </p>

== Service Oriented Architecture ==

<p> [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
<br><br>

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </p>

== Design patterns ==

<p> A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul></p>

== Role of design patterns in SOA ==

<p>When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. </p>

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]</b> || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] </b>|| These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]</b> || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] </b>|| These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]</b> || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]</b> || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] </b>|| These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] </b> || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]</b> || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}

<p>
<br>

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>GoF patterns expose methods
</li>
<li><b>Level of granularity that the design patterns provide:</b>
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
<li><b>Interaction provided in the patterns:</b>
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>
</p>
<p>

==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A key pattern frequently applied to the initial design of service architecture is the Service Façade. Inspired by the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>
</p>
<p>

== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>
</p>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T23:18:36Z

Artonoops:

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

<p> The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. </p>

== Service Oriented Architecture ==

<p> [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
<br><br>

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </p>

== Design patterns ==

<p> A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul></p>

== Role of design patterns in SOA ==

<p>When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. </p>

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]</b> || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] </b>|| These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]</b> || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] </b>|| These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]</b> || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]</b> || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] </b>|| These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] </b> || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]</b> || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}

<p>
<br>

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>GoF patterns expose methods
</li>
<li><b>Level of granularity that the design patterns provide:</b>
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
<li><b>Interaction provided in the patterns:</b>
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>
</p>
<p>

==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A key pattern frequently applied to the initial design of service architecture is the Service Façade. Inspired by the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>
</p>
<p>

== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>
</p>

CSC/ECE 517 Fall 2009/wiki2 16 am

2009-10-09T22:17:50Z

Artonoops:

== Service Oriented Architecture ==

<p> [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture ](SOA) can be defined as an [http://en.wikipedia.org/wiki/Architectural_pattern_(computer_science) Architectural design pattern] that concerns itself with defining loosely-coupled relationships between producers and consumers. A [http://ondotnet.com/pub/a/dotnet/2003/08/18/soa_explained.html service] is a unit of work done by a service provider to achieve desired end results for a service consumer. Both provider and consumer are roles played by software agents on behalf of their owners. It provides us with a set of principles of governing concepts used during phases of systems development and integration. Such an architecture will package functionality as 'interoperable services' ( As in the example given above, Adapters for plugs ): software modules provided as a service can be integrated or used by several organizations, even if their respective client systems (Different power outlets) are substantially different . It is an attempt to develop yet another means for software module integration.
<br><br>

Rather than defining an [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface -- API] or a bunch of hierarchical classes, SOA defines the interface in terms of protocols and functionality. An endpoint is the entry point to such an SOA implementation. SOA separates functions into distinct units, or services, which developers make accessible over a network in order to allow users to combine and reuse them in the production of applications. These services communicate with each other by passing data from one service to another, or by coordinating an activity between two or more services. </p>

== The need for [http://en.wikipedia.org/wiki/Service-oriented_architecture Service-Oriented Architecture -- SOA] ==

<p> The need for building new systems is to achieve simplicity of usage and reuse existing software solutions for new challenges. Simplicity is lost in the process when real dependencies are overtaken by artificial dependencies. To differentiate between real and artificial dependencies, let us consider the example when we travel overseas on business. We know that we must bring our own power adapters along or life can be miserable. The real dependency is that we need power; the artificial dependency is that our plug must fit into the local outlet. So in order to build a simple system, the principle needs to be such that 'artificial dependencies should be reduced to the minimum but real dependencies should not be altered'. Applying this principle to the example, it means that the artificial dependencies between the power plugs and the power outlets should be minimized and the components should be made more loosely connected to each other. To achieve this principle, we seek the idea of SOA. </p>

== Design patterns ==

<p> A design pattern is a general reusable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code.
<ul><li>It is a description or template for how to solve a problem that can be used in many different situations.</li>
<li>Design patterns typically show relationships and interactions between entities, without specifying the final actual clients that are involved. </li>
<li>Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. </li>
<li>Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.</li> </ul></p>

== Role of design patterns in SOA ==

<p>When carrying out an SOA initiative, we need to pay attention to many design details with every service we deliver, while always keeping the big picture in our sights. Design patterns support us in maintaining this balance by helping us overcome common obstacles that have historically inhibited or even derailed SOA project plans. They establish an environment that is conducive not just to enabling the creation of effective service-oriented solutions, but also to enabling the effective long-term governance and evolution of the individual services that can be composed and recomposed to comprise these solutions. </p>

== Categories of SOA Design Patterns ==

{| border="1"
|-
!Category !! Objective
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch6 Foundational Inventory Patterns]</b> || These patterns define an SOA model with an emphasis on service inventory architecture. Examples: enterprise inventory, domain inventory, service normalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch7 Logical Inventory Layer Patterns] </b>|| These patterns establish service layers based on utility service models, business-logic entity service models, and single-purpose task service models. Examples: utility abstraction, entity abstraction, process abstraction.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch8 Inventory Centralization Patterns]</b> || These patterns address physical aspects of service inventory architecture. Examples: process centralization, schema centralization, policy centralization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch9 Inventory Implementation Patterns] </b>|| These patterns help solve implementation-level problems. Examples: dual protocols, canonical resources, state repository.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch10 Inventory Governance Patterns] </b>|| These patterns supply fundamental design-time solutions for post-implementation services evolution. Examples: canonical expression, metadata centralization, canonical versioning.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch11 Foundational Service Patterns]</b> || These patterns represent the steps required to partition and organize logic into services and capabilities. Examples: functional decomposition, service encapsulation, agnostic context.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch12 Service Implementation Patterns]</b> || These patterns impact or augment the physical implementation of the service architecture, to help respond to ongoing changes, address scalability, and runtime message processing. Examples: service façade, redundant implementation, service data replication.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch13 Service Security Patterns]</b> || These patterns extend service design in support of increased protection from security threats. Examples: exception shielding, message screening, trusted subsystem.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch14 Service Contract Design Patterns] </b>|| These patterns help position contracts as independent yet still central parts of service architectures. Examples: decoupled contract, contract centralization, contract denormalization.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch15 Legacy Encapsulation Patterns] </b>|| These patterns address common challenges with service encapsulation of legacy systems and environments. Examples: legacy wrapper, multi-channel endpoint, file gateway.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch16 Service Governance Patterns]</b> || These patterns help evolve services without compromising their responsibilities as active members of the service inventory. Examples: compatible change, version identification, termination notification.
|-
|<b>[http://www.soapatterns.org/masterlist_c.asp#ch17 Capability Composition Patterns] </b>|| These patterns provide a means by which to assemble and compose together the service logic resulting from service identification and definition patterns. Examples: capability composition, capability recomposition.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch18 Service Messaging Patterns]</b> || These patterns provide various techniques for processing and coordinating data exchanges between services. Examples: service messaging, messaging metadata, service agent.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch19 Composition Implementation Patterns]</b> || These patterns provide design solutions that address implementation-level issues pertaining primarily to runtime service activity management and composition structure. Examples: agnostic sub-controller, composition autonomy, atomic service transaction.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch20 Service Interaction Security Patterns] </b>|| These patterns focus on applying security at the message level. Examples: data confidentiality, data origin authentication, direct authentication.
|-
|<b> [http://www.soapatterns.org/masterlist_c.asp#ch21 Transformation Patterns] </b> || These patterns address the interoperability obstacles of communications, data formats, and data models. Examples: data model transformation, data format transformation, protocol bridging.
|-
| <b>[http://www.soapatterns.org/masterlist_c.asp#ch22 Common Compound Design Patterns]</b> || These patterns document the effects of applying multiple patterns together. Examples: official endpoint, federated endpoint layer, three-layer inventory.
|}

<p>
<br>

== SOA design patterns and traditional design patterns [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four -- GoF] patterns ==

[http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented](OO) concepts such as [http://en.wikipedia.org/wiki/Inheritance_(object-oriented_programming) inheritance], [http://en.wikipedia.org/wiki/Encapsulation_(computer_science)#Encapsulation encapsulation], and [http://en.wikipedia.org/wiki/Polymorphism_in_object-oriented_programming polymorphism] that could be applied to define relationships between classes. Software, developers and architects noticed some patterns that can be applied to the usage of OO principles to solve similar types of problems. A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides ("Gang of Four" authors). In OO the first-class constructs were objects and classes.

In SOA, the main emphasis is on the identification of the right services followed by their specification and realization. Services are business-aligned entities and are at a much higher level of abstraction than are objects and components. The main first-class constructs in an SOA are services, service components, and process flows. These are at a level of abstraction that is higher than that of objects, classes, and components. Hence, there needs to be a higher level of modeling and design principles that deal with the first-class constructs of an SOA.

== Differences between SOA design patterns and traditional patterns ==

<ul>
<li><b>Aim of design patterns:</b>
<br>SOA patterns are more about Modeling, Design, Architecture
<br>GoF patterns are about Modeling, Design, Architecture and Programming
</li>
<li><b>What the design patterns expose:</b>
<br>SOA patterns expose services
<br>GoF patterns expose methods
</li>
<li><b>Level of granularity that the design patterns provide:</b>
<br>SOA patterns exhibit business-level granularity
<br>GoF patterns exhibit component/object-level granularity
</li>
<li><b>Interaction provided in the patterns:</b>
<br>SOA patterns interact at the service-level, inter-service via service requests
<br>GoF patterns interact component/object-level, inter-objects/components via method calls
</li>
<li><b>Standards for patterns:</b>
<br>SOA patterns are in the nascent stages. They are being collected and organised from emerging best practices.
<br>GoF patterns contain a lot of best practices and excellent tools. They have a mature knowledge base in the industry.
</li>
</ul>
</p>
<p>

==Similarities between traditional design patterns and the SOA design patterns==

A variety of design patterns which supported object-orientation have been published by Gamma, Helm, Johnson, Vlissides. This set of 23 patterns produced by the "Gang of Four" helped established object-orientation as a design approach for distributed solutions. Some of these patterns have persisted within service-orientation as detailed below:

<li><h4>[http://www.informit.com/articles/article.aspx?p=1271262 Capability Composition Pattern] (SOA) is related to [http://en.wikipedia.org/wiki/Composite_pattern Composite Pattern] (Traditional)</h4></li>

These patterns provide the means to assemble and compose together the basic entity's(Objects and classes in terms of traditional patterns and Services in terms of SOA patterns) logic. Logic is aggregated to solve one or more larger problems. They help ensure
that this decomposition of one entity into two or more does not impact the contract (technical interface) of the original piece, thereby also avoiding impact to that entity's consumer programs.

<li><h4>[http://www.soapatterns.org/service_facade.asp Service Facade Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Facade_pattern Facade Pattern] (Traditional)</h4></li>

A key pattern frequently applied to the initial design of service architecture is the Service Façade. Inspired by the Façade pattern created by the Gang of Four, this pattern wedges a component between the service contract and the core service logic to establish a point of abstraction. It provides supplemental, intermediate processing logic in support of the core service logic.

<li><h4>[http://www.soapatterns.org/legacy_wrapper.asp Legacy Wrapper Pattern] (SOA) is derived from [http://en.wikipedia.org/wiki/Adapter_pattern Adapter Pattern] (Traditional)</h4></li>

These patterns are used to address various implementation and scalability-related requirements just like the Adapter pattern, while maintaining the overall flexibility required for services to be repeatedly composed and extended, as required. An example where classes have incompatible interfaces due to a modification, these patterns help by translating one interface for a class into a compatible interface to allow all the other classes to work together. They actually providing their interface to clients on the outside while internally using the original incompatible interface.

<li><h4>[http://www.soapatterns.org/non_agnostic_context.asp Non-Agnostic Context] (SOA) is similar to [http://en.wikipedia.org/wiki/Mediator_pattern Mediator Pattern] (Traditional)</h4></li>

Agnostic ("without knowledge") logic is logic that is sufficiently generic so that it is not specific to (has no knowledge of) a particular parent task is classified as agnostic logic. Agnostic logic is considered multi-purpose; logic that is specific to (contains knowledge of) a single-purpose task is labeled as non-agnostic logic. Another way of thinking about agnostic and non-agnostic logic is to focus on the extent to which the logic can be re-purposed.

Non-Agnostic Context provide criteria that help determine whether certain kinds of logic are deemed sufficiently agnostic to be put into a reusable or multi-purpose service.

SOA's Non-Agnostic Context Patterns and traditional GoF's Mediator design pattern serve similar purposes.

<li><h4>[http://www.soapatterns.org/decoupled_contract.asp Decoupled Contract Pattern] (SOA) is associated with [http://en.wikipedia.org/wiki/Bridge_pattern Bridge Pattern] (Traditional)</h4></li>

Services built using component-centric technologies such as .NET and Java require the service contract to be expressed via the same native technologies used to build the components. Thus the utilization and evolution of services is inhibited because they can only be used by the consumer programs compatible with their technology. These patterns enable the service contract to be physically decoupled from its implementation just like the bridge pattern, which '<i>decouples an abstraction from its implementation</i>'. It allows the service contract to be created as a physically separate part of the overall service implementation.

== Resources ==

<ul>
<li>Text - Design Patterns: Elements of Reusable Object-Oriented Software (E. Gamma, R. Helm, R. Johnson, J. Vlissides, Addison-Wesley 1994)</li>
<li> SOA Design Patterns by Thomas Erl </li>
<li> [http://www.wikipedia.org/ Wikipedia] </li>
<li>[http://www.soaglossary.com/ SOA Glossary]</li>
<li>[http://www.xml.com/pub/a/ws/2003/09/30/soa.html SOA]</li>
<li>[http://www.soapatterns.org SOA design patterns] </li>
<li>[http://www.soapatterns.org/soa_patterns_article.pdf Need for SOA design patterns]</li>
<li>[http://schneider.blogspot.com/2008/06/gartner-soa-design-patterns.html SOA design patterns observed by Gartner analysts]</li>
<li>[http://soa-eda.blogspot.com/2007/01/what-is-service-in-soa.html What is a Service?]</li>
<li>[http://my.safaribooksonline.com/9780137149476/ch04 Executing SOA: A Practical Guide for the Service-Oriented Architect]</li>
</ul>
</p>
<p>

== Abbreviations ==
<ul>
<li>SOA - [http://en.wikipedia.org/wiki/Service-oriented_architecture Service Oriented Architecture]</li>
<li>API - [http://en.wikipedia.org/wiki/Application_programming_interface Application Programming Interface]</li>
<li>GoF - [http://en.wikipedia.org/wiki/Design_Patterns:_Elements_of_Reusable_Object-Oriented_Software Gang of Four]</li>
<li>OO - [http://en.wikipedia.org/wiki/Object-oriented_programming Object oriented]</li>
</ul>
</p>