Kroakie on 18/2/2006 at 09:03
This time it's Java.
So I'm supposed to implement a linked list for two different object type for this assignment I'm doing. Then I thought, instead of making a type-specific link list, I'll make one that will work for all classes by working with the Object class. But now here's the question: how do I do a deep copying of an Object err... object? I can't just return the reference to the item in the list, what with the data hiding and all. I know there's this Cloneable interface, and I thought maybe I'll just make a linked list that'll work for all classes that implements the Cloneable interface, but it seems that the clone() method is under the Object class, and it's protected. I suppose I can declare a base ListItem class, and extend from that, but that seems a bit inflexible to me.
And no, please don't suggest that I use the Java Collections Framework, because the assignment explicitly states that use of the Java Collections Framework is prohibited.
henke on 18/2/2006 at 09:29
Oh that KERRRAZY KROAKIE! :D
Here we go again! :joke:
mopgoblin on 18/2/2006 at 09:51
Why don't you want to return a reference to the item in the list? It's been a while since I've used Java, but since you're putting a reference to an object into the list, you'd expect to get a reference to the same object back out, right? The actual objects you store aren't logically part of the inner workings of the class.
aguywhoplaysthief on 18/2/2006 at 11:21
I think a better question is, "How do I make a virus for a Mac so I can knock those bitches down a peg?"
dvrabel on 18/2/2006 at 12:05
Use generics.
addink on 18/2/2006 at 13:12
Why do you need to copy/clone the instances referenced in the linked list?
a linked list -as I know it- usually consists of two* classes:
* The list. A basic interface to manage the list.
* The list nodes. The nodes that make up the actual list; referencing to next and prev nodes in the list, and referencing to instances of arbritrary classes, the instances that are to be listed.
Copying or cloning the listed instances would just make a mess of things wouldn't it?
Also, if a class has private properties and doesn't provide method(s) to create a clone, it shouldn't be cloned.
*) An additional third class often provided with linked lists is an iterator to easily step through the list.
Kroakie on 18/2/2006 at 15:00
If I just return the references to the elements, won't they be modifiable outside the list? Say the items are actually sorted. Then I retrieve an item from the list and modify the key field. Won't that mess up the list? At least, that's what the lecturer said. However, he used a type-specific linked list in his example code, and hence the question.
WingedKagouti on 18/2/2006 at 17:28
You won't be able to ensure that a list of Objects can be sorted in any meaningful way because you can have several different classes stored in it.
How would you sort an object exposing 2 strings and another object exposing 2 integers? Their ToString may return the same result regardless of any properties.
If the list has to be sorted then you need to know the type of objects stored in it.
addink on 18/2/2006 at 18:16
Two ways about this.
1- If you want a list class that can list any type of object, just use references.
The 'any type of object' part of the last sentence does imply that the objects themselves don't provide an mechanism that takes in account any changes that the list should be susceptible to.
2- If you do want changes to the object to affect the list too (order- or otherwise) you need to code that into the object. And the 'any type of object' is no longer applicable.
Nice thing about the latter option is that objects are actually 'aware' of their presence in a list; coded well, that can prevent unnecessary sorting and keep the list clean of invalidated objects without too much overhead.
---
On the other hand, if the changes you want to keep track of are list specific, just add the interface for the changes to the node class. And you can still link to any type of object.
descenterace on 18/2/2006 at 18:42
This would be why there is no SortedList class in Java. Instead, we have the Collections.sort(...) static methods.
I cannot understand for a moment why allowing the objects in the list to be modified in place is a bad thing. Kroakie, have you actually looked at how the standard Java list-type classes do things? ArrayList doesn't give a damn what you do to the objects in it.
All a linked list does is store references to objects. It doesn't care what you do to them. 'Data hiding' applies to the linked list's internals, not to the things it's keeping references to.
Re-sorting a list every time it's modified is a ridiculous waste of time. If you're doing something to it that requires that it be sorted, explicitly sort it first. Which is why we have Collections.sort(...).
