Pro .NET 2.0 Code And Design Standards In CSharp (2006) [eng]
.pdf
36C H A P T E R 2 ■ C O D E S T R U C T U R E
developed in different code files by different developers. The two files reside in the same namespace, and when the files are compiled, the functionality is combined by the compiler.
File1.cs
namespace ModelT
{
//part 1
public partial class MyCar
{
public void StartEngine() {;}
}
} //end namespace
File2.cs
namespace ModelT
{
//part 2
public partial class MyCar
{
public void StopEngine() {;}
}
} //end namespace
The Standard: Partial Type
The standard acknowledges the use of partial type where there is a requirement to split a type over multiple files but cautions that once the type is compiled, it cannot be extended.
Generic Type (Introduced C# 2.0)
Generics introduce a flexibility that combines type safety with the ability to avoid committing to a type at design time.
What
Generics enable class, delegate, interface, and struct types, and methods to be created with type parameters that are placeholder types, which can be substituted when the type is known.
Where
Generics are commonly used in data structures—for example, collections and arrays, or in passing method parameters.
C H A P T E R 2 ■ C O D E S T R U C T U R E |
37 |
Why
Generics overcome the overhead issues of casting and boxing between types, which adversely affects performance.
How
Generics are specified within a pair of delimiters (“<” and “>”) placed after the respective type or method name. When the type is known, it is substituted for the generic placeholder, as the following code snippet illustrates. Note that the method GenericMethod is declared as generic, as is its parameter. In the Main function, we vary the types of the method.
using System;
using System.Collections.Generic; using System.Text;
namespace ModelT
{
public class ModelTGenerics
{
public static void GenericMethod<T>(T arg)
{
Console.WriteLine("Calling Model T generic method, " + arg.GetType());
}
public static void Main()
{
//Call the generic method passing different types: GenericMethod<string>("Hallo Generics"); GenericMethod<double>(16.75);
}
}
}
The Standard: Generic Type
The standard acknowledges the use of generics to reduce overhead and increase type flexibility while retaining the protection of type safety.
C H A P T E R 3
■ ■ ■
Code Development
The previous chapter focused on how code can be structured into assembly, namespace, and complex types. This chapter builds on that knowledge by focusing on how to develop the code that will use those structures. The discussion will cover development perspectives, application development methods, application architecture, class development, building a class interface, accessibility, and class fundamentals.
Development Perspectives
There are two ways of looking at application code development: developing an application or developing an enterprise. Generally, the immediate thought lies with developing an application and its functionality. However, to stop there would result in an overly narrow view, because an application is not an island: it is part of an enterprise that may host 50 or 5,000 applications, for example. The application may consume common functionality, or it may contribute functionality that is published through an integration or services layer, which in turn is consumed by other applications. So, to get the full picture of developing an application, we need to look at it not from one but from two perspectives: application and enterprise. Figure 3-1 illustrates a nonexhaustive set of issues we need to consider, and as you can see, there is a lot to consider. It should be noted that perspectives are interdependent: what can
and can’t be done from an application perspective impacts what is possible from an enterprise perspective, and, alternatively, what can and can’t be done from an enterprise perspective impacts what is possible from an application perspective.
39
40 C H A P T E R 3 ■ C O D E D E V E L O P M E N T
Figure 3-1. Perspectives of code development
We now continue our code discussion by examining two commonly used application development methods: top-down and bottom-up.
Application Development Methods
There are two methods for developing application code: top-down and bottom-up. Each method offers a different development perspective, and determining which is most appropriate is a case-by-case or application-by-application decision. It may be easier to develop a particular application one way but develop another application with a different method.
C H A P T E R 3 ■ C O D E D E V E L O P M E N T |
41 |
Essentially, the difference between the two methods is that the top-down method iterates development by starting with the big picture of the domain (the top) and works downward by decomposing the domain into assemblies, namespaces, and classes (the bottom). In contrast, a bottom-up method, which is also an iterative process, starts at the class level (the bottom) and works upward to the top, by composing classes, namespaces, and assemblies. Historically, object-oriented design and development theorists have advocated decomposing a complex domain into manageable units, which is a top-down method. However, many pragmatists have since recognized that there are times when starting with a vague abstraction is counterproductive and a more tangible approach (i.e., starting by developing classes) is preferred.
■Tip Two books that are most useful in understanding object-oriented development are (1) Object-Oriented Analysis and Design with Applications, by Grady Booch (Addison-Wesley, 1994), which gives excellent coverage of the theory of object-oriented analysis and design, and (2) Expert C# Business Objects, by Rockford Lhotka (Apress 2003), which gives comprehensive and clear coverage of the applied aspects of objectoriented design and development.
Top-Down Method
A top-down development method is one of two commonly used approaches to develop an application (the other is the bottom-up method).
What
An application is developed as an iterative decomposition of the domain. The process starts with a high-level abstraction (clouds) and works downward to implementation (code).
Where
A top-down method is used in developing domain or enterprise applications.
Why
The top-down approach is commonly used because it follows a traditional object-oriented design, which advocates that complexity is best understood by starting with an abstraction and decomposing it into smaller units. However, although that approach usually works, there are times when working with an abstraction is problematic and it is more productive to start with the basics and work upward (bottom-up method).
How
The domain is viewed from the big picture, and application development is commenced by developing an architecture, then working through assemblies and namespaces to develop classes. The architecture is prepared before code is developed, and it may be tweaked as code development progresses.
42 C H A P T E R 3 ■ C O D E D E V E L O P M E N T
The Standard: Top-Down Method
The standard acknowledges the use of the top-down development method to develop a solution by developing an application by decomposing a domain problem.
Bottom-Up Method
A bottom-up development method is one of two commonly used approaches to developing an application (the other is the top-down method).
What
An application is developed as an iterative composition of the domain.
Where
A bottom-up method is used in developing domain or enterprise applications.
Why
The bottom-up approach is used because it starts off more tangibly by developing small units of functionality (classes) and incrementally composes the complexity from class level to assembly level.
How
The domain is viewed from a detailed picture, and application development is commenced by developing classes and working upward to develop the structure (e.g., namespaces and assemblies). The architecture is prepared as part of code development; it evolves as a consequence of assembling the solution.
The Standard: Bottom-Up Method
The standard acknowledges the use of the bottom-up development method to develop an application by composing a domain solution.
Application Architecture
Whether a top-down or bottom-up development method is used, an application is developed with an architecture: it may be prepared before code development (top-down) or it may evolve during development (bottom-up).
What
An application architecture is a design or structural framework in which to organize application functionality. An application may reuse an application framework or template for its
C H A P T E R 3 ■ C O D E D E V E L O P M E N T |
43 |
architecture (see the section Application Framework Solution in Chapter 7, Design Development) or develop it from scratch.
Where
An application architecture is used for all nontrivial application development. It is commonly used where there is a need to structure development across layers or tiers of functionality (e.g., a three-tier application architecture).
Why
By using an application architecture, the application is more able to accommodate volatility within the domain and the enterprise.
How
Regardless of which development method is used, an application architecture has to be pieced together. Figure 3-2 illustrates a nonexhaustive list of elements that are considered as part of an application architecture.
Figure 3-2. Application architecture
There is no definitive process for assembling an application architecture; however, the following is a guide.
•Structure: Decompose the domain through assemblies, then namespaces and classes.
•Object Collaboration: Determine how objects are expected to collaborate within the architecture. An application functions through object collaboration, so objects that need to collaborate are more efficient if they are in the same namespace or assembly.
•Data: Consider the most efficient way to organize an object’s access to data. What is at first logical from an application perspective may have to be modified to be acceptable from an enterprise perspective (e.g., to optimize a data load–balancing algorithm).
•Enterprise Integration: Determine how objects will interrelate with the enterprise— determine whether they will consume and/or publish services through application and enterprise integration layer.
44C H A P T E R 3 ■ C O D E D E V E L O P M E N T
•Deployment: Consider the most appropriate deployment architecture of assemblies, to maximize efficiency, visibility, and maintainability.
•Volatility: Identify the likely sources of change, and design the architecture to minimize the impact of volatility—for example, by separating that volatility from nonvolatile functionality.
The previous guide is not exhaustive, and each item is not considered in isolation: often when one item (for example, data) is considered, other, related items (e.g., classes, object collaboration, and deployment) are considered in concert as the architecture is tweaked.
The Standard: Application Architecture
The standard acknowledges the use of application architecture, observing that an application developed using architecture is more likely to be efficient and maintainable, as well as better equipped to accommodate volatility within the domain and the enterprise, than is an application that is not developed using architecture.
Class Development
The functionality in an application comes from the collaboration of concrete classes (objects), so class development plays a key role in the success of the application.
What
Class development includes identifying a class’s role; determining the interface that it will expose to collaborate with other concrete classes; identifying how it will acquire that interface (internal functionality or through an association—composition and/or inheritance); and building functionality using algorithms and so forth.
Where
Class development occurs within the application architecture and throughout the life cycle of the application.
Why
The class is the application—so class development is fundamental to the success of the application.
How
There is no standard way to develop classes. However, Figure 3-3 illustrates a number of the aspects that need to be considered.
C H A P T E R 3 ■ C O D E D E V E L O P M E N T |
45 |
Figure 3-3. Developing Application classes
The classes are developed within namespaces within the application framework. There are many elements that need to be considered when developing classes, including the following:
•Build a Class as a Collaborative Object: Although a class is a template of an object, it is not until the class is instantiated and collaborating with other objects that the effectiveness and efficiency of the class is determined.
•Design Patterns: Consider whether design patterns will be of assistance in developing creational, structural, or behavioral collaborative ability.
•Build an Interface: Determine what functionality each class will expose for other classes to call—in other words, what collaborative role will a given concrete class play in the application?
•Inheritance: Consider the role of class and interface inheritance in evolving an interface and functionality of a class.
•Composition/Containment: Consider the role of composition or containment in evolving an interface and functionality of a class.
•Encapsulation/Accessibility: Consider the most appropriate way to encapsulate accessibility to functionality through modifiers.
•State: Identify how classes will manage state.