design and implementation question

[vcllvc]

I am running into a problem that I have a CreditCard class, which has a property called "CardType". When I create a "VISA" credit card object, I set the CardType property to "VISA" which is a string.

Another approach is define a enumerate type of credit card type, so I can avoid any typo error.

But my problem is everytime I add a new credit card company, I need to edit the code and recompile for the above two approaches.

I wonder is there any way of design or implementation can avoid the above clumsy process. Let say I can just change an XML file node and reload the file.

 

[stefanwagner]

Depending on your preferred language, the features to solve this vary.
And without knowledge how a visa-card behaves/ is treatened differently from a eurocard i.e., the way to go is different.

If only some values differ - let's say a displayed name, and an emergency phone-number, you might store pairs in a configuration-file.

If the differnces are more sophisticated, you would use a Interface ICreditCard in Java, and let VisaCard implement ICreditCard.
For a new type of card that one would implement that interface too.

The main programcode would only use the Inteface:

List <ICreditCard> licc = new ArrayList <ICreditCard> ();
ICreditCard icc1 = new VisaCard (foo, bar);
ICreditCard icc2 = new EuroCard (foo, bar);
...
licc.add (icc1);
licc.add (icc2);
...
CreditCardValidator ccv = new CreditCardValidator (licc);
ccv.validate ();
...

// CreditCardValidator
validate ()
{
        for (ICreditCard icc: licc)
        {
                icc.validate ();
        }
}

Now you can generate new types of CreditCards withou recompiling the Validator.
To get rid of the hardcoded 'new XyCard (...)' you may use reflection.
Have a look at the abstract-factory-pattern.
For java see as example the JDBC-driver.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[vcllvc]

So does it make any different if I implement the credit card in an abstract base class, instead of using interface?

Thanks in advance.

 

[stefanwagner]

You may use booth.
In an abstract base-class, you may implement some code, which is shared by all subclasses, but if you need to change the implementation in the subclass, you might break the functionality of derived classes.

If you develop against the interface, you may create new Implementors, which don't use the abstract base at all, which leads to more independency.

seeking a job as java-programmer in Berlin:

http://home.arcor.de/hirnstrom/bewerbung

 

[SundialServices]

To my way of thinking, a CreditCard is a thing which holds a number, an expiration and other properties. I can give a number to it and expect an exception to occur if the number is incorrectly formatted. I can use it in a transaction. The object probably also has an interface to the credit-card processing service.

What varies, from one card to another, is not "what they do," but "exactly how they do it." So the different types of credit cards are natural subclasses.

 

[BobRodes]

<abstract base class, instead of using interface

A quick point: in practical usage, the term "abstract class" generally describes a class wherein some but not all of the functionality is implemented. However, a class with no implementation at all (an interface) is still abstract.

So, an interface IS an abstract class, really.

For a lively discussion on this topic, see thread678-1157063

HTH

Bob

 

[cpjust]

Bob, I've seen you always use "<" when quoting people. If it's the post just above you it might be easy to find, but in this case I couldn't see who you were quoting until I did a search.
If you type:
[ignore]

abstract base class, instead of using interface

[/ignore]
You'd get the following, which is much more readable:

abstract base class, instead of using interface

 

[BobRodes]

Yeah, I know, but it takes up a lot of space, and that blue color is...well...however, I'll take that under advisement.

Thx

Bob