Why Use Class Libraries?

Chapter 10 - Componentization
byJohn Kauffman, Fabio Claudio Ferracchiatiet al.?
Wrox Press ?2002

The language-neutral architecture of .NET has made the creation of class libraries a more useful proposition than ever before - classes written in one .NET language can be used from any other .NET language, without the need for any special considerations. With the language obstacle out of the way, the benefits of using class libraries in (ASP).NET development are broadly the same as the traditional benefits of using classes in single-language development. In this section, we'll enumerate those advantages, and give some suitably themed examples.

Simplified Programming

By putting complex functionality into classes with well-defined programming interfaces, other programmers only have to worry about dealing with those interfaces. To see how this works, consider ADO.NET itself as an example. When we use ADO.NET with SQL Server or Access, we don't have to worry about the intricacies of the Tabular Data Stream or OLE DB. As Microsoft likes to say, "It just works."

You can write your class libraries in the same way. For example, it's quite easy to have one class that manages the details of loading data into collections for processing, and another that performs some checking on any attempted changes to that data before they're written back to the database. Other programmers can then just call your methods for loading, validating, and saving the data, without having to know anything about database programming.

Encapsulation

Encapsulation is the ability of a class to hide its internal data and methods, and to present a carefully designed interface to its users. In this way, only the parts of the class that you want to be accessible are accessible. For example, when we use the Fill() method of a data adapter, we're really asking for the computer to work its way through a result set and put the data into a DataTable object. But to do our job, we don't know or need to know exactly how it does that.

As a further demonstration, imagine we have a class whose objects will represent individual employees. Such a class could include a GetTaxID() method that might look something like this:

    GetTaxID(strEmployeeID As String) As String 

Given this definition, we would expect to provide a strEmployeeID variable as a string, and to get a string back - but we don't know anything else about how it works. There might be a database query, or a message could be sent off to a BizTalk server, but in the end we really don't care. Such processes are hidden from us by the class's programming interface.

A further benefit of encapsulation is that it allows you to present a simple interface to a potentially difficult operation. For example, suppose that we've created an instance of the employee class that we've been talking about, and that it's important for users of this class to be able to get hold of the employee's name. If the employee class has a member field like this:

    Private mGivenName As String 

Then we can expose it to the outside world using a property, like this:

    Public Property GivenName As String      Get        Return mGivenName      End Get      Set(ByVal Value As String)        If Value.Length > 0 Then          mGivenName = Value        Else          Throw New ArgumentException("Given Name cannot be blank.")        End If      End Set    End Property 

The property is a part of the public interface of the class, while the field, being private, is not. Using a property allows us fine control over programmatic access to the value - by not including a 'set' section, for example, we could have made this a read-only value. Also, the property allows us to perform validation when some other code attempts to change its value; this would not have been possible had we just used a public field.

In general, taking advantage of encapsulation in the design of your classes provides the following benefits to you and other users of your class libraries:

  • It offers data hiding. In the above case, the programmer who is using your class cannot directly change mGivenName - they must do it through the property. Data hiding means that you can enforce rules about the data without directly exposing that logic to the class's user. You can also control when and how the value of the given name is updated in its store, be that a database or some other system.

  • It offers the ability to modify or extend the internal code of the class at a later date, without affecting its use through others' applications. In other words, you can add functionality to a class without having to modify the other classes that use the modified class, as long as the original interface continues to be supported.

Reuse

Class libraries promote the reuse of code by allowing different applications with similar needs to reuse a common set of classes. Suppose, for example, that you have three applications that all need to access employee information - one for a phone directory, one for processing insurance claims, and one for tracking helpdesk requests. Each of these applications may need to access different information about the employee - phone number, hire date, or perhaps office location. If our employee class were to expose this information as part of its interface, then each application could use it, rather than having to create its own.

A further advantage of reuse is that classes that get used a lot also tend to get tested a lot. Classes that are well tested mean a boost to the reliability of applications that use them, and represent a time saving for you when you come to test such an application.

Enhanced Sustainability

Sustainability measures the degree to which a class or an application adapts to changes in its environment. These changes could be in the structure or sources of data that the class works with, or in how other classes or applications use it. Highly sustainable applications adapt to changes quickly and with a minimum of effort.

Designing good classes can become something of a balancing act. You want to provide as much information and functionality as is appropriate, knowing that this will promote simplicity and reuse in many projects. However, it's very difficult to anticipate every possible use, so it's hard to know exactly what interfaces you should provide. A good way to cope with this is to expose your information as generically as possible, and then let the consumer transform it into what they need.

For example, suppose that your employee class provides a method that returns the employee's name and phone number formatted into an HTML table row, ready for output in an online telephone directory. That's great for the phone directory application - all it has to do is call your method and display the results - but it's not so great if the application needs to send its output to a WAP-enabled mobile phone. If you're designing for maximum sustainability, your class shouldn't provide such a method as the only way to get the phone number. Rather, it should provide the information in a generic format (say, an XML document) and let the consumer transform that into the desired output form.



Beginning ASP. NET 2.0 and Databases
Beginning ASP.NET 2.0 and Databases (Wrox Beginning Guides)
ISBN: 0471781347
EAN: 2147483647
Year: 2004
Pages: 263

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net