Design Patterns

At Ishi, we have been using Design Patterns since 1995 and have delivered numerous successful projects using them. We use Design Patterns primarily for:

• A language for communicating concepts among architects, designers and developers. In our experience, this accelerates development while lowering defects.
• Reuse at design level. We prevent ourselves from the “not invented here syndrome”, and use proven designs to increase reliability and reduce risk.
• Develop common programming models and micro-architectures.

Anti-Patterns

• Where good solutions exist naturally in a repeated manner (Design Patterns), bad ones also repeat themselves. Anti-Patterns describe a commonly occurring solution to a problem that results in negative consequences. They are a natural extension to Design Patterns. They bridge the gap between architectural concepts and real-world implementations.
• While Design Patterns are Problem + Solution pairs, Anti-Patterns are Solution (problematic) + Solution (refactored) pairs. We identify Anti-Patterns from their contextual causes and solve the problems created by the earlier solution using refactoring.

Coding Standards

We use coding standards compliant to the client’s enterprise standards. If the client does not have them, we provide a starter set. Coding Standards allow us:

• To write maintainable code rapidly as they enhance the programming model
• To improve readability, allowing our engineers to understand new code more quickly and thoroughly

Some common standards we use are categorized as:

• Naming Conventions
• Control structures and types (class or interface) definitions
• File Suffixes and common file names (e.g. README)
• Formatting Conventions (Line length, wrapping lines, etc.)
• Implementation comments and in-code documentation

Component Based Development Techniques

• Business Component Identification
• Component Design
• Design by Contract
• Build vs. Buy decisions
• Composition
• Build services on top of components