Building class

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

In the system I am working on, there are 3 credit cards: Visa, MasterCard and
AmericanExpress. On the database side I have one table: credit_card
CREATE TABLE credit_card
( credit_card_id int not null PRIMARY KEY,
credit_card_code varchar(30) not null,
description varchar(255) null )

Now I am building classes and i can do it in 2 ways:

* Build a class "CreditCard".
public class CreditCard
{
private int _creditCardId;
private string _creditCardCode;
private string _description;
}

* Build a class "CreditCard" and then build 3 classes "Visa", "MasterCard"
and "AmericanExpress" all inherited from "CreditCard".
public class CreditCard
{
private int _creditCardId;
private string _creditCardCode;
private string _description;
}
public class Visa : CreditCard
{
}
public class MasterCard : CreditCard
{
}
public class AmericanExpress : CreditCard
{
}


Which way is better and why?

Thanks
 
Hello Rizwan,

The second case is preferable, because u have the common data/logic for all
you classes which can be moved to the base class

Read about inheritance there http://en.wikipedia.org/wiki/Inheritance_(computer_science)

---
WBR, Michael Nemtsev [.NET/C# MVP].
My blog: http://spaces.live.com/laflour
Team blog: http://devkids.blogspot.com/

"The greatest danger for most of us is not that our aim is too high and we
miss it, but that it is too low and we reach it" (c) Michelangelo

R> In the system I am working on, there are 3 credit cards: Visa,
R> MasterCard and
R> AmericanExpress. On the database side I have one table: credit_card
R> CREATE TABLE credit_card
R> ( credit_card_id int not null PRIMARY KEY,
R> credit_card_code varchar(30) not null,
R> description varchar(255) null )
R> Now I am building classes and i can do it in 2 ways:
R>
R> * Build a class "CreditCard".
R> public class CreditCard
R> {
R> private int _creditCardId;
R> private string _creditCardCode;
R> private string _description;
R> }
R> * Build a class "CreditCard" and then build 3 classes "Visa",
R> "MasterCard"
R> and "AmericanExpress" all inherited from "CreditCard".
R> public class CreditCard
R> {
R> private int _creditCardId;
R> private string _creditCardCode;
R> private string _description;
R> }
R> public class Visa : CreditCard
R> {
R> }
R> public class MasterCard : CreditCard
R> {
R> }
R> public class AmericanExpress : CreditCard
R> {
R> }
R> Which way is better and why?
R>
R> Thanks
R>
 
Thanks Michael.

One other person I consult with, thinks the first way is better. He is of
the view that "your classes should match one-to-one with your tables". What
do you think about that?
 
Rizwan said:
One other person I consult with, thinks the first way is better. He is of
the view that "your classes should match one-to-one with your tables". What
do you think about that?
Click to expand...

What's important isn't the view, so much as the reasons behind it.
There are times when a sort of inheritance structure makes sense, and
other times when it would make life harder.

*Why* does he think that classes should match one-to-one with tables?
What advantages does he see to that approach? How applicable are they
to your situation? What advantages are there in the alternative
approach? How much difference is there (in code) between the three
different kinds of card? Could those differences be encapsulated in a
way other than straight inheritance?

In short, we haven't got enough information to say what the best course
is - you need to be looking at the pros and cons of each approach. If
there's "received wisdom" you should ask for the reasons behind it -
otherwise it's superstition rather than wisdom.
 
Hi Rizwan,
I believe the person you consulted is thinking of using Reflection,
that's why he advised you to create a business Object class that match
one to one to your Database Table.
If you're going to build the system in the 3-tier architecture, that
person idea is best (i.e. creating each class for Visa, Mastercard and
Amex respectively).

But from language point of view, the second approach is more elegant
(^_^), since it's using inheritance.

Regards,
Hardono Arifanto
 
Back
Top