Nochmal Frage zu Vererbung Interfaces etc.

  • Themenstarter Themenstarter TheMole
  • Beginndatum Beginndatum
Status
Nicht offen für weitere Antworten.
T

TheMole

Gast
Hallo,
ich muss mich nochmal melden, wenn ich das im alten Thread gestellt hätte, wäre es vielleicht untergegangen und es wäre wichtig für mich. Daher wäre ich dankbar wenn sich mal jemand melden könnte und kurz seinen kompeteten Senf dazu gibt: Zuerst muss ich ein bisschen viel Code posten:

http://www.java-forum.org/de/topic58433_frage-interface-guter-programmierstil.html


und die Fragen sind auch konkret:

- Ist es sinnvoll, Die zustäzlichen Methoden der Klassen ElementDataImplxxx auch in das interface zu nehmen, auch
wenn die nicht von allen erbenden Klassen gebraucht werden?

- Ist es möglich eine einzige View für alle 3 Modelklassen zu definieren, anstatt für jede Modelklasse eine eigene View (für die Darstellung werden ja JLabels verwendet, davon werden in einer View graphics methoden benötigt, insgesamt sind die Views , auch wenn alle gemeinsame Daten haben, sehr unterschiedlich, so dass hier in einer ViewKlasse wohl viel Code nötige wäre...?)


- Allgemein: Wie ist dieser Ansatz, was kann man besser machen ?


Bitte es wäre sehr wichtig, für sinnvolle Antworten überweise ich eine Spende für das Forum 😉

Code:
package mvc;

import java.awt.Graphics;

import javax.swing.JLabel;

/**
 * 
 * interface mit gemeinsamen methoden für die Klassen ElementDataImplxxxx
 *
 */

public interface ElementData {
	
	void setA(int a);
	int getA();
	
	void setB(int b);
	int getB();
	
	void setC(int c);
	int getC();
	
	void setD();
	int getD();	

}

/**
 * 
 * abstrakte Oberklasse für gemeinsame Felder
 *
 */

public abstract class ElementDataImpl implements ElementData {	

	int a, b, c, d;
	
	public ElementDataImpl(int a, int b, int c, int d) {		
		this.a = a;
		this.b = b;
		this.c = c;
		this.d = d;
	}
	
	public int getA() {	
		return 0;
	}

	public int getB() {	
		return 0;
	}

	public int getC() {	
		return 0;
	}

	public int getD() {	
		return 0;
	}

	public void setA(int a) {}

	public void setB(int b) {}

	public void setC(int c) {}

	public void setD() {}	
}

/**
 * 
 * Datenhalter Klassen
 *
 */

public class ElementDataImplExtended1 extends ElementDataImpl {
	
	private String additionalField1;	
	
	public ElementDataImplExtended1(int a, int b, int c, int d, String newField) {
		super(a,b,c,d);
		setAdditionalField1(newField);
	}

	public String getAdditionalField1() {
		return additionalField1;
	}

	public void setAdditionalField1(String additionalField1) {
		this.additionalField1 = additionalField1;
	}	
}

public class ElementDataImplExtended2 extends ElementDataImpl {
	
	private String additionalField1;
	private boolean additionalField2;
	
	public ElementDataImplExtended2(int a, int b, int c, int d, String newField, boolean newValue) {
		super(a,b,c,d);
		setAdditionalField1(additionalField1);
		setAdditionalField2(newValue);
	}

	public String getAdditionalField1() {
		return additionalField1;
	}

	public void setAdditionalField1(String additionalField1) {
		this.additionalField1 = additionalField1;
	}

	public boolean isAdditionalField2() {
		return additionalField2;
	}

	public void setAdditionalField2(boolean additionalField2) {
		this.additionalField2 = additionalField2;
	}	
}


public class ElementDataImplExtended3 extends ElementDataImpl {
	
	
	private byte[] newField;
	
	public ElementDataImplExtended3 (int a, int b, int c, int d, byte[] newField) {
		super(a,b,c,d);
		setNewField(newField);
		
	}

	public byte[] getNewField() {
		return newField;
	}

	public void setNewField(byte[] newField) {
		this.newField = newField;
	}
}

/**
 * 
 * View Klassen
 *
 */

public class ElementDataImplExtended1View extends JLabel {
	
	private ElementDataImplExtended1 data;
	
	public ElementDataImplExtended1View(ElementDataImplExtended1 data){
		this.data = data;		
	}

	public ElementData getData() {
		return data;
	}

	public void setData(ElementDataImplExtended1 data) {
		this.data = data;
	}	
	
	/**
	 * additional code
	 */
	
	public void paintComponent(Graphics g){
		//some action
	}
	
}


public class ElementDataImplExtended2View extends JLabel {
	
	private ElementDataImplExtended2 data;
	private JLabel otherLabel = new JLabel();
	
	public ElementDataImplExtended2View(ElementDataImplExtended2 data){
		this.data = data;
		//some actions
	}

	public ElementData getData() {
		return data;
	}

	public void setData(ElementDataImplExtended2 data) {
		this.data = data;
	}	
	
}

public class ElementDataImplExtended3View extends JLabel {
	
	private ElementDataImplExtended3 data;
	
	public ElementDataImplExtended3View(ElementDataImplExtended3 data){
		this.data = data;	
		
		//to something with the data
	}

	public ElementData getData() {
		return data;
	}

	public void setData(ElementDataImplExtended3 data) {
		this.data = data;
	}	
	
}
 
> - Ist es sinnvoll, Die zustäzlichen Methoden der Klassen ElementDataImplxxx auch in das interface zu nehmen, auch
> wenn die nicht von allen erbenden Klassen gebraucht werden?
Ich würde dann wohl eher ein zweites Interface ElementData2 machen, das vom ersten erbt.

> - Ist es möglich eine einzige View für alle 3 Modelklassen zu definieren, anstatt für jede Modelklasse eine eigene View
Ein Model kann mehrere Views haben, aber nicht umgekehrt :wink:
 
Ok, Danke. Das heißt also dass das im Wesentlichen so in Ordnung ist ?

Was spricht gegen einen solchen Ansatz, der nun genau eine View für mehrere Models hat ?

Code:
class BusinessAction {
	
	ElementDataImplExtended1 dataModel1 = new ElementDataImplExtended1(1,2,3,4,"Typ 1");
	ElementDataImplExtended2 dataModel2 = new ElementDataImplExtended2(1,2,3,4,"Typ 2");
	ElementDataImplExtended3 dataModel3 = new ElementDataImplExtended3(1,2,3,4,"Typ 3");
}

public class OneViewForDifferentModels extends JPanel
{
	
	JLabel viewingLabel;
	ElementData data;
	
	public OneViewForDifferentModels(ElementData data) {
	
		this.data = data;
		
		if(data.getType.equals(TYPE_1)){
			setViewForType1();
		}
		else if (data.getType.equals(TYPE_2)){
			setViewForType1();
		}
		//...
		
	}
	
	public void setViewForType1() {
		viewingLabel = new JLabel();
		//....
		
		//special operations
		this.add(viewingLabel);
	}
	
	public void setViewForType2() {
		viewingLabel = new JLabel() {
			
			public void paintComponent(Graphics g){
				//...
			}
			
		};
		
	}
}
 
Hm, ich glaub jetzt war ich ein bisschen falsch. Das ganze ist ja nur in einer Klasse statt in mehreren gesteuert, aber trotzdem werden utnerschiedliche Views in Abhängigkeit des Modesl erzeugt ???:L
 
Die letzte Frage würde mich jetzt auch interessieren, speziell wegen des Kommentars

André Uhres hat gesagt.:
Ein Model kann mehrere Views haben, aber nicht umgekehrt

Eine View KÖNNTE doch auch meherer Models haben ???:L Oder anders gefragt: Wenn man die von dir genannte Bedingung erfüllen würde, indem man nicht
Code:
View { Model1, Model2, Model3  }
sondern
Code:
CompoundModel { Model1, Model2, Model3 }
View { CompoundModel }
schreibt, wäre das doch erstmal nur "Kosmektik"!? Ich würde spontan keinen direkten Vor- oder Nachteil bei einer der beiden Varianten sehen (abgesehen davon, dass beim CompoundModel u.U. mehr Durchreich-Arbeit zu tun ist)
[/quote]
 
Sowas ist vielleicht irgendwie machbar. Vom Gefühl her widerstebt mir aber ein Design, bei dem eine View gleichzeitig mehrere Models hat.
Dass man das mal Model austauschen kann, ist verständlich.
Aber gleichzeitig mehrere Model für ein View, da seh ich wirklich keinen Sinn dahinter.
 
Hm. Vielleicht hätte ich einen wichtigen Punkt erwähnen sollen: Ich bin davon ausgegangen, dass die Models "disjunkt" sind - also, dass es NICHT mehrere Models gibt, die (sinngemäß) auf die gleiche Component in der View "abgebildet" werden.
 
Ok aber meine Frage zu dem letzten Codeabschnitt ist immer noch nicht beantwortet.
Ein Model, verschiedene Views, die aber alle aus einer Klasse in Anbhägigkeit des Models (Konstruktor) gesetzt werden.
Ist das so in Ordnung oder nicht. so lange dies nicht ein gravierend schlec htes desgin ist, bin ich zufrieden. bitte nochmal um antwort. danke!
 
Marco13 hat gesagt.:
Code:
View { Model1, Model2, Model3  }
sondern
Code:
CompoundModel { Model1, Model2, Model3 }
View { CompoundModel }
schreibt, wäre das doch erstmal nur "Kosmektik"!? Ich würde spontan keinen direkten Vor- oder Nachteil bei einer der beiden Varianten sehen (abgesehen davon, dass beim CompoundModel u.U. mehr Durchreich-Arbeit zu tun ist)
[/quote]

Also zweiteres ist schon wesentlich besser, da hier in der View keine Unterscheidung zwischen den 3 Models durchgeführt werden muss. Die Unterscheidung ist Aufgabe des Controllers. Im Beispiel von TheMole ist diese Unterscheidung im Konstruktor implementiert, wodurch Controller und GUI stark vermischt werden.

Mit einem CompoundModel jedoch, weist man dem View einmal die Komponente zu und kann sie dann später im Controller modifizieren. Sämliche Modifikationsmöglichkeiten sollten dabei mindestens als abstrakte Methode im CompoundModel stehen. Das beste existierende Beispiel für den "CompoundModel-Ansatz" sind TableModel und JTable, obwohl ich eigentlich das Swing-TableModel noch zur GUI zähle - aber das Prinzip ist das gleiche.
 
TheMOle hat gesagt.:
Ok aber meine Frage zu dem letzten Codeabschnitt ist immer noch nicht beantwortet.
Ein Model, verschiedene Views, die aber alle aus einer Klasse in Anbhägigkeit des Models (Konstruktor) gesetzt werden.
Ist das so in Ordnung oder nicht. so lange dies nicht ein gravierend schlec htes desgin ist, bin ich zufrieden. bitte nochmal um antwort. danke!

Geschmackssache. Im Sinne von MVC halte ich es für unschön, das im Konstruktor zu machen. S.o.
 
hier kann man das adapter pattern anwenden, und die models passend übersetzen..
 
Status
Nicht offen für weitere Antworten.

Zurück
Oben