Which design decision should I use?

Question

2.00/5 (1 vote)

See more:

I am in the process of designing a checkbook register application, for my own personal project and use. I am running into some design decision stumbling blocks, which I would like some input for.

First, I initially thought of creating one whole class to input the register entries into the database which stores everything. However, upon further reflection I was thinking that maybe the withdrawal and deposit functionality of the application should be in different classes (On the basis that a class should only house 1 responsibility). When I wrote this out on paper, I found that the two classes (withdrawal and deposit) would have similar functionality; and in my mind should be in the same class.

I am going to develop this application in C#. What are other options or just thoughts on what I should do? Should it be in one class, or should it be dealt with multiple classes?

Thanks

Posted 17-Jun-14 4:09am

jason17349

Add a Solution

Comments

johannesnestler 17-Jun-14 10:33am

For me a "Entry" would be a (abstract?) base class and you could derive an WithdrawalEntry and a DepositEntry from it.

jason17349 17-Jun-14 10:34am

Would you be willing to explain a little bit further on that thought?

johannesnestler 17-Jun-14 11:36am

I'll try: I'm assuming you want to show all withdrawal and deposit actions later as a list or whatever. Therfore I'd model that as objects (in opposition to OriginalGriffs suggested "account" solution).
So your "model" could look like this: An account, a list of withdrawal and deposit objects associated with that account. And functions on the account object to pass a withdrawal and deposit object which changes the account (adds or removes money). If withdrawal and deposit object have the same properties, it would be easiest to derive them from a common base class. So your object model would be very close to the storage model (e.g. tables in the database) and could also be mapped easily (e.g. with EntityFramework).
Maybe as general "advice" I'd say try to make something useful first, if you see yourself duplicating code - just refactor (then call it "agile" and look cool ;-) ).

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

OriginalGriff · Answer 1 · 2014-06-17T04:42:00

Personally, I would split is differently: have an Account class (which has Deposit and Withdrawal methods), but abstract the structure of the app into the Three Layer Model: Presentation, Business and Data Access. The Account class would be in the BL and would interface with the DL to read / write from the DB.

There is no good reason why an Account needs to know how it is stored, or displayed - but since it needs input and output mechanisms (or it's not an account, it's just a number) it should be a single class.

Think about the real world equivalent: you don't know what the heck your bank does with the money you give it (DL) and the bank doesn't care how you cope with your checkbook and receipts, or if you write a cheque or use Paypal to make a withdrawal (PL).
All you have is a mechanism for identifying the account (the account number), some authorisation procedures (depends on the bank) and some way(s) to get money in and out - and ensure that you have enough in place to do it!