Home arrow Practices arrow Page 3 - Developing an Object Oriented Credit Card Transaction Processor

Approaching the Problem - Practices

This article will walk readers through the process of outlining a flexible Object Oriented design that will facilitate adding Merchant Services and Payment Methods in the future without affecting the client code.

TABLE OF CONTENTS:
  1. Developing an Object Oriented Credit Card Transaction Processor
  2. Principles
  3. Approaching the Problem
  4. Digging In
  5. Factory Work
  6. Conclusion
By: David Fells
Rating: starstarstarstarstar / 25
September 21, 2004

print this article
SEARCH DEV SHED

TOOLS YOU CAN USE

advertisement

A key concept that you will see me use again and again is that the client should not know about implementation. What does that mean? For example, let's define the following class:

public class EFTProcessor {
 CCPaymentService();
 
public:
 bool Execute();

private:
 EFT* SendTransaction(EFT*);
 string _paymentMethod;
 string _merchantService;
}

What we have defined is a class with one public method: Execute(). It has a private method called SendTransaction that Execute will call. It requires some values, _paymentMethod and _merchantService, that could be passed into the constructor or perhaps they were a component of our EFT datatype (which we have not yet defined). The point to this example is this: no matter what we do with SendTransaction and the EFT data type, the client can always call EFTProcessor::Execute and always get a boolean response indicating success or failure. Do not get too attached to this class, as it is only an example and will not be seen again.

The concept illustrated in the class example that we just looked at leads us to the next big concept that you will see me use: Design to an Interface, not an Implementation. This is a big one. It says that we should approach our design from the standpoint of how our objects interact, and more importantly, how our client will use them, rather than from the standpoint of how to write a specific routine. Approaching design in this fashion should lead to Loose Coupling of our design and implementation, meaning that the way in which our client interacts with our objects should be able to vary independently of how our objects complete the tasks that the client requests. Those of you who are familiar with Object Oriented Programming techniques understand that one of the purposes of this type of design, from a coding standpoint, is to facilitate polymorphism, meaning it facilitates replacing objects of one type with objects of another type transparently to the other objects that are interacting with it.



 
 
>>> More Practices Articles          >>> More By David Fells
 

blog comments powered by Disqus
escort Bursa Bursa escort Antalya eskort
   

PRACTICES ARTICLES

- Calculating Development Project Costs
- More Techniques for Finding Things
- Finding Things
- Finishing the System`s Outlines
- The System in So Many Words
- Basic Data Types and Calculations
- What`s the Address? Pointers
- Design with ArgoUML
- Pragmatic Guidelines: Diagrams That Work
- Five-Step UML: OOAD for Short Attention Span...
- Five-Step UML: OOAD for Short Attention Span...
- Introducing UML: Object-Oriented Analysis an...
- Class and Object Diagrams
- Class Relationships
- Classes

Developer Shed Affiliates

 


Dev Shed Tutorial Topics: