266A P P E N D I X A ■ E N V I R O N M E N T VA R I A B L E S A N D R E M OT E P R OX Y E X A M P L E

11.We now need to point the command box to UK_Client folder, so on the command line key in

cd ..\uk_client

and press Enter. For the client to have an association with the server functionality, it needs to know about the ProxyChiefDesignEngineer—open up Client.cs and note that an instance of ProxyChiefDesignEngineer needs to be created and two of its “knowledge methods” will be called. Presently, there is nothing in the UK_Client folder to help Client.cs access ProxyChiefDesignEngineer. Herein lies the trick: make a copy of ProxyRemoteServer DLL, which is located in the US_Server folder, and place it in the UK_Client folder. We now need to associate Client.cs with the DLL and also compile it into Client.exe. This will all be done at the same time when we enter the following command on the command line:

csc /r:proxyremoteserver.dll client.cs.

You should now have three files in the UK_Client folder: Client.cs,

ProxyRemoteServer.dll, and Client.exe, as shown in Figure A-9.

Figure A-9. UK_Client folder dialog

12.We have now set up both the server and client applications, so you can close the two instances of Windows Explorer that pointed to the respective folders. By the way, although this example is contrived, because we are working on a single PC, it need not be; we need only alter the TCP address in Client.cs from tcp://localhost:1234/ RemoteProxy to whatever address we choose, to allow remote client code to access the

ity permissions, etc.).

13.Now we are about to let the client call the service exposed by the server. Open up a second instance of the command box (see previous instructions). Align the two instances of the command boxes as shown in Figure A-10.

Figure A-10. US_Server and UK_Client dialog

14.We need to start up the service that will allow the UK technical guys to ask some questions. We do this by running server.exe from the command line. Key server.exe onto the command line that is pointed at US_Server. Calling server.exe will start the server application, as shown in Figure A-11.

Figure A-11. Server.exe dialog

List of Standards

This is a list of the standards that are catalogued in the respective chapters of the book.

Code Policy Standards

The following standards are the code policy standards that appear in Chapter 1.

Code Policy

The standard acknowledges that a code policy is an effective and efficient way to successfully manage code development by coordinating development across the enterprise.

Code Management

The standard acknowledges that code is a valuable resource that benefits from management throughout its development and life cycle.

Code Vision

The standard acknowledges that a code vision creates a sense of direction that unites a development team to work toward a shared technical goal.

Code Objective(s)

The standard acknowledges that code objectives are an essential part of the development process because they identify what aspects of the enterprise need to change to realize a code vision.

Code Plan

The standard acknowledges the use of a code plan to identify tasks and allocate resources to progress code from its current state to its future state.

Code Strategy

The standard acknowledges that a code strategy can be used to determine the best way to implement a code plan and achieve a set of code objectives.

Code Development Methodology

The standard acknowledges the use of code development methodologies such as XP and RUP, which are used to maximize the likelihood of developing successful code.

269

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

Peer Review

The standard acknowledges the benefits of peer review: (1) improvement of the quality of code by improving the skills of the developer, (2) knowledge sharing, (3) compliance with code policies, and (4) building team cohesion.

Unit Testing

The standard acknowledges the importance of unit testing, which is used to examine the reliability of calling the methods of an object.

Refactoring

The standard acknowledges that refactoring is a useful tool to transform the internal workings of an application without affecting its external workings.

Enterprise Imperative

The standard acknowledges that developing code with an enterprise imperative improves efficiency by minimizing code duplication and maintenance.

Domain Imperative

The standard acknowledges that a domain imperative is used where a requirement is tightly coupled to a domain or there is insufficient opportunity or incentive to develop it otherwise.

Source Code Control

The standard acknowledges that a source code security control reduces the risks associated with team development.

Obsolescence

The standard acknowledges the benefits of early warning of obsolescence. Notice should be given in a timely manner: it is considered that a notice period of one major version is a minimum.

Code Style

The standard acknowledges the use of a code style to encourage uniformity or consistency in the way that code is written. It improves understandability of code and makes it relatively easy to rotate developers from project to project or from team to team.

Pascal Notation

The standard acknowledges the use of Pascal notation for class, constant, delegate, enum type, enum value, event, event handler, exception, static member variable, interface, method, namespace, and property.

Camel Notation

The standard acknowledges the use of Camel notation for instance member variables and parameters.

Hungarian Notation

The standard acknowledges the debate about the use of Hungarian notation with Web/Windows visual controls and notes it has steadfast and wide community support, thus making its use, for a variable assigned a visual control, optional.

Case Sensitivity

The standard acknowledges that where C# and Visual Basic are supported, for consistency in naming variables, a choice is made between (1) ruling against the use of case sensitivity in C# code; or (2) prefixing variables—in C# and VB code—with an underscore.

Code Structure Standards

The following standards are the code structure standards that appear in Chapter 2.

Assembly

The standard acknowledges that an assembly may be used to partition specialized functionality and to control distribution and accessibility to that functionality. The choices made to structure code impact not only accessibility to code but also the flexibility and maintainability of the code.

Namespace

The standard acknowledges the use of namespaces and embedded namespaces to strategically structure code and to avoid naming conflicts.

Interface Type

The standard acknowledges the use of namespaces and embedded namespaces to strategically structure code and to avoid naming conflicts.

struct Type

The standard acknowledges a struct type may be used as a lightweight alternative to a class to structure code and leverage interface inheritance in situations where memory allocation is scarce or class-inheritance and referencing are not required.

Class Type

The standard acknowledges the use of a class type where there is a requirement to support class-inheritance or reference semantics and the overhead of a reference type is not an issue.

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

The standard acknowledges the use of generics to reduce overhead and increase type flexibility while retaining the protection of type safety.

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

Code Development Standards

The following standards are the code development standards that appear in Chapter 3.

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

The standard acknowledges the use of the bottom-up development method to develop an application by composing a domain solution.

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 standard acknowledges that class development is complex and is an iterative process in which many elements have to be considered to build the most appropriate concrete classes, including interface, encapsulation accessibility, functionality, design patterns, inheritance, containment, and state.

Composition

The standard acknowledges the flexibility of composition in building a class interface and that it is favored over inheritance.

Class Inheritance

The standard acknowledges the use of class inheritance and notes that it is used to strategically and progressively extend and reuse design and functionality. It cautions that inappropriate base type selection is a common cause of reengineering.

Interface Inheritance

The standard acknowledges the use of interface inheritance as a versatile means to strategically implement an interface through using multiple interface inheritance, as required.

Overriding

The standard acknowledges the use of overriding to specialize generic functionality.

Overloading

The standard acknowledges the use of overloading as a low-risk way to vary or extend functionality, where the overloaded methods implement similar functionality using different types and numbers of parameters.

abstract Modifier

The standard acknowledges that the role of an abstract class is to contain generalized functionality or an interface and that the abstract method is used to defer implementation to a subclass.

sealed Modifier

The standard acknowledges the use of sealed to indicate that it is not logical or permissible to extend a class.

new Modifier

The standard acknowledges the use of new modifier to hide a derived method or delegate.

private Modifier

The standard acknowledges the use of the private modifier where there is a requirement to limit accessibility within a given class. Note that a class field should be modified private and its value accessed through a class property, to comply with encapsulation.

protected Modifier

The standard acknowledges the use of the protected modifier where there is a requirement to limit accessibility to a class hierarchy.

internal Modifier

The standard acknowledges the use of the internal modifier where there is a requirement to limit accessibility to other classes in the same program or assembly.

protected internal Modifier

The standard acknowledges the use of the protected internal modifier where there is a requirement to limit accessibility to a class, a class(es) derived from that class, or other classes in the same assembly.

public Modifier

The standard acknowledges the use of the public modifier where there is a requirement not to limit accessibility to functionality by defining and publishing an interface against which client code can collaborate.

static Modifier

The standard acknowledges the use of static to differentiate a class member from an object member and also to leverage the ability to access class functionality without the overhead of instantiation.

Attribute

The standard acknowledges the use of Attribute, which may be used to enrich an entity with metadata that may be accessed programmatically, at runtime.