A class library is a collection of classes. Unlike an application, it can't be executedeither in a console prompt or as a Windows applicationit can only provide services, on request, to other applications.
Why would a project include a class library, a collection of classes? After all, you can just put all your classes in your application. For small projects, you might not need a class library, but large projects benefit from the organization that it offers. If you have performed a full object-oriented design on a complex system, you can have hundreds or thousands of classes. The same concepts of encapsulation and abstraction that you used to gather 5 or 10 functions ( methods ) and variables (attributes) into classes should drive you to gather 10 or 20 classes into a class library.
Often it's intuitive, even obvious, that certain corners of your design will be a module or a layer. Perhaps you have a number of classes that deal with a particular piece of hardware, or that communicate with another server over the network, or that interact with the database. When you gather these into a single layer, you encapsulate everything about the hardware or the other server or the database and you insulate the rest of the system from that detail.
When you're reading about design and architecture that involves class libraries, you are likely to come across words like module, package, subsystem, layer or tier . These words have precise meanings to certain peopleunfortunately five different people can have five completely different very precise meanings for the same word. In this chapter I'm going to use them loosely to mean a group of related classes.
One of the really obvious layers in your application is the user interface. By gathering all the classes that ask questions of the user or that handle events from the user into one layer, and refusing to have any user interface code in the other classes in your system, you gain a number of benefits:
If you ever change your user interface, for example by replacing a logo or color scheme because of a corporate change, the number of classes to change will be smaller than if every class in the system was part of the user interface.
In a team environment, you can assign the developer who is best at user interface design to the user interface layer rather than asking every developer to work on part of the user interface.
All the other layers can be used to support another application with a different interface (a service, a console application, a Windows application, a Web service, and so on) without any changes.
If you split your application into multiple modules or subsystems, almost invariably one will be the user interface and all the others will be class libraries.
SHOP TALK: LAYERS IN REAL LIFE
One of the first remote projects I undertook showed me how dramatic the results of layering could be. We were developing software that simulated a chemical plant or oil refinery. Many of the developers, including me, were high-level chemical engineers , not user interface experts or graphic artists . I was working on classes in the business layer that simulated the behavior of a pump, a pipe segment, or other pieces of a chemical plant. My classes had no user interface component: They had methods that the user interface classes could call to pass along requests or information from the user.
As I worked on my code, I linked with a C++ .LIB file that held the compiled version of the user interface. From time to time the client would send me a new version of this .LIB file. One day I recompiled andpresto!the console application I had been testing had become a Windows application. All of my code worked just the same even though a dramatic appearance change had happened throughout the application. Separating your code into layers gives you flexibility, portability, and durability.
The process of developing a layered application becomes simpler when you look for certain "obvious" or popular layers. These include
User interface layer the parts of the application that report information to the user and accept requests and input from the user.
Data layer everything that interacts with the database.
Communications layers any sets of classes that communicate with the hardware or another system.
Business logic any sets of classes that enforce line-of-business rules, such as authorizing purchases, determining prices, tracking absences, calculating marks, and the like. Complex systems can have several modules within the business layer.
No matter what purpose your layer serves, if it can't be executed, it's a class library.