Don't use either of those classes, which are both regarded as legacy code. In youir method headings declare the parameter as type List<E> instead.
C Robinson wrote:. . . class that uses Enumerations . . . for a "wallet" Vector . . .
Please work out why you are getting access to the value field at all. Look where you have written the Currency class.
1) Why need the getValue() method if my first approach worked?
C Robinson wrote:1) Why need the getValue() method if my first approach worked?
2) Was there a better way to achieve what I have other than moving the reference BACK to a Currency Object? (I tried casting Object "o" and changing the parameters of getValue() and it did not work)
3) General observations about approach, etc. I know I have no comments (yet).
As far as there being "something wrong with the design of code that uses instanceOf multiple times", I'm obviously new at this and wouldn't know what that something is. I'm posting here to learn things, so understanding what exactly is wrong and why is key.
For classes/methods that are final, it really doesn't matter that much. Note also that if you want to access the property from another class, you have no choice but to call the method, because fields should be private.
If you meant to ask if there was a better way to access the value property of a Currency object when you have a reference to it of type Object, then the only thing you CAN do it cast it. But as Campbell has pointed out, you want to avoid having to cast, and use generic type parameters in the way they were intended.
But going by the original code, the entire purpose of this exercise is to mix objects of different types and then cast them back at a later time. Realize though that in the real world, you will want to avoid code that like.
In object oriented programming, you want to create a class that actually represents a wallet and to which you add instance methods.
You might notice that I used int to represent the value of a denomination, and I used BigDecimal to print it. That is because you should NEVER use floating point types such as float and double to represent exact values, such as monetary amounts. When you use floating point types, all arithmetic operations may cause rounding errors. With BigDecimal, you can move rounding operations to the end of the calculation and explicitly specify how the rounding is done
Stephan van Hulst wrote:...except move the parameter checking and the defensive copying to the factory methods. Private constructors may assume that their parameters are validated and copied,
C Robinson wrote: the field is private, so how would the piece of code above be able to use it to increment the total variable?
I believe they are teaching the material in a certain way so we can grasp the concept with the easiest process, correct or not, and then they expand on it later.
This would have been my first approach, but this likely wasn't a requirement to keep learning the concepts less complicated.
This seems pretty straightforward, I'm surprised we had not learned this yet as I am in the second Java course.
Junilu Lacar wrote:Great discussion. I especially applaud OP for his search for understanding.
The reason is that the private modifier means that only code inside the same top-level class' body is allowed to access the member. The value field is a member of the Currency enum, which is declared inside the D3 top-level class. That means that EVERY piece of code inside the D3 class' body can access it directly. The main() method is inside the D3 class, so it can access the Currency.value field directly.
Another way of thinking about this is that private means "private to the code in this source file", but only if you have no more than one top-level class in your source file.
It's likely because professors and authors don't want to distract from the lesson they're trying to teach by introducing new types.
The instructor probably knows it's not a good idea but reasons that "They'll figure this out later, I just want to show them the motion and how the mechanics of the arm works." To me, this is totally wrong.
I had better come back to this discussion after such a long absence (sorry).
C Robinson wrote:. . . We did not get to set these parameters for the assignment, these were requirements.
Some people have already answered. There are two problems. One is that you are not using an inheritance hierarchy properly. You would have something like[[That would work a lot better. You can now declare your List as List<WalletItem> wallet new ArrayList<>(); or simlar
As far as there being "something wrong with the design of code that uses instanceOf multiple times", . . .
I have seen what passes for creativity in some students' code It isn't a pretty sight.
About half an hour ago, I wrote:. . . creativity . . .