Moving from procedural programming languages such as ASP and Visual Basic to .NET object-oriented languages enables programmers to build systems that are highly extensible and flexible. In the first part I will demonstrate how to isolate business rules to a particular implementation class.
The Scenario
I have built an application that tracks bills for a company. I host the application for the company and perform modifications for a fee. A second company likes the product but adds new business rules in calculating the bill. The second company has requested a modification to the application to meet their business need.
Version 1 - VB Com Object
Public
Class Bill
Public Function calculateBill(ByVal CustomerName As String) As Double
If CustomerName = "CompanyA" Then
calculateBill = totalprice
ElseIf CustomerName = "CompanyB" Then
calculateBill = totalprice + comission
End If
End Function
End Class
The Problem
As the sales person convinces new clients our billing system is the best, and these new clients will inevitably request more changes. The result is that the application will be filled with control logic to perform the special business logic for each customer.
A Possible solution
In this article I will show how to use a design pattern accompanied with inheritance to enable an application to become more flexible. A design pattern is a way to solve common problems from various applications with a standard implementation style. I am implementing a variation of the Factory Pattern. The Factory Pattern allows a requestor to get an object of a base type, but it does not specify which implementation object to create. Therefore the requestor is shielded from the creation of the object.
Version 2 - C# Objects
In our example above, the requestor was some user interface that will display the bill. The Bill class provides the base of implementation. In this example, I will create an intermediate class that the user interface will use to request the bill object. Based on which type of Company the user represents they will get an implementation class that is appropriate.
Sample Code:
using
System;
using myBusinessObjects;
namespace ConsoleSample
{
class MySample
{
[STAThread]
static void Main(string[] args)
{
// test harness for company B
string currentCompany = "CompanyB";
//address new company's need
CompanyBBill companyBBill = (CompanyBBill)BillFactory.getBill("CompanyB");
companyBBill.Commission = 9.2;
Console.WriteLine(companyBBill.calculateBill().ToString
());
/*
// test harness for company Astring currentCompany = "CompanyA";
//regular implementation Bill companyABill = BillFactory.getBill("CompanyA");
Console.WriteLine(companyABill.calculateBill().ToString());
*/
}
}
}
namespace myBusinessObjects
{
class BillFactory
{
public static Bill getBill(String CompanyName)
{
Bill myBill;
if (CompanyName == "CompanyB")
myBill = new CompanyBBill();
else
myBill = new Bill();
return myBill;
}
}
class Bill
{
protected double CostofProduct = 10.25;
protected int NumberOfProducts = 3;
public virtual double calculateBill()
{
return CostofProduct * NumberOfProducts;
}
public virtual double getDiscountPrice()
{
return CostofProduct * 0.8;
}
}
//each derived special case class could be generalized and compiled
//as needed then cached. will show in future article
class CompanyBBill : Bill
{
//the extended data items could be generaicized,
//I will show this in a future article
public double Commission;
public override double calculateBill()
{
// calls Bill.calculateBill and then adds commission
return base.calculateBill() + Commission;
//or you can provide other custom implementation
//return NumberOfProducts * CostofProduct + Commission *
NumberOfProducts;
}
}
}
Explanation
The Bill class provides the basic design of the system. Most customers should want the functionality of the base Bill class. New customers who want additional functionality and class members can request objects that are derived from the base Bill class. In the sample above, the base class Bill calculates the bill by (# of products * price of Products). When a customer wants to modify this functionality, I create a new implementation class CompanyBBill that inherits all of the functionality of the Bill class. I inherited from Bill instead of creating a new class so that CompanyBBill will maintain all of the functionality of the original Bill. Thus, I do not have to rewrite getDiscountPrice().
The BillFactory class provides an intermediate between the client and the implementation class. If a customer requests a change you could make a new implementation class and alter the factory for the base class. If this technique was applied across all business objects, a customer could request functionality that changed in only one or multiple business objects.
Applying to the Real World
In future articles I will demonstrate how to expand this concept.
1) Building a user interface of dynamically loaded Web User Controls from a factory. The same patterns could be applied so that the user interface adapts to each customer needs and changes.
2) Have each Business Object that is changeable derive from a base class. This base class will have a collection of generic data objects driven by a database. Coding specific implementations into class files. The class files can be compiled at first run and cached on the server for future use. The class files will add functionality by overriding functionality in a base class and potentially accessing the generic data objects above. Once this framework is established you can do the following:
a) Release customer functionality with zero regression testing for other customers.
b) Publish your application and limited object model to customers and have their programmers alter functionality without having access to your base code. You can even charge for object models with different levels of detail!!
c) Publish new versions of the application without affecting the base build.
d) Remove functionality of old customers with zero impact.