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

Principles - 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

There are some principles of Object Oriented design that we must discuss before delving into this particular design. Many of you may be familiar with the notion of developing "Modular" or "Reusable" software. You may also be completely unaware of approaching a problem requiring this type of design... or even worse, you may not know how to determine when a Reusable Object Oriented design is appropriate.

I can argue the point at length and, quite effectively that, for the vast majority of web projects, an Object Oriented design is not needed. More often than not, the cost of designing a highly reusable OOP solution for a web project far outweighs the benefits. This has a lot to do with the technologies used on the web and how implementation of any given design can vary wildly between platforms and software versions, but it has even more to do with the simple fact that most dynamic websites provide nothing more than a rudimentary frontend to a database. There are, however, many situations such as the one we are examining in this article, that require an Object Oriented approach. Here are some considerations to keep in mind when you are planning a new web project with a linear, non OOP approach:

  1. How heavily can we expect this system to be modified to meet future customer demands on their website?

  2. How likely is it that future developers will be required to work on your code base?

  3. How much refactoring will be involved if the customer wants to add a new section or feature to the website?

If the answer to any of these questions is "A Lot" or "Very Likely", then an Object Oriented Approach would in all likelihood be valuable. The hard fact of web development is that these situations do not describe most websites. Given that, let's weigh our objective against these three considerations.

How heavily can we expect this system to be modified to meet future customer demands on their website?

One of the principle requirements of this system is that it allow the addition of an arbitrary number of Merchant Providers and Transaction Methods. We can expect a high volume of changes to be made to the product in time to accommodate new customers who prefer Merchant Providers that may be unsupported in our product.

How likely is it that future developers will be required to work on your code base?

Again, looking at our first two objectives, we are required to consider that other developers will be working to provide Merchant Providers and Transaction Methods to clients. It is not unlikely that a customer will have an on-staff developer and prefer to have them work on the clock for an unsupported feature rather than paying your company to develop a new module for transaction processing.

How much refactoring will be involved if the customer wants to add a new section or feature to the website?

We want to avoid refactoring as much as possible because we do not want the client to notice changes to our system architecture when it is presented with the need to support a new Merchant Provider. This means that using a non-OOP approach would force us to refactor each time a customer needed a module for an unsupported Merchant or Transaction Method.



 
 
>>> 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: