Pro .NET 2.0 Code And Design Standards In CSharp (2006) [eng]

276 L I S T O F S TA N D A R D S

try-finally

The standard acknowledges the use of the try-finally statement as a mechanism where it is necessary to attempt to execute a block of code (in the try block) and, regardless of the outcome, execute a subsequent code block (in the finally block).

try-catch-finally

The standard acknowledges the use of try-catch-finally statement or block where a comprehensive exception handling methodology is a requirement. It is mindful of the extra resources necessary to support catch statements and the benefit of arranging them descending in likelihood of occurrence.

do-while

The standard acknowledges the use of the do-while statement where there is a requirement to iterate an iteration block at least once.

while

The standard acknowledges the use of while statement where there is a requirement for iterative flexibility: to iterate zero or more times (place while at the head of an iteration block) or at least once (place a while statement at the tail of an iteration block and a do statement at the head of the iteration block).

for

The standard acknowledges the use of the for statement where there is a requirement to test a condition, by using the value in the index variable, before entering an embedded code block.

foreach

The standard acknowledges the use of the foreach statement where there is a requirement to iterate a collection—for example, objects or controls.

Code Documentation Standards

The following standards are the code documentation standards that appear in Chapter 4.

Development Documentation Policy

The standard acknowledges the importance of knowledge retention and that a documentation policy may be used to minimize the risk of knowledge degradation.

Code Design Documentation

The standard acknowledges the importance of documenting code design so that it readily identifies and explains key aspects of the underlying code design strategy, rationale, and structure.

Code Design Log

The standard acknowledges the use of a code design log as an intuitive and quick method to document code design. It may be prepared as a txt, xml, or html template and stored inside a folder within a Visual Studio solution, for example.

Line Comment

The standard acknowledges the use of the line comment, which may be used as a single line comment, a multiline comment, or an end-of-line comment.

Block Comment

The standard acknowledges the use of the block comment where documentation is extensive. However, it notes that Visual Studio’s line comment tool may be a more convenient method to comment blocks.

XML Comments

The standard acknowledges the use of XML comments as a form of internal and external code documentation.

Object Browser Comments

The standard acknowledges the use of object browser comments as a form of internal and external type documentation, and notes that it conveniently publishes the documentation in the Visual Studio IDE, which makes it readily accessible for developers and application architects.

XML and Line/Block Comments

The standard acknowledges the partnership of XML and line/block comments in documenting code.

Design Policy Standards

The following standards are the design policy standards that appear in Chapter 5.

Design Policy

The standard acknowledges that a design policy is an effective and efficient way to coordinate the management of a range of interrelated architectures that have different dynamics.

Design Objectives

The standard acknowledges that design objectives are an essential part of managing the design of an enterprise because they identify in concrete terms what needs to be done.

Design Style

The standard acknowledges the use of design style, which seeks to ensure that the enterprise is and remains structured in a way that complements an organization’s (dynamic) business strategy.

278 L I S T O F S TA N D A R D S

Architecture Framework

The standard acknowledges the use of an architecture framework to strategically use architecture to manage an enterprise.

Target Architecture

The standard acknowledges that the target architecture encapsulates and coordinates change as a version or iteration of the enterprise and avoids the high risk associated with implementing structural change in an impulsive or ad hoc manner.

Architecture Roadmap

The standard acknowledges the use of an architecture roadmap as a guide to migrating an existing architecture to a target architecture.

Architecture

The standard acknowledges the use of architecture to manage enterprise artifacts in line with technical and functional objectives.

Enterprise Architecture

The standard acknowledges the use of enterprise architecture as an efficient and effective way to manage technology, across an enterprise, in line with a business strategy.

Network Architecture

The standard acknowledges the use of network architecture as a tool to support the strategic requirements of software, technology, data, and deployment architectures, within the context of an architecture framework.

Technical Architecture

The standard acknowledges the use of technical architecture as an efficient and effective way to maximize decoupling and minimize duplication, within the context of an architecture framework.

Software or Application Architecture

The standard acknowledges the use of application architecture as an efficient and effective way to manage application design and development within the context of an architecture framework.

Data Architecture

The standard acknowledges the use of data architecture as an efficient and effective way to support information requirements within the context of an architecture framework.

Deployment Architecture

The standard acknowledges the use of deployment architecture as an efficient and effective way to deploy functionality and data throughout an enterprise within the context of an architecture framework.

Integration Architecture

The standard acknowledges the use of integration architecture as an efficient and effective way to manage the integration of functionality and data throughout an enterprise within the context of an architecture framework.

Service-Oriented Architecture

The standard acknowledges the use of service-oriented architecture as an efficient and effective way to manage the publication and subscription of functionality and data throughout an enterprise within the context of an architecture framework.

Business Architecture

The standard acknowledges the use of business architecture to identify a strategic purpose to unite and coordinate a set of architectures to manage and safeguard the enterprise.

Design Structure Standards

The following standards are the design structure standards that appear in Chapter 6.

Structural Design

The standard acknowledges the design and management of an enterprise through the use of a structural design methodology.

Design Dichotomy

The standard acknowledges that consideration may be given to determine whether functionality has an enterprise or a limited domain role. The earlier the consideration is made, the better.

Modularity

The standard acknowledges the use of modularity as a method to design, build, and maintain complex structures.

Coupling

The standard acknowledges the appropriate management of coupling and the value of decoupling where the exercise of discretion effects a net positive return on investment.

Layers

The standard acknowledges the use of layers as an efficient and effective way to design, develop, maintain, and manage complex and large structures.

Design Context

The standard acknowledges that the design workspace has to be identified, so that appropriate resources may be organized. It practice, not all of the functionality of an enterprise may be included within an enterprise context.

280 L I S T O F S TA N D A R D S

Enterprise Design Framework

The standard acknowledges the use of an enterprise design framework where there are many structures that need to be managed as a cohesive composite.

Application Layer

The standard acknowledges that the design, development, and maintenance of software is a specialized skill with its own set of dynamics. Encapsulating domain software into

a layer is an efficient and convenient way to manage the special needs of application development.

Domain Application

The standard acknowledges the design and development of domain applications to service the custom or non-universal requirements of a domain.

Enterprise Application

The standard acknowledges the use of enterprise applications to provide functionality that is routine or universal and is without a domain imperative.

Services Application

The standard acknowledges the use of services applications to distribute functionality across an enterprise as an effective and efficient way to manage functionality.

Two-Tier Design

The standard acknowledges the use of a two-tier design where there is a need for rapid development and high performance. It does caution, however, that over the medium to long term the design may encounter integration inefficiencies, and scalability, coupling, and maintenance issues.

Three-Tier Design

The standard acknowledges the use of a three-tier design where there is a requirement for an application that features high performance with a medium-to-long life expectancy. It cautions, however, that the business and data classes may be tightly coupled implementations to the user interface and datastore, which may cause future concern.

Five-Tier Design

The standard acknowledges the use of a five-tier design where there is a requirement for an application that requires high performance, presentation, and data source flexibility with a long life expectancy.

Application Integration Layer

The standard acknowledges the use of an application integration layer to avoid the cost of high maintenance, duplication, and tight coupling.

Enterprise Services Design

The standard acknowledges the use of enterprise services that seek to standardize resource availability, usability, adaptability, and stability while preventing or removing duplication and redundancy.

Communications Integration Layer

The standard acknowledges the use of a communication’s integration layer to centralize and coordinate the integration of multiple artifacts that may to enable a more efficient, maintainable, and loosely coupled solution.

Communication Infrastructure Layer

The standard acknowledges the use of a communication infrastructure layer to manage and encapsulate communication functionality within an enterprise framework.

Design Development Standards

The following standards are the design development standards that appear in Chapter 7.

Design of Enterprise Services Layer

The standard acknowledges the design of an enterprise services layer and its role to publish generic functionality that is highly visible and accessible to enable functionality to be managed more effectively and efficiently throughout the enterprise.

Design of Application Integration Layer

The standard acknowledges the design of an application integration layer, and its role is to satisfy domain and vendor requirements by providing a service that offers integration functionality that is customizable, transparent, and highly visible.

Design of Application Layer

The standard acknowledges the design of an application layer and that its role enables isolation of application code from integration and services code, which maximizes portability and minimizes the impact of change.

Horizontal Design Development

The standard acknowledges horizontal design development as a method to regulate design development through layers, which seeks to ensure that the inherent purpose of the layer does not become biased or coupled to an application implementation.

Vertical Design Development

The standard acknowledges vertical design development as a method to regulate domain development, but cautions that code and design may be excessively coupled to a domain, which may make it a poor candidate to migrate to other layers for reuse.

282 L I S T O F S TA N D A R D S

Object Collaboration

The standard acknowledges the importance of the role of object collaboration because it is the collaboration of exchanging messages between objects that yields the functionality of an application.

Object Collaboration (Abstract-Interface Dichotomy)

The standard acknowledges that it is not always obvious when to use class or interface inheritance to design the interface of an object. A key to the dilemma is that an interface type is used to signify a role that an object can perform—an interface type is suitable to perform generic roles.

Object Collaboration (Composition-Inheritance Dichotomy)

The standard acknowledges that there is a dilemma when designing objects because there are two ways to acquire an interface: through composition or inheritance. A key to the dilemma is that class inheritance is more sensitive to change than is composition. GoF propose a principle: “Favor object composition over class inheritance.”

Object Collaboration (Abstraction-Implementation Dichotomy)

The standard acknowledges that problems arise because at some point a design has to commit to an implementation; however, it needs to balance the cost of commitment against the need for flexibility in a dynamic domain. A key to the dilemma lies in using polymorphism, which enables an object to be treated as an implementation or as an interface at run time. GoF propose a principle: “Program to an interface, not an implementation.”

Collaborative Code (Design Patterns)

The standard acknowledges the role that design patterns play in solving problems of objects collaborating in a dynamic domain.

Start-from-Scratch Application Solution

The standard acknowledges that a start-from-scratch application is used where there is very little code to reuse, and so developers start from scratch. It cautions that such a

practice is generally inefficient as it may result in duplication of functionality and higher maintenance (compared with the use of a framework).

Application Frameworks Solution

The standard acknowledges the use of application frameworks, which are partially prebuilt solution templates, as an efficient and effective way to reuse proven design and functionality.

Design Documentation Standards

The following standards are the design documentation standards that appear in Chapter 8.

Application Design Documentation Policy

The standard acknowledges the implementation of a single application design documentation policy across all projects within a given site.

Application Specification Documentation

The standard acknowledges the role of technical specification documentation and its importance in supporting the functional specification of an application.

Functional Specification Documentation

The standard acknowledges the role of functional specification documentation and its importance in directing the design and development of an application and in evaluating and verifying that an application meets client requirements.

Application Design Documentation

The standard acknowledges the documentation of application design and observes that it should be readily accessible to architects and developers.

Application Architecture Documentation

The standard acknowledges the documentation of application architecture and that it should be readily accessible to architects and developers. Documentation enables a team to retain and share critical architecture design knowledge that identifies and explains the underlying intention of the application architect and lead developer.

Enterprise Framework Documentation

The standard acknowledges the documentation of application design as it relates to the enterprise architecture and that it should be readily accessible to architects and developers. Documentation enables a team to retain and share critical architecture design knowledge that identifies and explains the underlying intention of the enterprise and application architects and lead developer.

Pattern Standards

The following standard is the MVC design pattern standard that appears in Chapter 9—note that the other pattern standards, articulated by GoF, are in subsequent chapters.

MVC Design Pattern

The standard acknowledges the use of the MVC design pattern where there is a requirement to vary perspectives or views (output) without disturbing—or while minimizing the disruption to—the underlying information source (model) that publishes the information.

284 L I S T O F S TA N D A R D S

Creational Pattern Standards

The following standards are the creational pattern standards that appear in Chapter 10.

Abstract Factory Design Pattern

The standard acknowledges the use of the Abstract Factory design pattern when there is a requirement not to couple the client to an implementation that creates sets or families of object, yet to let the client indirectly control the build process.

Factory Method Design Pattern

The standard acknowledges the use of the Factory Method design pattern where there is a design problem when a creator class is required to be decoupled from creating specific objects.

Singleton Design Pattern

The standard acknowledges the use of the Singleton design pattern where there is a design problem when there can only be one instance of a given object and where there is a requirement for client code to trigger the creation of the object.

Structural Pattern Standards

The following standards are the structural pattern standards that appear in Chapter 11.

Surrogate-Proxy Design Pattern

The standard acknowledges the use of the Surrogate-Proxy design pattern where there is a design problem such that access to a principal (e.g., scarce resource) needs to be regulated.

Remote-Proxy Design Pattern

The standard acknowledges the use of the Remote-Proxy design pattern where there is a design problem such that access to a principal needs to be distributed through representation.

Adapter Design Pattern

The standard acknowledges the use of the Adapter design pattern where there is a design problem, where there is a requirement to integrate with a noncompliant interface, or where there is a requirement for one design to leverage the functionality from one design into another design.

Composite Design Pattern

The standard acknowledges the use of the Composite design pattern where there is a design problem where there is a hierarchy of entities and a requirement for a simple nonconditional methodology to manage single and composite entities.