Polymorphism and Arrays

Will Pritchard

Greenhorn

Posts: 7

1

posted 2 years ago

Hey forum! I'm not sure if it is allowed to post a homework assignment or not, but I do need some help. I pretty have the program made except I have no idea how to save user input/values to an array in a main class/method that gets information from one superclass and two subclasses. Is there anyone that can help me out with this, please? Here is the description from the assignment:

To demonstrate polymorphism, create an arrayList of Account type that can handle Checking and Savings accounts (this is the Bank). Prompt for name, account number (or assign account number in main) and add at least one checking object and one savings object to the bank array.
Now use a loop to process all accounts USING THE Bank array.

Here is what I've programmed so far:
Main - I was just experimenting to see if it would even grab values from my abstract class. I just need to figure out how to put values into a Checking and Savings array.

Will Pritchard wrote:Hey forum! I'm not sure if it is allowed to post a homework assignment or not...

That's fine, as long as:
(a) You're honest about it (which you have been).
(b) You don't expect us to just hand you the answer - and judging by the amount of work you've put in, that doesn't appear to be the case either.

And kudos on a very nicely produced question: You've included all the stuff we need to help you, and your code is nicely formatted. And for that you get a Cow - I wish more people wrote questions like it.

I used "Account" instead of bank. Why? I don't even know that.

I have to admit, that part of the requirements puzzled me too; but I think that what they want is for you to call the array 'bank', ie:
Account[] bank = new Account [2]; but TBH, I like 'accounts' better.

You could, however, put it in a Bankclass, on the basis that - for the purposes of this exercise - a Bank IS an bunch of Accounts. I leave that up to you.
And, as Darryl said, it should be an ArrayList, not an array.

(Tip: When you're reading requirements (or copying them for us) make sure that you register exactly what they said. Did they, for example, write 'bank' or 'Bank'? The first one suggests a field or variable name, whereas the latter suggests a class name. Java classes always start with a CAPITAL letter)

As for input: You might want to have a look at the UserInput page. It's fairly long, but it may give you some pointers.

I also agree with Carey: remove all those static qualifiers. In fact, don't ever define a static field unless you can explain why you did.

And before you try, have a look at the MainIsAPain page.
static fields are used for a very specific purpose - and it's NOT because main() is static.

Hope it helps.

Winston

"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here

Will Pritchard

Greenhorn

Posts: 7

1

posted 2 years ago

Hey Winston! Replying to you on my phone, so for some reason, I cannot quote. Thank you for the cow! I'm glad I accidentally made a good post! My professor said it is okay to put data into an array vs. arrayList, but I'm still not positive how to add values from different classes to an array/arrayList in a Main. Perhaps I missed it in the "main is a pain" link you provided. So, should I do an <array>.add(value, value, value) in main?

Campbell Ritchie

Marshal

Posts: 56546

172

posted 2 years ago

You don't do it in the main method. You do it elsewhere. Very simple for Lists.
myList.add(myValue); Bit more complicated for arrays; assuming the array is not yet full and you have a count variable telling you how many items are already in the array you can try
myArray[count++] = myValue; Because n++ returns the old value of n, if you have already filled 3 locations count++ will return 3 so it goes exactly for the 4th place in the array. Just where you want it. And count is now 4 ready for the next addition. Of course this will all go horribly wrong if you have a full array. You won't get such capacity problems with a List. You can copy a full array into a larger array but that is tedious.

is performing the divide in integer arithmetic. 2/100 will result in 0, which is then assigned to a double. One or both of the operands to the divide need to be a double.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

Will Pritchard

Greenhorn

Posts: 7

1

posted 2 years ago

Winston Gutkowski wrote:

Will Pritchard wrote:Hey forum! I'm not sure if it is allowed to post a homework assignment or not...

. . .
Hope it helps.

Winston

Just changed them to a non-static variables and the other subclasses freaked out. I guess that is why they are static. Also, Carrie and Campbell, thanks for the advice! I'll try to put the arrays in the actual class itself, and I'll make sure to update the interest rate.

Campbell Ritchie

Marshal

Posts: 56546

172

posted 2 years ago

Java® is an object‑oriented language. The keyword static means that what follows is not part of the object, so things static should be the exception and there should always be a good explanation for marking something static. As Winston said, because it won't compile otherwise is not a good reason.
You need to consider what an account object is, what a bank object is, etc. Consider which data (=fields) belong to which object and put them there. Consider which data are completely independent of objects; that might well be something static.

In this method you are passing in a double 'withdrawalAmount' for no other purpose than to have a place to assign the return value of inp.nextDouble(). you should use a local variable for withdrawalAmount and get rid of the parameter. You also seem to have your balance calculation backwards. No need to return anything here because the purpose of this method is to modify the state of your account.

In the big picture you may not want to incorporate the user interface in your Account class. Account should be a small class whose sole purpose is to maintain the state of an account object. You shouldn't burden it with the responsibilities of a user interface. Then it becomes a reusable component that can interact with either a text based interface or a graphical interface without modification.

Similar comments about this but if you keep this method I'd rename it. As it is it looks like a setter method that doesn't follow the conventions of a setter method. I would rename it to promptName(), or some such thing.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

Will Pritchard wrote:Just changed them to a non-static variables and the other subclasses freaked out. I guess that is why they are static.

No it isn't, unless you were given this code with all those static variables in it - and if you were, your tutors should be lined up and shot, because that is no way to teach Java.

But if you wrote it, then you chose to make them static (I suspect because you assumed it was the only way to reference them from main()), and now the compiler is complaining when you try to change them to what they should be, but you're not doing a complete job.

Take it from me: You should NOT define static fields unless they are also final. Ever. And you should not define static array or collection fields at all.

Did you look at the MainIsAPain page? Because it describes how convert even a poorly written main() method to an instance one.

HIH

Winston

"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here

This would have caused problems when you remove static. The CheckingAccount.XXX variables will no longer exist (this is a good thing). In addition those three assignments here were totally redundant because your call to super() already performed this function. Without static you should be able to access the variable accountName directly if you wish because you've declared them as protected.

Some people, when confronted with a problem, think "I know, I'll use regular expressions." Now they have two problems.

Will Pritchard

Greenhorn

Posts: 7

1

posted 2 years ago

1

Woah! Let's not get violent and shoot tutors. I was not given the code, but I did follow what my tutor was doing. Sorry.

So, I removed the statics and redundancy and sure enough! It works! Okay, now, how would I load everything from the user into either an array or arrayList? Should I put that in main? I was thinking doing a return ToString in a display method and then saving that to an array or arrayList. Would that work?

Oh, and about the interestCalc method and interestRate... local variables are not allowed in that class. =( also, my interestRate variable is a double. Is that correct? I thought dividing a number by 100 would give a percentage. How can I fix that?

Will Pritchard wrote:Woah! Let's not get violent and shoot tutors. I was not given the code, but I did follow what my tutor was doing. Sorry.

No sorry about it. If their code contained static variables, then they really do deserve to be shot (figuratively of course ).

So, I removed the statics and redundancy and sure enough! It works!

Well done! Have a pint on me.

Okay, now, how would I load everything from the user into either an array or arrayList? Should I put that in main?

Absolutely not. In fact, you should get out of the habit of putting all your code in main() as quickly as you can.

When you get further on, you'll discover that almost all the main() methods you write will have no more than 5 lines - and very often only one. And it'll look pretty much like the one in MainIsAPain.

However, for the moment, what about writing a method called loadBankAccounts? Which might look something like this:Then you can put all your logic for getting user input and loading it into an Account list (or array) in there, and simply call it from main().

Later on, you'll discover that there are many other (and better) ways to do it, but for now, whenever you think "I need to do something in main()", write a separate method called doSomething() (obviously with an appropriate name) and call it from main().
That way, you break up your problem into manageable pieces, and main() simply becomes a list of tasks, viz:Do you see how much easier that is to read? Someone with no knowledge of Java would have a pretty good idea what that class is doing, even if they don't understand all the code in its methods. And readability is very important.

However, even better is to break down the problem into classes - or objects - and forget about static methods altogether. But you'll probably be shown how to do that over the next few weeks on your course.

FYI: You may also find the WhereDoIStart page worth reading because, as you'll discover, you don't need to know exactly how you're going to do everything when you start writing a class.

And remember: These are only suggestions; there are tons of ways to write programs, and you'll need to find the one that best suits you. But get as much of that code out of main() as you can, as quickly as possible.

HIH

Winston

"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here