Fog Creek Software
Discussion Board

OOP Question

I'm sure to some of you this will seem like a rather silly question, but I'm trying to move up from VB to C# and I have an Object Oriented Programming question.

I am designing an financial application involving credit card charges.  For this example, let's say that each credit card(Visa, Mastercard, Discover, etc...) class all have the same methods (Sale, Refund, etc...) but completely different implementations.  One might expect information in Spanish, one Italian, one Mandarin Chinese, or whatever.

Now the question.  The books I have read seem to indicate something like this would be done using inheritance of an abstract base class, however it seems to me that an interface would work as well since none of the code will be shared between the classes.  Is there a "right" way to do this?  Or am I over-analyzing the problem and should just pick one and go with it?

Monday, December 31, 2001

Well, two things. First: If you spend so much time thinking about it and none doing it, what's the point? Eventually you have to pick one ;)

Second, I usually divide things up in whatever way seems logical. Think about what you may have to do so you don't do any major misdesign stuff, but that shouldn't be too difficult. You are correct: if these are the only functions you have, then an interface would work as well as inheritance. However, there may be some sharing after all. For instance, do you need to maintain a history for each card? What about information? Do you store the card's CC# and exp. date? What if you will in the future? It's easier to add functionality to a base class than to move from interfaces to base classes.

Just a few thoughts. Also, I think you're dwelling on a triviality: interfaces and classes are basically, to me, a semantic issue: Not really significant in terms of the overall structure. However, OTOH, a choice between a hash and a linked list, or whatever, or a decision to use C++ STL strings vs. C-strings impacts the program much more.

Mike Swieton
Monday, December 31, 2001

Thanks for the input.  I was thinking it was rather trivial, but as I am just learning I wanted to make sure I didn't end up going down the wrong road.  Thanks again.

Monday, December 31, 2001

I think most of your code IS going to be shared between your credit cards. Even if a credit card type does contain country information, should it really dictate a language preference? I don't know enough about credit card processing to answer that question. Your credit cards may even be so similar that it isn't worth the added complexity to create separate classes for each card. Subclassing a CMammal into CDog and CCat doesn't make a lot of sense out of an OOP textbook if you can implement its Speak() method with just one class and a switch statement.

Martin Fowler recently wrote an article about writing explicit instead of generic code, which appealed to me a lot.

If your language options are user interface languages (and not related to credit card processing), instead centralize your application's strings in one or more units, assign an identifier to each string and use that identifier to retrieve the string in the user's preferred language. A credit card class sounds like a "business layer" class, which should not contain any user interface elements, including text that the user sees. This is one design idea that essentially all programmers can agree on.

As for over-analyzing, unless you write your code the XP way with unit tests for everything, don't start coding until you run out of constructive thoughts (but then start.) If you do write units tests, you can start coding earlier and refactor with fewer headaches when you realize that the architecture is broken.

There is no one right way to do anything, but every time you write a line of code, you're making a choice between what you write and what you could have written instead, and you should strive to make it a conscious one.

Johannes Bjerregaard
Monday, December 31, 2001

When I first moved to OOP I found the best way to decide on a design is to first hack a solution using whatever seems immediately logical, be it functional or OOP.  From there you've a sense of the whole problem and it's far quicker to "encounter" design issues then to think them up, atleast in regards to implementation.

Once you have something that works (in a hack sort of way) you reconcider the problem and refactor the hack into a clean-er design.  Atleast this has worked best in my experience with regards to designs of the size this one is.

Probably get some flack for that opinion/suggestion though ;)


Lucas Goodwin
Saturday, January 05, 2002

*  Recent Topics

*  Fog Creek Home