Praise for C# 2.0: Practical Guide for Programmers 2005 phần 2 pot

■ 2.2 Access Modifiers 13

visible within the class itself. The visibility of its protected methods and data fields is

restricted to the class itself and to its subclasses. Internal methods and data fields are

only visible among classes that are part of the same compiled unit. And finally, methods

or data fields that are protected internal have the combined visibility of internal and

protected members. By default, if no modifier is specified for a method or data field then

accessibility is private.

On the other hand, if a class is internal, the semantics of the access modifiers is

identical to those of a public class except for one key restriction: Access is limited to those

classes within the same compiled unit. Otherwise, no method or data field of an internal

class is directly accessible among classes that are compiled separately.

When used in conjunction with the data fields and methods of a class, access mod￾ifiers dually support the notions of information hiding and encapsulation. By making

data fields private, data contained in an object is hidden from other objects in the system.

Hence, data integrity is preserved. Furthermore, by making methods public, access and

modification to data is controlled via the methods of the class. Hence, no direct external

access by other objects ensures that data behavior is also preserved.

As a rule of thumb, good class design declares data fields as private and methods Tip

as public. It is also suggested that methods to retrieve data members (called getters) and

methods to change data members (called setters) be public and protected, respectively.

Making a setter method public has the same effect as making the data field public, which

violates the notion of information hiding. This violation, however, is unavoidable for com￾ponents, which, by definition, are objects that must be capable of updating their data fields

at runtime. For example, a user may need to update the lastName of an Id object to reflect

a change in marital status.

Sometimes, developers believe that going through a method to update a data field is

inefficient. In other words, why not make the data field protected instead of the method?

The main justification in defining a protected method is twofold:

■ A protected method, unlike a data field, can be overridden. This is very important if

a change of behavior is required in subclasses.

■ A protected method is normally generated inline as a macro and therefore eliminates

the overhead of the call/return.

It is also important to remember that, in software development, it is always possible to add

public methods, but impossible to remove them or make them private once they have been

used by the client. Assuming that the class Id instantiates components, we add public

modifiers for all methods and private modifiers for all data fields, as shown:

public class Id {

// Methods (behavior)

public string GetFirstName() { return firstName; }

public string GetLastName() { return lastName; }

public void SetFirstName(string value) { firstName = value; }

public void SetLastName(string value) { lastName = value; }

14 Chapter 2: Classes, Objects, and Namespaces ■

// Fields (data)

private string firstName = "<first name>";

private string lastName = "<last name>";

}

2.3 Namespaces

A namespace is a mechanism used to organize classes (even namespaces) into groups

and to control the proliferation of names. This control is absolutely necessary to avoid any

future name conflicts with the integration (or reuse) of other classes that may be included

in an application.

If a class is not explicitly included in a namespace, then it is placed into the default

namespace, otherwise known as the global namespace. Using the default namespace,

however, is not a good software engineering strategy. It demonstrates a lack of program

design and makes code reuse more difficult. Therefore, when developing large applica￾tions, the use of namespaces is indispensable for the complete definition of classes.

2.3.1 Declaring Namespaces

The following example presents a namespace declaration for the Presentation subsys￾tem in Figure 1.2 that includes two public classes, which define the TUI and the GUI,

respectively.

namespace Presentation {

public class TUI { ... }

public class GUI { ... }

}

This Presentation namespace can also be nested into a Project namespace containing all

three distinct subsystems as shown here:

namespace Project {

namespace Presentation {

public class TUI { ... }

public class GUI { ... }

}

namespace Business {

// Domain classes ...

}

namespace Data {

public class Files { ... }

public class Database { ... }

}

}