|
|
|
|
Concrete vs. Abstract ClassesAs you learn to construct class libraries, you will discover pretty quickly that you can often 'push' a number of common attributes and/or methods up the inheritance hierarchy. For example, the Employee class would typically be used to contain the attributes and methods that are common to all employees, such as name, employee id, telephone number, etc. However, you might decide that Employee isn't sufficiently concrete enough to represent a real employee. In practice, an employee usually has a specific role in an organization -- an employee is always a Secretary, Programmer, Manager, Janitor, President, CEO, FinancialAnalyst or whatever. Instantiating an Employee might not actually make sense; it's not sufficiently concrete -- it's too abstract; we would need to know what kind of Employee we're talking about. But the class Employee is still very useful! It allows you to distill out the essence of all employees -- those attributes and behaviors that all (or perhaps most) employees share. When you do pull shared attributes and behaviors into a class such as this, it can make the design of the subclasses of that class much cleaner, and can allow you to reuse code more effectively. A class like this -- one that you never expect to instantiate (create instances of) alone; one that is considered incomplete -- is called an abstract class.
|
|
This page was last modified on 02 October, 2007 |