OOP Klassen mit "Eigenschaften"

[Codeschnipsel]

Hallo,
Ich habe ein Problem und eine Lösung dafür. Mit dieser bin ich jedoch nicht wirklich zufrieden:

Das Problem:

• Ich habe mehrere Klassen und mehrere "Eigenschaften".
• Die Eigenschaften werden/können nicht durch Methoden oder ähnliches beschrieben werden. Sie sind über die Klassen definiert, die sie besitzen (Gemeinsamkeiten).
• Es sollen Gruppen von Klassen gebildet werden. Jede dieser Gruppen besteht aus Klassen, die alle eine bestimmte Eigenschaft gemeinsam haben.
• Die Eigenschaften der Untergruppen/Teilmengen haben/müssen nichts mit den Eigenschaften der übergeordneten Gruppe/Obermenge zu tun haben.
• Außerdem soll der Compiler bei diesen Gruppen auf Typ-Korrektheit überprüfen (können).

Bisherige Lösung:

• Für jede Gruppe wird ein (möglicherweise leeres) Interface erstellt.
• Alle Klassen, die eine gemeinsame Eigenschaft besitzen, implementieren dieses Interface. Die Gruppe bzw. das Interface steht also für alle Klassen mit dieser Eigenschaft.
• Will man nun einer Methode, einen Parameter übergeben, der nur Klassen mit einer bestimmten Eigenschaft annehmen soll, ist der Parameter-Typ das entsprechende Interface.

Beschreibung eines Beispiels:

• Alle Klassen implementieren ein Interface mit einer Methode m1.
• Für jede Eigenschaft wird ein Interface (Grupp) erstellt, das von allen Klassen implementiert wird, die die entsprechende Eigenschaft erfüllen. Eigenschaften könnten z.B. Seiteneffekte sein, die beim ausführen der Methode m1 auftreten.
  Das Interface steht folglich für eine Gruppe von Klassen mit einer entsprechenden Eigenschaft. Es repräsentiert sozusagen die Eigenschaft.
• Des weiteren existiert noch eine Methode m2, die als Parameter ein Objekt einer Gruppe mit bestimmter Eigenschaft/Seiteneffekt bekommt.
  In m2 wird m1 vom übergebenen Objekt aufgerufen. Dabei wissen wir über den Seiteneffekt (SE) bzw. die Eigenschaft (E) Bescheid, die beim Ausführen von m1 auftritt (SE) bzw. erfüllt ist (E).
• Es ist nicht möglich, m2 ein Objekt ohne entsprechende Eigenschaft/Seiteneffekt zu übergeben, da der Compiler auf Typ-Korrektheit überprüft.

Code-Beispiel: (Seiteneffekt werden über eine Ausgabe dargestellt)

public class Example {
	public static void m2(Property_12 p_12) {
		p_12.m1();
	}
	
	public static void main() {
		Class_1 c_1 = new Class_1();
		Class_2 c_2 = new Class_2();
		Class_3 c_3 = new Class_3();

		m2(c_1);
		m2(c_2);
		// m2(c_3);	// Is not passed by the compiler (wrong type)
	}
}

interface Combinable {
	public void m1();
}

interface Property_12 extends Combinable {}
interface Property_13 extends Combinable {}
interface Property_23 extends Combinable {}
interface Property_123 extends Combinable {}

class Class_1 implements Property_12, Property_13, Property_123 {
	@Override
	public void m1() {
		System.out.println("Property (1,2)");
		System.out.println("Property (1,3)");
		System.out.println("Property (1,2,3)");
	}
}

class Class_2 implements Combinable, Property_12, Property_23, Property_123 {
	@Override
	public void m1() {
		System.out.println("Property (1,2)");
		System.out.println("Property (2,3)");
		System.out.println("Property (1,2,3)");
	}
}

class Class_3 implements Combinable, Property_13, Property_23, Property_123 {
	@Override
	public void m1() {
		System.out.println("Property (1,3)");
		System.out.println("Property (2,3)");
		System.out.println("Property (1,2,3)");
	}
}

Warum bin ich mit dieser Lösung nicht zufrieden?
Es geht mir an sich nicht um einen konkreten Fall, sondern um ein allgemeines Problem.
Die Anzahl der Interfaces, die man erstellen muss, schießt schnell in die Höhe:

Kombinations-Möglichkeiten = Potenzmenge der Menge aller Klassen

=> |P(K)| = 2^|K|​

Wenn die Interfaces/Gruppierungen, wie in diesem Fall, nach einem bestimmten System aufgebaut sind, muss es doch eine Möglichkeit geben, das Ganze eleganter zu lösen, als für jede Gruppe ein Interface zu schreiben. Der Aufwand 2^|K| Interfaces zu erstellen ist schon enorm groß und sollte sich zumindest reduzieren lassen.
Will man nun noch mehrere Eigenschaften zusammenfassen, steht man wieder vor dem gleichen Problem. Man müsste für jede Kombination von Interfaces, die eine Eigenschaft beschreiben, erneut ein Interface erstellen:

|P(P(K))| = 2^2^|K|​

Bewältigt man den riesigen Schreibaufwand, kann man dafür, Objekte mit mehreren Eigenschaften übergeben.

Ich hoffe, meine Formulierung ist einigermaßen verständlich und es gibt den ein oder anderen interessanten Vorschlag.

 

[bERt0r]

Also per OO Definition sind Eigenschaften von Klassen Membevariablen. Eine Eigenschaft sollte nur dann eine Klasse definieren, wenn sie etwas wesentliches von ihrer Funktionalität bestimmt.
Dein "Problem" was du hier beschreibst ist ja gerade der Grund warum es die Generalisierung in OO gibt. Von Klassen werden doch nur Methoden ausgeführt. Du kannst von Klassen erben und dann die Methode überschreiben, sodass sie eben auf bestimmte Parameter anders reagiert.

 

[Codeschnipsel]

Der Begriff Eigenschaft ist eventuell etwas ungünstig gewählt. In meinem Fall ist eher etwas anderes darunter zu verstehen, wie per OO Definition. Dafür einen passenden Begriff zu finden ist gar nicht so leicht. Eventuell sollte man besser Eigenheit sagen. Die Klassen einer Gruppe bringen eine bestimmte Eigenheit mit sich.

Diese Eigenheit hängt eben nicht von Klassen-/Membervariablen oder irgendwelchen gegebenen Werten ab. Man könnte vermutlich eine Variable erstellen, die diese Eigenheit widerspiegelt, aber dann besteht immer noch das Problem, dass der Compiler meckern müsste, wenn versucht wird, ein ungültiges Objekt an eine Methode zu übergeben (siehe Zeile 13). In so einem Fall dürfte der Code gar nicht erst compiliert werden.

 

[bERt0r]

Das klingt jetzt so, als ob du einfach nur Generics verwenden müsstest.

 

[Codeschnipsel]

Kannst du mein Codebeispiel denn mit Generics entsprechend abändern?

 

[Codeschnipsel]

Entschuldigt den Doppelpost, aber mit Generics lässt sich die Anzahl der Interfaces zumindest halbieren, genauer gesagt gibt es statt

2^n

nur noch

2^(n-1) - 1

Interfaces.

 

[bERt0r]

Ich bin mir nicht sicher ob es das ist was du willst, aber schau mal:

interface Property<T>
	{
		public void printProperty();
	}
	
	class PropertyInteger implements Property<Integer>
	{
		int i=0;
		@Override
		public void printProperty() {
			System.out.println(i);	
		}		
	}
	
	class Farbe
	{
		int r,g,b;
	}
	
	class PropertyFarbe implements Property<Farbe>
	{
		Farbe f=new Farbe();
		@Override
		public void printProperty() {
			
			System.out.println(f.r+" "+f.g+" "+f.b);
		}
		
	}
	
	class FarbeMitNamen extends Farbe
	{
		String name="Schwarz";
	}
	
	class PropertyFarbeMitNamen implements Property<FarbeMitNamen>
	{
		FarbeMitNamen f=new FarbeMitNamen();
		@Override
		public void printProperty() {
			System.out.println(f.name+" "+f.r+" "+f.g+" "+f.b);
			
		}
		
	}


public class PropertyBsp
{
	 public static void m2(Property <?extends Farbe> prop) {
	       prop.printProperty();
	    }
	 public static void m1(Property<?> prop)
	 {
		 prop.printProperty();
	 }
	    
	    public static void main(String args[]) {
	        PropertyInteger pi=new PropertyInteger();
	        PropertyFarbe pf=new PropertyFarbe();
	        PropertyFarbeMitNamen pf2=new PropertyFarbeMitNamen();
	 
	        System.out.println("m1");
	        m1(pi); 
	        m1(pf);
	        m1(pf2); 
	        
	        System.out.println("m2");
	        //m2(pi);    Is not passed by the compiler (wrong type)
	        m2(pf);
	        m2(pf2); 
	    }
}

 

[Codeschnipsel]

Sieht schon ganz gut aus und ist auch das, was ich insgesamt möchte. Leider ist es nicht weniger Aufwand. Dafür ist deine Variante übersichtlicher.

Wenn ich es um diese Uhrzeit noch richtig interpretiert habe, machst du an sich nichts anderes, wie Schachteln. Es entstehen dabei genauso viele Interfaces/Klassen (insgesamt egal, was man nimmt), wie bei meiner Variante. Den Gedanken hatte ich auch schon. Allerdings habe ich mich aus unterschiedlichen Gründen dagegen entschieden. Wobei Übersichtlichkeit dafür sprechen würde, wie wir gerade festgestellt haben.

Ich habe mal so einen Kombinations-Baum, wie er bei dir auch entsteht (für |K| = 3) gezeichnet:

     |-- P1 --|
     |        |-- P12 --|
     |   P2 --|         |-- P123
P13--|    |___          |
     |        |-- P23 --|
     |-- P3 --|

Wenn man deine Klassennamen einträgt, sieht der Baum so aus:

     |-- FarbeMitNamen --|
     |                   |-- Farbe --|
     |        P2 --------|           |-- P123
P13--|         |_________            |
     |                   |--- P23 ---|
     |---- Integer ------|

Du hast also nicht alle Kombinationsmöglichkeiten implementiert. Es würde aber auf den gleichen Aufwand hinauslaufen. Eigentlich werden es sogar noch mehr Interfaces/Klassen. Denn die Interfaces/Klassen, die nur von einer einzigen Klasse implementiert werden (FarbeMitNamen und Integer), kann man weg lassen/sind nicht nötig. Stattdessen kannst du bei der Funktion direkt den Klassennamen als Typ angeben.

Naja, bei dieser Variante entstehen, wie gesagt auch

2^|K|

Interfaces. Bei der Folgenden nur

2^(|K|-1) - 1

(habe den Code auf 4 Klassen erweitert, damit man sieht, wie schnell das Ganze extrem komplex wird):

public class Example {
	public static void f12(GI2_1<Class_1, Class_2> p_12) {
		p_12.all();
	}

	public static void main(String[] args) {
		Class_1 c_1 = new Class_1();
		Class_2 c_2 = new Class_2();
		Class_3 c_3 = new Class_3();
		Class_4 c_4 = new Class_4();

		f12(c_1);
		f12(c_2);
		// f12(c_3); // Is not passed by the compiler (wrong type)
		// f12(c_4); // Is not passed by the compiler (wrong type)
	}

}

/*
 *  Alle kombinierbaren Klassen besitzen diese Methode.
 *  Beim Aufruf der Methode sind jedoch die Eigenschaften der Klassen zu beachten, die diese Methode implementiert.
 */
interface Combinable {
	public void all();
}

/*
 * Alle Klassen, die eine Eigenschaft besitzen, müssen dieses Interface implementieren
 */
interface Element {}

/*
 * GIe_n:  GI = Generic Interface (steht für eine Eigenschaft)
 *          e = Anzahl der Elemente/Klassen, die das Interface implementieren
 *          n = Nummer der Eigenschaft (nötig, da von jedem Interface nur einmal geerbt werden kann)
 */
interface GI2_1<K1 extends Element, K2 extends Element> extends Combinable {}
interface GI2_2<K1 extends Element, K2 extends Element> extends Combinable {}
interface GI2_3<K1 extends Element, K2 extends Element> extends Combinable {}
interface GI3_1<K1 extends Element, K2 extends Element, K3 extends Element> extends Combinable {}
interface GI3_2<K1 extends Element, K2 extends Element, K3 extends Element> extends Combinable {}
interface GI3_3<K1 extends Element, K2 extends Element, K3 extends Element> extends Combinable {}
interface GI4_1<K1 extends Element, K2 extends Element, K3 extends Element, K4 extends Element> extends Combinable {}

class Class_1
		implements
		Element,
		// 2-elements
		GI2_1<Class_1, Class_2>, GI2_2<Class_1, Class_3>,
		GI2_3<Class_1, Class_4>,
		// 3-elements
		GI3_1<Class_1, Class_2, Class_3>, GI3_2<Class_1, Class_2, Class_4>,
		GI3_3<Class_1, Class_3, Class_4>,
		// 4-elements
		GI4_1<Class_1, Class_2, Class_3, Class_4>
{
	@Override
	public void all() {
		System.out.println("Property (1,2)");
		System.out.println("Property (1,3)");
		System.out.println("Property (1,2,3)");
	}
}

class Class_2
		implements
		Element,
		// 2-elements
		GI2_1<Class_1, Class_2>, GI2_2<Class_2, Class_3>,
		GI2_3<Class_2, Class_4>,
		// 3-elements
		GI3_1<Class_1, Class_2, Class_3>, GI3_2<Class_1, Class_2, Class_4>,
		GI3_3<Class_2, Class_3, Class_4>,
		// 4-elements
		GI4_1<Class_1, Class_2, Class_3, Class_4>
{
	@Override
	public void all() {
		System.out.println("Property (1,2)");
		System.out.println("Property (2,3)");
		System.out.println("Property (1,2,3)");
	}
}

class Class_3
		implements
		Element,
		// 2-elements
		GI2_1<Class_1, Class_3>, GI2_2<Class_2, Class_3>,
		GI2_3<Class_3, Class_4>,
		// 3-elements
		GI3_1<Class_1, Class_2, Class_3>, GI3_2<Class_1, Class_3, Class_4>,
		GI3_3<Class_2, Class_3, Class_4>,
		// 4-elements
		GI4_1<Class_1, Class_2, Class_3, Class_4>
{
	@Override
	public void all() {
		System.out.println("Property (1,3)");
		System.out.println("Property (2,3)");
		System.out.println("Property (1,2,3)");
	}
}

class Class_4
		implements
		Element,
		// 2-elements
		GI2_1<Class_1, Class_4>, GI2_2<Class_2, Class_4>,
		GI2_3<Class_3, Class_4>,
		// 3-elements
		GI3_1<Class_1, Class_2, Class_4>, GI3_2<Class_1, Class_3, Class_4>,
		GI3_3<Class_2, Class_3, Class_4>,
		// 4-elements
		GI4_1<Class_1, Class_2, Class_3, Class_4>
{			
	@Override
	public void all() {
		System.out.println("Property (1,3)");
		System.out.println("Property (2,3)");
		System.out.println("Property (1,2,3)");
	}
}

Bin mit dieser Lösung noch nicht zufrieden. Auch wenn man sie übersichtlicher gestalten würde. Es sind /bleiben einfach zu viele Interfaces!

 

[bERt0r]

Richtig, du willst ja Klassen einsparen. Hier mal ein anderer Ansatz:

class Farbe
{
	int r,g,b;

	public String toString()
	{
		return r+" "+g+" "+b;
	}
}

class FarbeMitNamen extends Farbe
{
	String name="Schwarz";
	public String toString()
	{
		return name+" "+super.toString();
	}
}

class Property<T> 
{
	T object;
	Property(T t)
	{
		object=t;
	}

	public void printProperty() {

		System.out.println(object);
	}

}

public class PropertyTest
{
	public static void m2(Property<? extends Farbe> prop) {
		prop.printProperty();
	}
	public static void m1(Property<?> prop)
	{
		prop.printProperty();
	}

	public static void main(String args[]) {
		Property<Integer> pi=new Property<Integer>(new Integer(5));
		Property<String> ps=new Property<String>("Hallo Welt");
		Property<Farbe> pf=new Property<Farbe>(new Farbe());
		Property<FarbeMitNamen> pf2=new Property<FarbeMitNamen>(new FarbeMitNamen());

		System.out.println("m1");
		m1(pi); 
		m1(ps);
		m1(pf); 
		m1(pf2);
		System.out.println("m2");
		//m2(pi); 	Error
		//m2(ps);	Error
		m2(pf);
		m2(pf2);
	}
}

 

[Codeschnipsel]

Was in den Klassen/Interfaces drin steht ist ja vorerst mal egal. Es geht lediglich um die Gruppierungen. Und da will ich alle Kombinationsmöglichkeiten haben. Zudem kann man nicht davon ausgehen, dass meine gruppierbaren Klassen vordefinierte Klassen, wie String oder Integer sind.

Bei deinem Beispiel kann man das Generic weglassen. Stattdessen kann man direkt das Interface/die Klasse als Typ angeben. Ich habe dein Beispiel mal ohne Generic aber mit Vererbung geschrieben bzw. es entsprechend abgeändert. Vordefinierte Klassen hab ich aus dem Beispiel entfernt und zum besseren Verständnis andere Klassen hinzugefügt. Jedoch sind hier auch nicht alle Kombinationsmöglichkeiten implementiert:

class Farbe implements HasProperty {
	int r, g, b;

	public String toString() {
		return r + " " + g + " " + b;
	}
	
	@Override
	public void propertyFunction() {
		System.out.println("Ich besitze eine Eigenschaft Farbe.");
	}
}

class FarbeMitNamen extends Farbe {
	String name = "Schwarz";

	public String toString() {
		return name + " " + super.toString();
	}
}

interface HasProperty {
	void propertyFunction();
}

class IHaveAProperty implements HasProperty {
	@Override
	public void propertyFunction() {
		System.out.println("Ich besitze eine Eigenschaft, aber ich kann dir nicht sagen welche :D.");
	}
}

class NoProperty {}

public class PropertyTest {
	public static void m2(Farbe prop) {
		System.out.println(prop);
		prop.propertyFunction();
	}

	public static void m1(HasProperty prop) {
		System.out.println(prop);
		prop.propertyFunction();
	}

	public static void main(String args[]) {
		Farbe pf = new Farbe();
		FarbeMitNamen pf2 = new FarbeMitNamen();
		IHaveAProperty ihap = new IHaveAProperty();
		NoProperty np = new NoProperty();
		
		System.out.println("m1");
		m1(pf);
		m1(pf2);
		m1(ihap);
		// m1(np); Error
		System.out.println("m2");
		m2(pf);
		m2(pf2);
		// m2(ihap); Error
		// m2(np); Error
	}
}

Wie du siehst/sehen solltest, ist es so ziemlich das Gleiche. Aber das fällt noch besser auf, wenn man eine dritte Klasse ins Boot holt und alle Kombinationsmöglichkeiten bildet.

Hierzu habe ich ein Beispiel geschrieben. Der Baum dazu sieht folgendermaßen aus:

            |-- Eisbär ------|
            |                |-- Weiß -----|
            |   Schwan ------|             |-- Tier
Säugetier --|      |_________              |
    |       |                |-- Fliegen --|
    |       |-- Fledermaus --|             |
    |______________________________________|

Nun der zugehörige Code:

public class TierEigenschaften {

	public static void weissesTier(Weiss w) {
		w.shout();
	}
	
	public static void tier(Tier t) {
		t.shout();
	}

	public static void main(String[] args) {
		Eisbaer e = new Eisbaer();
		Schwan s = new Schwan();
		Fledermaus f = new Fledermaus();
		
		weissesTier(e);
		weissesTier(s);
		// weissesTier(f); // Error
		tier(e);
		tier(s);
		tier(f);
	}

}

interface TierEigenschaftBehaftet {
	public void shout();
}

interface Weiss extends Tier {}
interface Fliegen extends Tier {}
interface Saeugetier extends Tier {}
interface Tier extends TierEigenschaftBehaftet {}

class Eisbaer implements Weiss, Saeugetier {
	@Override
	public void shout() {
		System.out.println("Eisbär: Ich bin ein weißes Säugetier.");
	}
}

class Schwan implements Weiss, Fliegen {
	@Override
	public void shout() {
		System.out.println("Schwan: Ich bin weiß und kann fliegen.");
	}
}

class Fledermaus implements Fliegen, Saeugetier {
	@Override
	public void shout() {
		System.out.println("Fledermaus: Ich bin ein fliegendes Säugetier.");
	}
}

Verdammt, ich habe mich bei meiner vorherigen Antwort geirrt. Meine Variante mit Generics, wo ich gemeint habe, dass sie nur

2^(|K|-1) - 1

anstatt

2^|K|

braucht, ist falsch/funktioniert nicht. Ausschlaggebend ist unter anderem dieses Problem:

Class_1 implements GI2_1<Class_1, Class_3>
Class_1 implements GI2_2<Class_1, Class_3>

Außerdem lautet die Anzahl generell schon

2^(|K|-1) - 1

. Bei der trauriger Weise falschen Variante mit Generics wäre es also

2^(|K|-2) - 1

gewesen.

 

[Codeschnipsel]

Mir ist gerade ein weiterer Fehler an meiner Formel aufgefallen
Nachdem man die einelementigen Mengen (und die leere Menge) ignorieren kann, da diese bereits durch die Klasse selbst repräsentiert werden, ändert sich die Formel wie folgt:

|P(C) \ ({ {x} : x in C } vereinigt "Leere Menge")| = |P(C)| - |C| - 1 = 2^|C| - |C| - 1

Ps: Kann man seine Beiträge nicht bearbeiten?