Hey, New to Java and this forum! I have a school project that i'm having difficulty with understanding. we were allowed choose whatever we wanted I chose a bank and i'm regretting it now!!! Basically I wanted a Customer Class to hold all the personal details , an Account Class, a transaction class and a main driver code with the gui to display everything. The first thing i'm stuck with is I don't really understand the "Has a " relationship. Like the customer has Accounts but how do I actually link them?? I'm going to post my code so far but its all over the place and very messy, i'm just very confussed at the moment!!
this is the Account Class so far
This is the Customer Class so far
This is the Transaction Class (Haven't figured out where i am going with that yet)
And the Driver Code
Sorry about the really long post just panicing at the moment because I don't know what to fix first to move forward!
Also I'm only doing this with 2 months so I'm not really up on the lingo!
The first thing i'm stuck with is I don't really understand the "Has a " relationship. Like the customer has Accounts but how do I actually link them??
The 'Has-A' relationship is pretty self explanatory (i.e. an object of one type contains, holds, or owns an object of the other type). The way this works in Java is the use of a variable of the appropriate type. For example:
If the Customer can have more than one Account then use a List<Account> (read: a List of Accounts) instead of an Account. How do you get an Account into the Customer? There are basically 3 ways, (1) the Customer can create the Account itself if it has all the information needed to do so:
(2) the Account can be passed into the Customer class via the constructor. You usually use this way if the Customer must have an Account in order to exist (and usually if it has the same Account for the life of the Customer).
Finally (3) you can pass the Account in to the Customer via a 'setter' method.
In your case, your Account Has-A Customer, and you are saying that the Customer also Has-A Account. So you will need to keep these two in sync. One possible way, since you pass the Customer into the Account as a parameter in its constructor, would be to have the Account pass itself to the Customer as part of its constructor. something like:
Don't take this the wrong way, but what possible reason do you have for writing almost 700 lines of code when you don't seem to understand what you need to be doing?
Good software design starts with pencil, paper, and your brain. you design at a high level what things should look like and what they should do.
You then write your code in TINY chunks. I never write more than 5 lines before I compile and test.
You want to write code in atomic pieces. What I mean by that is that you can write an account class, and nothing else. you can write code (that you may eventually throw away) to test it and verify it works - that it is rock solid. Once you KNOW your account class works, you can write a person class that has-a account. You then don't need to worry about the account class because you know it is good - you just test the person class until it is rock solid.
Once your person class is tested and rock solid, you can work on your Bank class, and then whatever comes next. Once you have all those working, you then start your GUI code.
If you try and do it all at once, you are doomed to failure.
There are only two hard things in computer science: cache invalidation, naming things, and off-by-one errors
fred rosenberger wrote:If you try and do it all at once, you are doomed to failure.
@Trish: And further to what Fred said, I would suggest very strongly that you separate your "banking" classes from your GUI entirely (possibly even putting them in a different package).
Bank Accounts (and Customers) existed long before we had computers and terminals to write fancy display systems for; so try and separate the business of banking from that of display. You'll also find that it helps an awful lot when you come to writing test modules.
Steve Luke wrote:If the Customer can have more than one Account then use a List<Account> (read: a List of Accounts) instead of an Account...
In this particular case I think a Set would be better, since you're not likely to want duplicate Accounts for a Customer (or indeed duplicate Customers for an Account, if that's the way Trish decides to go - I have to admit a slight preference for the latter).
Winston (old DBA)
Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Joined: May 05, 2012
Thanks so much for all the help and advice guys. I'm going to sit down and strip it back now and get everything working step by step, Its my first project and I wasn't sure how to approach it so I dived in foolishly!!! Just one thing you say to separate the gui should I take it out of the main class completely and create a domain class??
Trish Murphy wrote:Thanks so much for all the help and advice guys. I'm going to sit down and strip it back now and get everything working step by step, Its my first project and I wasn't sure how to approach it so I dived in foolishly!!! Just one thing you say to separate the gui should I take it out of the main class completely and create a domain class??
Well, I'm afraid I'm no expert on GUIs, but I'd have thought that one of any size would involve quite a lot of classes.
What I can tell you is that a class called Account should be exactly that: a bank account, NOT its visual representation; so I'd be leery of any Account class that included references to any classes beginning with 'J' (JPanel, JFrame, JComponent... etc) or any System.out calls, unless they're there purely for testing or debugging.
something you might want to read up on is the MVC design principle...Model, View, Controller. The basic idea is that you can separate out these three things - they are completely independent of each other. A device that tells time is the classic example...
The model is how you represent the data inside the computer. A clock may use a pendulum, a radio-isotope decaying, a quartz crystal vibrating, sand falling, or any of several other ways to mark the passage of time. The point is, it doesn't matter how you do it - you pick the one that is best for the technology you have available.
Next is the view. The view asks the model for the time, then displays it to the user. It could post it as "12:17 pm", or be the hands on a clock face, or blinking lights on a binary clock...again, it doesn't matter. the view just asks the model for the data - it doesn't care how the model gets/creates/keeps track of stuff.
Finally, there is the controller. This is how the user interacts with the device. there could be a stem on a watch you pull/push and twist. There could be buttons you press to do different things. Maybe you implement speech recognition. Again, the controller doesn't care how the view displays the data or how the model does its part...
All three do have to talk to each other, but all three can be written independently of each other, and you can - if you design it carefully - replace any one of the three and not impact the other two at all...
I don't think at this point you need to learn any of the MVC frameworks (struts, for example), but the concept is a good thing to start thinking about now.