C# and VB Object-Oriented Programming in Visual Studio .NET

III. Tools That Can Help

By jumping on the OOP bandwagon, VB.NET provides us with a considerable number of new features. C# is certainly a language that will get a lot of attention. But OOP doesn't come for free. Modeling tools are needed to help document the software requirements and model the classes and interactions. Tools such as Microsoft Visio for Enterprise Architects, Rational Rose, and the new Rational XDE that integrates with Visual Studio.NET will certainly come in handy—f not prove necessary—to provide a solid foundation for application development and documentation. You also can use their basic code generation features to synchronize your model with your code. Other software vendors provide specialized solutions that allow for the generation of greater amounts of code, be it business logic code or the architecture code of an application.

IV. Applying Best Practices

Design patterns are what could be called the body of knowledge for object-oriented software development. They give you a standard way in which to attack common problems that occur in Object-Oriented Designs (OOD) and their implementations.

Design patterns aren't invented; rather, they are found. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, the so-named "Gang of Four (GOF)," have put together and documented more than 20 design patterns. Of course, there are many more patterns available. Every time a problem is solved, and the solution is documented appropriately, that solution has the potential of becoming a pattern if it's adopted as the way to resolve the problem.

To name a few design patterns, there are Singleton, Facade, Abstract Factory, Flyweight, Adapter, and so forth. These patterns are fully documented on the Internet and in some very good books. To demonstrate the usefulness of these patterns, let's take a look at the Singleton pattern and how to implement it.

The Singleton pattern is very simple. Its purpose is twofold: to assure that within the lifetime of a running application, a class will have a maximum of one instance at a time available and to provide a global point of access to it.

Sometimes it's necessary to implement the Singleton pattern. For example, when an application has an event log, there should be a single log, not two or three. Another example is a printing system. Although there are many printers attached to the print spooler, there can only be one spooler available.

As you can see, there are many ways to implement the same design pattern. Here's an example of the simplest implementation. A more complex implementation might include separating the Singleton logic from the object's logic.

Public Class EventLogger
       Protected Shared uniqueInstance
As EventLogger
       Protected events As ArrayList

       Protected Sub New()
              events = New ArrayList()
       End Sub

       Public Shared Function Instance() As
EventLogger
              If uniqueInstance Is Nothing
Then uniqueInstance = New EventLogger()
       Return uniqueInstance
       End Function

       Public Sub LogEvent(ByVal eventToLog
As Object)
              events.Add(eventToLog)
      End Sub
End Class

public class EventLogger
{
       static protected EventLogger
uniqueInstance;
       protected ArrayList events;

       protected EventLogger()
       {
              events = new ArrayList();
       }

       static public EventLogger Instance()
       {

              if (uniqueInstance == null)
                     uniqueInstance = new
EventLogger();

              return uniqueInstance;
       }

       public void LogEvent(object
eventToLog)
       {

              events.Add(eventToLog);
       }
}

V. The Next Big Thing

The next big thing that will certainly change the way we develop applications is Model Driven Architecture (MDA). This initiative, led by the OMG, defines a way to separate business logic from implementation. Companies that adopt this paradigm will shield themselves from the problems related to changes in technology. An application written for DAO, RDO or ADO that you want to port to ADO.NET today requires meticulous find and replace everywhere in the code where the old technologies were used. In concert with an MDA capable tool, OOP will prove even more powerful by providing loose coupling at the application design stage.

OOP is definitely here to stay. As the examples demonstrate, it's a programming paradigm that emulates the human way of seeing things. Now that VB.NET fully supports OOP, the development abstraction goes one level higher. And if you haven't looked at C# yet, do so, and you'll see that it's not too different from what you're used to.

About the Authors

Yan Locas is a senior technical consultant working at Codagen Technologies Corp. (www.codagen.com), the maker of Codagen Architect, a patent-pending MDA-capable software development tool that reduces development lifecycles, speeds time-to-market, and minimizes testing and re-coding efforts. He has occupied technical and management positions and has been working in the IT industry for the last 9 years. Yan is an MCSD, MCSE, MCT, and CLP. He can be reached at ylocas@codagen.com.

Erik Renaud is a senior software engineer for Codagen Technologies Corp. He is currently working on MDA-compliant code-generation techniques for the Microsoft .NET framework. Erik has also a vast C++ experience in interconnecting disparate systems and designing multi-tier distributed systems used for the leisure and transport industry. He occasionally gives OOP training and can be contacted at erenaud@codagen.com.