Developing an Object Oriented Credit Card Transaction Processor - Factory Work

(Page 5 of 6 )

You are probably already wondering why this page is named Factory Work. To satisfy that curiosity, consider what a factory does. Put simply, a factory works under given parameters to produce a desired product. How is this applicable to the problem at hand? Well, we want our ETFTransaction object to be capable of utilizing any Merchant that we provide a class for. To allow this without hard coding the ETFTransaction object, we have to provide an intermediary class, a Factory class, to provide the proper Merchant object to the ETFTransaction object. The purpose of our factory is this: take a parameter object and return the appropriate Merchant object to the ETFTransaction object. Let's look at a definition:

public class ETFPaymentServiceFactory {
protected:
 ETFPaymentServiceFactory();
private:
 ETFPaymentServiceFactory* _instance;
public:
 ETFPaymentServiceFactory* Instance();
 ETFPaymentService* Create(ETFPaymentMethod*);
}

We would extend our ETFTransaction object again:

public class ETFTransaction {
public:
 ETFTransaction(ETFPaymentMethod*);
 bool Execute();
private:
 ETFPaymentMethod* _pm;
 ETFPaymentService* _ps;
}

You will note that the constructor is protected; this is because we do not wish to allow this object to be instantiated more than once. _instance is a reference to the sole instance of this object. Obviously you cannot use this method in PHP, but there are ways. The Instance() method would look something like this:

ETFPaymentServiceFactory* Instance() {
 if (_instance = 0) {
  _instance = new ETFPaymentServiceFactory;
 }
 return _instance;
}

To use the factory, we would have code such as this:

ETFPaymentMethod* pm = new ETFPaymentMethod;
ETFTransaction* trans = new ETFTransaction(pm);

bool Execute:ETFTransaction() {
 ETFPaymentServiceFactory* factory = ETFPaymentServiceFactory::Instance();
 _ps = factory->Create(pm);
}

So now we've outlined how our Transaction object will go about getting a Payment Service object, but we still have not defined an interface for the ETFPaymentService class. Let's do so now:

public class ETFPaymentService {
public:
 ETFPaymentService();
 virtual bool SendRequest();
private:
 ETFPaymentMethod* _pm;
 virtual bool SupportsPaymentMethod();
}

As you can see, this is the abstract class for all Payment Services to inherit from; you would see objects like AuthorizeNet:ETFPaymentService and LinkPoint:ETFPaymentService to handle specific requests. We could simply add a call to _ps->SendRequest() in our Execute:ETFTransaction function to process the ETF. The private method of ETFPaymentService SupportsPaymentMethod() is used internally to check against whatever data registry we have provided to ensure that the PaymentMethod object represents and Payment Method that our Payment Service is capable of handling.

Lastly, we would add a method such as the following to allow retrieval of status information from our ETFTransaction object. We would also want a method to store messages from our Payment Service. The way these messages are represented in XML from the Payment Service are not important to this discussion, because they will be adapted to fit the interface of a generic ETFMessage object.

bool isApproved:ETFTransaction();

public class ETFMessage {
public:
 ETFMessage(int code);
 int GetMessage();
private
 int _code;
 string* _message;
}

And add this to our ETFTransaction class:

public:
 ETFMessage* CurrentMessage();
 bool NextMessage();
private:
 ETFMessage* messages[];

You see a basic Iterator pattern here, which could be expanded if you want. We simply want to provide a standard method of message retrieval to our client.

Now that it is established how our objects will interact, and we have an idea how the objects will receive their parameters, we can briefly discuss client implementation. To review the process involved in using these classes, we have the following steps:

1. Create a structure from our registry representing available Payment Methods and Payment Services.
   
   
2. Once the Method has been selected by the customer using the website, relative to the Service selected by the site administrator, create our Address and Payment Method objects.
   
   
3. Create our Transaction Object.
   
   
4. Call the Execute() method of our Transaction object.
   
   
5. Check the status of our transaction and review any messages.

And... viola! That's it. Now that we have a design, the rest is gravy. Remember that routines and functions will do whatever you want them to do -- it is the design that truly makes a system work.

Next: Conclusion >>
 

More Practices Articles
More By David Fells

Comments On: Developing an Object Oriented Credit Card Transaction Processor

>>> Be the FIRST to comment on this article!