CODEWITHSUNDEEP
javadesign-patternsooad
AConsumer
AConsumer

Reputation: 2801

Java modelling class if objects have same properties but they are fundamentally different

Suppose i have to model credit card report and debit card report. Consider they both have same properties like transaction amount, date of transaction, place of transaction, transaction id and status of transaction.

How should i model this in Java ? Should i create Single class like Creditdebit class having properties as mentioned above and use it for creating credit report as well as debit report? or create separate classes as they are fundamentally different ? how should i handle this kind of scenarios? Help me with resources in dealing such cases or if there is any pattern to handle scenarios like this.

Upvotes: 0

Views: 456

Answers (1)

searchengine27
searchengine27

Reputation: 1471

Are they fundamentally different? Based on your description, it doesn't sound like it. Yes, logically the way you and I might think about credit and debit cards, they are fundamentally different.

But you need to differentiate between what you think is different in your mind and how you physically use it and what you need to model as different for your program to be able to process, because these are two different things. Sometimes the ideas that represent both how you use it and how your program will use it are the same, but not always.

In your case, you describe two things which may have different names, but are literally the same thing. If they have all the same attributes, and the function definitions are exactly identical, then it's the same class - why write it twice? Minimize your codebase.

That said, creating a separate class for both isn't a bad thing either. It helps you scale your code later.

abstract class Card {
    UUID id;
    BigDecimal limit;
    BigDecimal currentAmount;
    ...
    public void charge(BigDecimal amount) {
        currentAmount = currentAmount.add(amount);
    }
    ...
}
class DebitCard extends Card {}
class CreditCard extends Card{}

So your Card class contains all the logic, and DebitCard and CreditCard are both completely empty classes, inheriting all their fields and logic from the parent class, Card. The advantage here, again, is scaling. If later on, you determine that CreditCard needs to figure out some way to make monthly payments (not in your original description), then you can add that later without negatively impacting DebitCard in any way.

Upvotes: 3

Related Questions