What are Anti-Patterns?

A pattern is a common solution to a problem that occurs in many different contexts. It provides a general solution that may be specialized for a given context. Patterns capture expert knowledge about “best practices” in software design in a form that allows that knowledge to be reused and applied in the design of many different types of software. Patterns address the problem of “reinventing the wheel.”

In computer science, anti-patterns are specific repeated practices that appear initially to be beneficial, but ultimately result in bad consequences that outweigh the hoped-for advantages. They are known as anti-patterns because their use (or misuse) produces negative consequences. Anti-patterns document common mistakes made during software development as well as their solutions.

There must be at least two key elements present to formally distinguish an actual anti-pattern:

· Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results, and

· A refactored solution that is clearly documented, proven in actual practice and repeatable.

Avoiding anti-patterns requires diagnosing them as early as possible in the software life-cycle. The concept of anti-patterns is readily applied to engineering in general.

Some of the Classic Anti-Patterns are:

Organizational anti-patterns

§ I told you so: When the ignored warning of an expert proves justified, and this becomes the focus of attention.

§ Mushroom management: Keeping employees uninformed and misinformed (kept in the dark and fed manure).

§ Design by committee: The result of having many contributors to a design, but no unifying vision.

Project management anti-patterns

§ Smoke and mirrors: Demonstrating how unimplemented functions will appear.

§ Software bloat: Allowing successive versions of a system to demand ever more resources.

Analysis anti-patterns

§ Retro-specification: To write the Technical/Functional specification after the project has already gone live.

§ Napkin specification: The Functional/Technical specification is given to the Development team on a napkin (i.e., informally, and with insufficient detail) which is fundamentally equivalent to having no specification at all.

General design anti-patterns

§ Re-coupling: Introducing unnecessary object dependency.

§ Gas factory: An unnecessarily complex design.

§ Interface bloat: Making an interface so powerful that it is extremely difficult to implement Stovepipe system: A barely maintainable assemblage of ill-related components.

Object-oriented design anti-patterns

§ Singletonitis: The overuse of the singleton pattern.

§ BaseBean: Inheriting functionality from a utility class rather than delegating to it.

§ Call super: Requiring subclasses to call a superclass's overridden method.

§ Poltergeists: Objects whose sole purpose is to pass information to another object.

§ Yet Another Damn Layer: Adding unnecessary layers to a program, library or framework. This became popular after the first book on programming patterns.

Programming anti-patterns

§ Accidental complexity: Introducing unnecessary complexity into a solution.

§ Coding by exception: Adding new code to handle each special case as it is recognized.

§ Magic strings: Including literal strings in code, for comparisons, as event types etc.

§ Monkey work: Term for any general repeated support code required within projects which suffer from poor code reuse and design. Is often avoided and rushed, hence open to errors and can quickly become a Bug magnet.

§ Wrapping wool in cotton: Commonly observed when framework methods are contained in single line methods in wrapper classes which provide no useful abstraction.

Testing anti-patterns

§ Hostile testing: Antagonizing practical development solutions and workflow with over-testing procedures or over-scheduling test runs.

§ Meta-testing: Overdesigning testing procedures until it is necessary to test them, also known as "watchmen's watchmen".

§ Moving target: Continuously change design and/or implementation in order to escape established testing procedures.

§ Slave testing: Conditioning testers by means of black-mail or corruption to satisfy the stakeholders urge to flag positive compliance.

Seminar on Software Architecture by Microsoft !

Check out the Microsoft Architecture Days - Seminar for Solution/Application/Aspiring architects at Banglore/Chennai/Hydrabad.

Visit : http://www.msarchitecturedays.com/default.aspx

Whats new in Visual Studio 2008 ????

Microsoft Visual Studio .NET 2008 has been released. Click here to find out Whats new in Visual Studio .NET 2008.

What is an Application Security? What is STRIDE security model?

You can secure your application by employing several security mechanisms, such as firewalls, proxies, secure channels, and authentication schemes. However, all it takes for a security breach to occur is for an attacker to find one weakness in your system. It is said that security is like a chain. The total strength of the chain is equal to the strength at its weakest point.

Attackers use various methods to exploit system vulnerabilities to achieve their goals. Vulnerabilities are weak points or loopholes in security that an attacker exploits to gain access to an organization’s network or to resources on the network. Some of the vulnerabilities are weak passwords, misconfigured software, unencrypted data, SQL injections, cross site scripting, social engineering.

To design a secure application, you should be familiar with the following principles of security and employ them when creating security strategies:

1. Rely on tested and proven security systems.

2. Never trust user input.

3. Assume that external systems are not secure.

4. Follow STRIDE principles.

STRIDE security Model:

Each letter in the STRIDE acronym specifies a different category of security threat:

1. Spoofing identity

2. Tampering

3. Repudiation

4. Information disclosure

5. Denial of service

6. Elevation of privilege.

Application architects should design the systems in such as way that they cover all the aspects of security as per the STRIDE model. Mechanism are available in .NET to counter security attacks, it all depends on the design if your system.

What are software Design Patterns?

A design pattern in software engineering is a general reusable solution to a commonly occurring problem in software design. Patterns originated as an architectural concept by Christopher Alexander (1977/79).
Some of the design patterns used in the software industry are listed below:

Creational patterns

Abstract Factory
Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

Factory method
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Builder
Separate the construction of a complex object from its representation so that the same construction process can create different representations.

Lazy initialization
Tactic of delaying the creation of an object, the calculation of a value, or some other expensive process until the first time it is needed.

Object pool
Avoid expensive acquisition and release of resources by recycling objects that are no longer in use.

Prototype
Specify the kinds of objects to create using a prototypical instance, and create new objects by copying this prototype.

Singleton
Ensure a class only has one instance, and provide a global point of access to it.

Structural patterns

Adapter
Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

Bridge
Decouple an abstraction from its implementation so that the two can vary independently.

Composite
Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.

Decorator
Attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.

Facade
Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.

Flyweight
Use sharing to support large numbers of fine-grained objects efficiently.

Proxy
Provide a surrogate or placeholder for another object to control access to it.

Behavioral patterns

Chain of responsibility
Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.

Command
Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations.

Interpreter
Given a language, define a representation for its grammar along with an interpreter that uses the representation to interpret sentences in the language.

Iterator
Provide a way to access the elements of an aggregate object sequentially without exposing its underlying representation.

Mediator
Define an object that encapsulates how a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and it lets you vary their interaction independently.

Memento
Without violating encapsulation, capture and externalize an object's internal state so that the object can be restored to this state later.

Observer
Define a one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

Intercom
Define a many-to-many as well as one-to-many dependency between objects so that when one object changes state, all its dependents are notified and updated automatically.

State
Allow an object to alter its behavior when its internal state changes. The object will appear to change its class.

Strategy
Define a family of algorithms, encapsulate each one, and make them interchangeable. Strategy lets the algorithm vary independently from clients that use it.

Specification
Recombinable Business logic in a boolean fashion.

Template method
Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

Visitor
Represent an operation to be performed on the elements of an object structure. Visitor lets you define a new operation without changing the classes of the elements on which it operates.

Single-serving visitor
Optimize the implementation of a visitor that is allocated, used only once, and then deleted.

Hierarchical visitor
Provide a way to visit every node in a hierarchical data structure such as a tree.