VerketteteListe Einsatz eingefügten Objekt gebunden

Question

Ich habe Code, der wie folgt aussieht:

public class Polynomial {
    List<Term> term = new LinkedList<Term>();

, und es scheint, dass, wenn ich so etwas wie term.add(anotherTerm) tue, mit anotherTerm zu sein ... einem anderen Begriff Objekt, so scheint es anotherTerm verweist das gleiche wie das, was ich habe gerade in Begriff eingeführt, so dass, wenn ich versuche anotherTerm zu ändern, term.get (2) (sagen wir mal) ist zu erhalten geändert.

Wie kann ich das verhindern?

Da Code angefordert wurde:

//since I was lazy and didn't want to go through the extra step of Polynomial.term.add
public void insert(Term inserting) {
    term.add(inserting);
}

Code, um das Insert-Methode aufrufen:

poly.insert(anotherTerm);

Code, um den anotherTerm Begriff zu erstellen:

Term anotherTerm = new Term(3, 7.6); //sets coefficient and power to 3 and 7.6

Neuer Code das Insert-Methode aufrufen:

poly.insert((Term)anotherTerm.clone());

Welche leider immer noch nicht funktioniert aufgrund clone() has protected access in java.lang.Object auch nach public class Term implements Cloneable{ tun

Answer 1

OK, replacing my old answer with this, now that I understand the question and behavior better.

You can do this if you like:

public void insertTerm(Term term) {
    polynomial.insert(new Term(term));
}

and then create a new Term constructor like this:

public Term(Term term) {
    this.coefficient = term.coefficient;
    this.exponent = term.exponent;
}

That should work.

Answer 2

The solution is simple: make Term immutable.

Effective Java 2nd Edition, Item 15: Minimize mutability:

• Immutable objects are simple.
• Immutable objects can be shared freely.
• Immutable objects make great building blocks for other objects.
• Classes should be immutable unless there's a very good reason to make them mutable.
• If a class cannot be made immutable, limit its mutability as much as possible.
  • Make every field final unless there is a compelling reason to make it non-final

Something as simple and small as Term really should be made immutable. It's a much better overall design, and you wouldn't have to worry about things like you were asking in your question.

See also

• What is meant by immutable?

---

This advice becomes even more compelling since the other answers are suggesting that you use clone().

Effective Java 2nd Edition, Item 11: Override clone judiciously

Because of the many shortcomings, some expert programmers simply choose to never override the clone method and never invoke it except, perhaps, to copy arrays.

From an interview with author Josh Bloch:

If you've read the item about cloning in my book, especially if you read between the lines, you will know that I think clone is deeply broken.

DO NOT make Term implements Cloneable. Make it immutable instead.

See also

• How to properly override clone method?
• Why people are so afraid of using clone() (on collection and JDK classes) ?

Answer 3

EDIT: Ok, I think I see what it is you're doing now. If you have this class:

public class Polynomial 
{
    List<Term> term = new LinkedList<Term>();

    public void insert(Term inserting) 
    {
       term.add(inserting);
    }
}

And then you do this:

Polynomal poly = new Polynomal()
Term term = new Term();
poly.insert(term);
term.coefficient = 4;

...then the object term is the same object as poly.get(0). "term" and "poly.get(0)" are both references to the same object - changing one will change the other.

Answer 4

Question is no so clear, but i just try , when you are adding the objects , add anotherTerm.clone()

Answer 5

It sounds like you are not instantiating new Objects, just referencing the same one. You should instantiate a new Term, either with Term term = new Term(); or by cloning term.clone().

EDIT to be able to be cloned, Term need to implement the Cloneable interface. That means that you are responsible for how the new copy of a Term should be defined.

Hard to tell without seeing the code that calls the insert method, but sounds like that is the problem.