HANDLING NAME CONFLICTS

In large applications, it is fairly common to have name collisions. One developer might create an Employee class, while another makes a function named Employee that returns the employee ID for a particular person’s name. Or two developers might build different Employee classes that have different properties and different purposes. When multiple items have the same name, this is called a namespace collision or namespace pollution.

These sorts of name conflicts are most common when programmers are not working closely together. For example, different developers working on the payroll and human resources systems might both define Employee classes with slightly different purposes.

Namespaces enable you to classify and distinguish among programming entities that have the same name. For example, you might build the payroll system in the Payroll namespace and the human resources system in the HumanResources namespace. Then, the two Employee classes would have the fully qualified names Payroll.Employee and HumanResources.Employee, so they could coexist peacefully and the program could tell them apart.

The following code shows how an application would declare objects of these two types:

Dim payroll_emp As Payroll.Employee
Dim hr_emp As HumanResources.Employee

Namespaces can contain other namespaces, so you can build a hierarchical structure that groups different entities. You can divide the Payroll namespace into pieces to give developers working on that project some isolation from each other.

Namespaces can be confusing at first, but they are really fairly simple. They just break up the code into manageable pieces so that you can group parts of the program and tell different parts from each other.

This chapter describes namespaces. It explains how to use namespaces to categorize programming items and how to use them to select the right versions of items with the same name.