~ Mansukh
Mansukhdeep Thind wrote:As soon as I wrote extends List<T> and hit return key, it threw a lot of naming clashes with the already implemented methods. It says that return types do not match. How to overcome this duplication issue Jeff?
So, do I change the return types of all already the implemented methods which have naming clashes due to distinct return types from those specified in the List<T> interface?
Jeff Verdegan wrote:
Mansukhdeep Thind wrote:As soon as I wrote extends List<T> and hit return key, it threw a lot of naming clashes with the already implemented methods. It says that return types do not match. How to overcome this duplication issue Jeff?
If you're exending class or interface X, then any public or protected methods you have with the same signature as X must have the same return type as X's version, or a subtype. There's no way around that, which is a good thing.
If I declare a variable to be of type List, I might get back a MansukhdeepArrayList and not even know it. All I know and care about is that I have a List, so if List.foo() returns int, then whatever concrete List implementation I get, including MansukhdeepArrayList, better return int from its foo() method, not long or double or boolean or void or JPanel.
Jeff Verdegan wrote:
Mansukhdeep Thind wrote:So, do I change the return types of all already the implemented methods which have naming clashes due to distinct return types from those specified in the List<T> interface?
If you want to implement or extend List, then yes. Remember implements and extends represent inheritance, which is an IS-A relationship, and if you're going to say, "My class IS-A List," then your class has to behave like List promises to behave.
~ Mansukh
Mansukhdeep Thind wrote:So the only parts of a method I would need to change would be the return types in the declaration and return the respective types from inside the methods. That should do it. Correct?
Jeff Verdegan wrote:
Mansukhdeep Thind wrote:So the only parts of a method I would need to change would be the return types in the declaration and return the respective types from inside the methods. That should do it. Correct?
In order to satisfy the compiler, yes, that's all you'll have to change.
However, if you're changing the return type, you're also changing the semantics of the returned value. In order to satisfy the documented behavior, you can't just return any old value of the appropriate type. You'll have to make sure that the value you return matches the documented semantics.
~ Mansukh
Jeff Verdegan wrote:I gotta admit, I really don't see what the benefit is to this approach. It's not like next() vs. previous() is a complex concept to get one's head around.
I think I'm missing some key point somewhere.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Jeff Verdegan wrote:I gotta admit, I really don't see what the benefit is to this approach. It's not like next() vs. previous() is a complex concept to get one's head around.
No, but the combination of the two can get a bit tricky.
Also:
It saves duplicating methods for each direction.
It allows you to create an Iterator that can change direction. Even with all those darn methods in ListIterator, you can't do that unless you store the "current" direction somewhere. In fact, in order to comply with the requirements of the class, you're pretty much forced to store it anyway.
And wouldn't it be nice to have a way of returning the contents of any Collection in reverse sequence, rather than having to define extra methods to do it? To me, an Iterator iterates - why should that mean only forwards?
To be honest, there's no real reason for DirectionalIterator to have any extra methods at all; you could just plug a Direction into an Iterator. I can also imagine that for a matrix-style dataset like a ResultSet, it could be used to iterate in more than just two directions. Do you want to add extra methods for all of them?
I think I'm missing some key point somewhere.
Jeff Verdegan wrote:Not to beat a dead horse, but I still don't see how setting a direction and then using a single next() method ends up with less code than having a separate previous() method
Maybe it's one of those things that's hard to understand until you actually need it.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Jeff Verdegan wrote:Yes.
For the documentation, if you put nothing there, then javadoc will provide a link to the parent's docs. Again, judgment call for you.
Of course, if your implementation does anything special that's worth noting--such is it's O(N) when the general case is O(N^2) or vice versa, or anything else that might surprise a user of the method in the general case--then you want to make sure to document that.
~ Mansukh
Mansukhdeep Thind wrote:Please comment if I have changed them correctly as per the List interface contract.
~ Mansukh
~ Mansukh
Mansukhdeep Thind wrote:Can you teach me how to write test cases for a method? Any tutorial would be appreciated.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
~ Mansukh
~ Mansukh
Mansukhdeep Thind wrote:The third test method that checks for IndexOutOfBoundsException should fail if I pass the correct valued for index. Why does it pass then? It should pass if the index passed is -ve or more than size, which, in this case, is not true.
~ Mansukh
Mansukhdeep Thind wrote:It is as if there are 3 separate instances of myList.
Jeff Verdegan wrote:
Mansukhdeep Thind wrote:It is as if there are 3 separate instances of myList.
Maybe there are.
What do the docs for JUnit say about how many instances of your test class it creates? What do they say about the order in which the test methods will be called? What do they say about preserving the state of your test class between calls?
Jeff Verdegan wrote:
Mansukhdeep Thind wrote:Once again, you seem to be making assumptions about how things behave, and then when you see something that doesn't fit your assumptions, rather than investigating and checking your assumptions you're running here for help. People here are happy to help. That's why we come here after all. But by now, I'd expect you to be doing a little more research yourself before posting here. Don't let this site become a crutch, and don't assume every little question or problem that comes up has to be part of the group discussion.
~ Mansukh
Mansukhdeep Thind wrote:
I read the API documentation here. But I could not find anything that indicates specifically what is the flow of execution? After it creates an instance of my Test Class CustomArrayList_Test using reflection, what happens then? That is what I want to know.
Apologies if I am being too curious or irritating Jeff.
~ Mansukh
Mansukhdeep Thind wrote:@ Winston : I cautiously reused code this time.
EDIT: The declaration of the toArray(T[] a) method gives a warning:
The type parameter T is hiding the type T
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:
Actually, that method signature is not very good. It really should be:
public <T extends E> T[] toArray(T[] a) {
which probably doesn't solve your problem; but at least makes it more obvious what's going on. They should probably warn you about it in the docs too.
Mike Simmons wrote:Surely <T super E> would make more sense, no? And be safe for use for any legal T?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
~ Mansukh
Stinging nettles are edible. But I really want to see you try to eat this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|