Elegantere "dirty" Prüfungen?

[andreT]

Hallo,

ich muss mich mal wieder mit dem Thema "dirty" eines Objekts beschäftigen. Der übliche Weg sieht ja meist so aus :

public class DirtyTest {	
	private boolean dirty = false;

	private int intVariable;
	private boolean booleanVariable;
	private String stringVariable;
	
	public boolean isDirty() {
		return dirty;
	}

	private void setDirty(boolean dirty) {
		this.dirty = dirty;
	}

	public int getIntVariable() {
		return intVariable;
	}

	public void setIntVariable(int intVariable) {
		if(this.intVariable != intVariable) {
			setDirty(true);
		}
		
		this.intVariable = intVariable;
	}

	public boolean getBooleanVariable() {
		return booleanVariable;
	}

	public void setBooleanVariable(boolean booleanVariable) {
		if(this.booleanVariable != booleanVariable) {
			setDirty(true);
		}
		
		this.booleanVariable = booleanVariable;
	}

	public String getStringVariable() {
		return stringVariable;
	}

	public void setStringVariable(String stringVariable) {
		if(this.stringVariable == null && stringVariable != null
		|| this.stringVariable != null && stringVariable == null
		|| this.stringVariable != null && !this.stringVariable.equals(stringVariable)) {
			setDirty(true);
		}
		
		this.stringVariable = stringVariable;
	}
}

1.) Gibt es da eigtl. eine elegantere Vorgehensweise (Listener o.ä.)?
2.) Kann man diese ganzen Prüfungen auf != oder equals nicht irgendwie schicker in eine externe Methode auslagern oder sowas?
Hat da jemand einen Tipp o.ä.?

Gruß
A

 

[SlaterB]

grundsätzlich leichter hast du es, wenn du hier allerdings auf OO verzichtest,
indem die normalen Attribute verschwinden, alles in einer Map<Name, Wert> gespeichert wird

die Methoden könnten evtl. noch bleiben, aufrufen,

public void setX(int y) {
      set("x",value);
}

von den allgemeinen Basismethoden (Basisklasse für viele Beans) können sich einige um primitive Datentypen kümmern,
in Integer wrappen usw.

gerade wenn Daten in Formularen gespeichert werden, besonders im Web, und dort auch alles wiederholt wird, bietet sich das an,
Hibernate macht das Richtung DB auch

es kann ja zwei Stufen geben, einmal die normalen Objekte, einmal die dynamischen Varianten..

 

[andreT]

Dachte ich mir schon daß da nicht mal eben ...
Aber das 2-Stufen "Modell" ist sicher eine Überlegung wert.

 

[Sym]

Du könntest so etwas natürlich mit AOP lösen.

 

[andreT]

Mal sehen ... Eclipse.AOP grad mal installiert. Ganz schön mächtig das Zeugs

 

[Spacerat]

Kleiner Tip... schau' dir mal das seit Java7 veränderte Java2D-API im Bezug auf Imaging insbesondere die DataBuffer-Klassen. Dann noch ein besonderes Augenmerk auf die States STABLE, UNTRACKABLE usw. Das sollte einen doch auf neue Ideen bringen.

 

[andreT]

Kleiner Tip... schau' dir mal das seit Java7 veränderte Java2D-API im Bezug auf Imaging insbesondere die DataBuffer-Klassen. Dann noch ein besonderes Augenmerk auf die States STABLE, UNTRACKABLE usw. Das sollte einen doch auf neue Ideen bringen.

Hmm, steht da jemand bei mir auf der Leitung? So recht wird mir nicht klar was mir eine Codezeile wie
this.theTrackable = StateTrackableDelegate.createInstance(initialState);
genau sagen will. Kannst du deine Idee etwas erläutern?

 

[Spacerat]

Aber natürlich. Wo Sun einst den boolschen Wert "stolen" auf true setzte, verwenden sie nun dieses Trackable-Objekt. Weil man die Raster mit "setStolen(false)" viel zu leicht beeinflussen konnte (obwohl man dazu Konventionen umgehen musste), musste eine Art Brückenobjekt her, in welchem "stolen" gekapselt wird, so das es nur von einer Klasse zurückgesetzt werden kann, von dessen Existenz nur Sun (sorry... Oracle) etwas weis. Wie würdest du bei dir das dirty Bit zurücksetzen? Egal... nichts was man nicht auch per Reflection, JNI oder ähnlichem bewerkstelligen könnte um es zu umgehen. Wäre eine solche Lösung dann nicht praktikabler?

public interface DirtyTracker {
  void markDirty();
}

class DirtyTest {
  private final DitryTracker dt = DubioseDirtyTrackerFactory.createInstance();

  public void doThis() {
    // whatever
    synchronized(dt) {
      dt.markDirty();
    }
  }
}

Das einzige, was bekannt werden könnte, ist das Interface DirtyTracker und damit auch die Möglichkeit, ein Objekt zu invalidieren. Die echte Implementation aber bleibt geheim und es braucht einige schmutzige Reflectionzeilen mehr um den Sinn zu kompromitieren. Das man einen Anweisungsblock auch noch auf das DirtyTracker-Objekt synchronisieren kann ist ein zusätlicher positiver Nebeneffekt und selbst das Inteface kann geheim bleiben.
[EDIT]Eine "isDirty()"-Methode ist obligatorisch und im Interface nicht mal nötig. Kommt nur drauf an, wer diesen Status abfragen darf und wer nicht.[/EDIT]

 

[andreT]

Da werd ich nochmal drüber schlafen (müssen). Solche Sachen sind zwar schick, oft aber leider nicht massentauglich. Das Vorgehen ist sicher clever, nur die Nachwelt wird wohl ihre Probleme bei der Wartung haben vermute ich. Abgesehen davon bin ich innerhalb eines Frameworks wo ich mir nicht wirklich sicher sein kann ob ein solches "aus der Reihe tanzen" gewünscht ist. Wie gesagt, werd ich nochmal drüber schlafen, aber trotzdem ...