vererbung, kinder einer instanz.

[dermoritz]

ich hab 2 klassen wobei die eine kinder der anderen ist. beim instanziieren der kinder wird ja auch immer eine instanz der mutter gebildet.

in meinem fall soll die mutterinstanz aber immer die selbe sein. d.h. nicht nur die attribute sollen dieselben sein sondern die ganze instanz.
die kinder haben natürlich attribute die unterschiedlich sind. ich hätte also gerne eine vererbung zur laufzeit. eine mutterinstanz mit vielen kinderinstanzen.

wie macht man denn sowas?

 

[maki]

wie macht man denn sowas?

Nicht über Vererbung, am besten gar nicht.

"Eine Mutterinstanz mit vielen kinderinstanzen" klingt für mich daneben
Warum denn nur eine "Mutterinstanz"?

Wenn du Attribute hast die für alle Instanzen gelten sollen, mach sie static.

 

[Marco13]

:shock: Uh-hu - VORSICHT mit der Empfehlung, etwas static zu machen, "weil man dann so praktisch drauf zugreifen kann" :noe: Fields sollte man nur static machen, wenn man sie unbedingt static machen muss - und das muss man "fast nie"....

Kling eher, als wäre das Problem, dass dort Vererbung verwendet wird, obwohl eher Aggregation oder Komposition verwendet werden sollte.

 

[maki]

>> Uh-hu - VORSICHT mit der Empfehlung, etwas static zu machen, "weil man dann so praktisch drauf zugreifen kann"

Das war nicht meine Empfehlung

 

[ARadauer]

obwohl eher Aggregation oder Komposition verwendet werden sollte

finde ich auch

mach dir ein Fabriksklasse, immer wenn du ein "kind" brauchst, lässt du dir von der Fabrik eins erstellen. diese erstellt das kind und setzt die mutter rein...
ungefähr so:

    private static Mutter mutter;
    public static Kind generateKind(){
       if(mutter == null)
          mutter = new Mutter();
       Kind k = new Kind();
       k.setMutter(mutter);
       return k;
    }

 

[dermoritz]

danke für die tips, die frage ist nun welchen weg ich einschlage.
im moment ist das ganze mit vererbung realisiert, wobei die mutterklasse bestimmte eigenschaften und methoden an die kinder vererbt.
mir fällt gerade ein, das einige eigenschaften der mutter durch die kinder manipuliert werden! d.h. meine eigentliche frage ist damit ist damit nichtig.
oder sollten die kinder die eigenschaften nicht manipulieren sondern eigene attribute dafür besitzen? irgendwas muss ich auf jedenfall an der struktur ändern denke ich. deswegen würde mich trotzdem interessieren wie man aggregation und komposition in java umsetzt. der vorschlag mit der fabrikmethode gefällt mir auch ganz gut. wie realisiert man die "setMutter" methode bzw. was macht diese? alle attribute setzen?


wenn mir ein beispiel einfällt was diese 2 klassen gut darstellt werd ich es hier reinschreiben. meine 2 klassen sind zu speziell um sie hier erläutern zu können.

edit:
mal soviel: meine kindklasse greift auf bestimmte attribute und methoden der mutterklasse zu und manipuliert einige attribute und bringt einige eigene atribute mit.
praktisch ruft der kind konstrukteur -)) den eltern konstruktuer auf um danach darauf einige methoden loszulassen.
ich hab vererbung gewählt, weil ich mit den kindern genau wie mit den eltern arbeiten kann also die instanzen werden ab dem moment ihrer instanziierung wie ein eltern instanz behandelt und nur bei bedarf werden kind spezifische eigenschaften benötigt (alle kinder methoden sind "private")

 

[Final_Striker]

wie realisiert man die "setMutter" methode bzw. was macht diese? alle attribute setzen?

{

public class Kind()
{
   Mutter mutter;

   public Mutter setMutter(Mutter mutter)
   {
       this.mutter = mutter;
   }
}

[/quote]

vielleicht solltest du erst mal erklären, was du genau machen willst, damit dir auch geholfen werden kann.

 

[ARadauer]

bei vererbung, ist das kind eine mutter,
mutter hat namen -> kind hat namen

bei aggregation bzw kompostion hat das kind eine mutter als member

striker hat recht, erklär mal was du vor hast...

 

[dermoritz]

mir fällt leider kein gutes beispiel ein. nochmal ein allgemeiner erklärungsversuch: (wenn mir ein beispiel einfällt geb ich es an)

mein kindklasse spezifiziert die mutterklasse etwas genauer. mit zusätzlichen eigenschaften und manipuliert eben einige eigenschaften der mutter. einige eigenschaften sind aber zumindest für eine gruppe von kindern immer gleich (eben allgemeine eigenschaften der gruppe).
die mutterklasse muss auch alleine instanziiert werden können. die kinder sind also spezialisierte varianten der mutter. deswegen bin ich auf den trichter mit "extends" gekommen.

theoretisch könnte ich die speziellen eigenschaften und manipulierenden methoden der kinder auch komplett in die mutter integrieren - dann verlöre ich aber die modularität.

mich stören also nur noch bestimmte eigenschaften die bei einer gruppe von kindern immer gleich sind und gleich bleiben. die frage wäre inwieweit z.b. ein deklarieren dieser eigenschaften mit "static" sinn macht. und wann und wie diese statischen eigenschaften gesetz werden. werden diese bei jedem aufrufen des konstruktors neu gesetzt oder nur beim erstmaligen aufrufen?
also würde es reichen vor die allgemeinen klasseneigenschaften die durch die kinder nicht manipuliert werden (sollen) ein "static" zu schreiben oder muss man noch andere dinge ändern?

 

[Marco13]

mir fällt leider kein gutes beispiel ein. nochmal ein allgemeiner erklärungsversuch: (wenn mir ein beispiel einfällt geb ich es an)

Wie wär's mit dem, das du zu lösen versuchst? :roll:

mich stören also nur noch bestimmte eigenschaften die bei einer gruppe von kindern immer gleich sind und gleich bleiben. die frage wäre inwieweit z.b. ein deklarieren dieser eigenschaften mit "static" sinn macht.

Aus genau diesem Grund eben NICHT: Die Eigenschaften wären dann IMMER und für ALLE Kinder gleich - da ist nichts mehr mit "Gruppen".

Man kann jetzt mit irgendwelchen möglichen Klassenstrukturen ankommen und weiter im trüben stochern,
interface ChildGroup, class Mother implements ChildGroup
class PropertiesThatAreCommonForSomeChildren, class Child { private PropertiesThatAreCommonForSomeChildren p; }
...
aber du kannst immer sagen ... "Ja neeee... fast, aber nicht ganz.....". Mir persönlich ist das jetzt dann zu albern...

 

[dermoritz]

das problem ist mein konkretes problem so aufzubereiten das man versteht wofür man das alles braucht. aber ich kanns ja mal versuchen:

es geht allgemein um das testen von software. ein solcher 'test' besteht aus einer testspezifikation (meine mutterklasse) diese spezifikation wird aus einer xml datei erstellt. in erster linie werden aus der xml datei alle eingangs parameter für das zu testende stück software extrahiert. und es werde für jeden eingangs parameter die zu testenden werte (z.b. ein representant aus jeder äquivalenzklasse) extrahiert.
daraus wiederum kann man eine stimulationsdatei erzeugen welche jedwede kombination von eingabedaten für das zu testende stück software erzeugt.

man kann aber auch einen vollständigen test durchführen (eben nicht nur die stimulation mit allen kombinationen erzeugen) in dem man testfälle (meine kindklasse) spezifiziert. hier werden bestimmte eingabe größen auf einen fixen wert gesetzt zusätzlich kommen aber noch referenzen für die gewünschten ausgangsdaten werte hinzu. alle nicht gesetzten werte werden wieder durchkombiniert.
d.h. eine solche kindklasse manipuliert die daten die zur stimulationserzeugung nötig sind bevor die stimulationsdatei erzeugt wird.

sehr viele eigenschaften wie z.b. der name des zu testenden stücks software oder die einheiten der eingangswerte oder deren min und maxwerte sind für alle "testfälle" die zu einer "testspezifikation" gehören gleich.

im moment würde für jeden testfall auch eine testspezifikation (beim erzeugen eines testfalls wird der mutterkonstrukter aufgerufen der die xml datei parst) erzeugt das finde ich irgendwie unschön.

es läuft natürlich auch so, da das aber mein erstes projekt in java is will ich gleich noch was lernen und es auch vernünftig machen.

ich hoffe die erklärung verwirrt nicht nochmehr es gibt wahrscheinlich bessere beispiele das proble/die struktur zu beschreiben.

 

[Marco13]

Warum trennst du dann nicht Testspezifikation und eingabe/ausgabe?

class TestSpecification 
{
    // Spezifikationsdaten
}

class InputTest extends TestSpecification 
{
    // Eingabedaten
}

class InputOutputTest extends InputTest
{
    // Ausgabedaten
}

 

[dermoritz]

genau das hab ich befürchtet, dass ihr euch gedanken über das problem selbst macht und nicht um die struktur bzw. meine frage.
jetzt könnte ich anfangen den test und die testprozedur genauer zu beschreiben aber eben das will ich vermeiden (das ist alles nicht innerhalb eines threads zu erklären.)

also die struktur ist wie sie ist mir geht es wirklich nur um das verhältnis von testspezifikation und testfall. bzw. um allgemeine möglichkeiten sowas in java zu modellieren - wie eben vererbung (mit welchen modifiern an welchen stellen auch immer) oder die erwähnte aggregation und kompostion.

(aber nun doch eine kurze erklärung für die frage warum ein und ausgabe nicht getrennt ist: das liegt an dem testsystem selbst was die stimulationsdatei "frisst" - dort wird nicht explizit zwischen ein und ausgabe getrennt.)

 

[Marco13]

Tja, dann soll sich da eben derjenige Gedanken drüber machen, der dafür bezahlt wird.

 

[dermoritz]

wird hier jemand bezahlt? also ich nicht - es geht um meine diplomarbeit.

 

[Landei]

DIPLOMARBEIT? Keine Verarsche, das ist wirklich für eine DIPLOMARBEIT???



Hoffentlich nicht in Informatik oder so. Ansonsten: Armes Deutschland!

 

[maki]

Komposition, Aggregation, Factory, etc. pp.

Hast doch genügend Tipps bekommen, google ist voll von Seiten die jedes dieser Themen erklären.

Wenn du keine konkreteren Fragen stellst bekommst du eben nur allgemeine Antworten

 

[Marco13]

Offenbar gab es da ein Problem, das gelöst wurde, und durch die Lösung trat ein anderes Problem auf (das zu diesem Thread geführt hat). Dass jetzt letzteres gelöst werden soll, statt das erste richtig zu lösen, ist so ein Schema, das immer wieder auftritt. Manchmal muss man einen Schritt zurückgehen, feststellen: "Aha, so ging es also nicht" und sich eine andere Lösung überlegen. Ob das bei dir auch der Fall ist kann ich nicht beurteilen, aber dass du eine Lösung für ein abstraktes Problem haben willst, das du dir vermutlich(!) durch die suboptimale Lösung eines anderen Problemes selbst geschaffen hast, ist nicht gerade eine Motivation für Antworten...

 

[maki]

Am Rande fällt mir noch ein, dass ein Framework für Tests am besten Testgetrieben geschireben werden sollte

 

[dermoritz]

wieso gleitet das ganze plötzlich in eine metadiskussion ab? genau deswegen hab ich mich so geziert mein konkretes beispiel zu beschreiben - ich werds nie wieder tun :-|.



zum thema:

nochmal zum anfang: es gibt eigentlich gar kein problem. nur fand ich es irgendwie verschwenderisch für mehrere instanzen einer klasse die bestimmte werte für bestimmte attribute teilen, diese werte mit der instanz zu speichern. ich würde sie gerne mit der klasse speichern.

und da ich in java nicht so bewandert bin hab ich mir erlaubt zu fragen wie man soclhe klassen eigenschaften (insebsondere in meinem fall) definiert und wann und wie man sie setzt. denn in meinem fall ist es ja keine echte klasseneigenschaft sondern eine gemeinsame eigenschaft einer gruppe von instanzen. (mit "vererbung" hab ich da halt an die mutter gedacht die solche eigenschaften speichern könnte)
aber offensichtlich kann eine mutter(instanz) nicht mehrere kinder(instanzen) haben. es wäre echt praktisch wenn man einen konstrukteur der kindklasse schreiben könnte der als parameter eine mutterinstanz nimmt und so nicht den super konstrukteur aufrufen muss sondern eben die gegebene instanz verwendet.

konkret frage ich mich z.b. ob es sinn macht solche eigenschaften als static zu deklarieren. dann hätten alle instanzen den selben wert, aber bei jedem aufrufen des konstruktors würde diese mit dem gleichern wert wieder überschrieben werden? das kann man nur abfangen mit if(eigenschaft)!=null, oder?

 

[Marco13]

Nunja. Im mal KOMPLETT "meta" zu werden: Wenn in einem Handwerker-Forum jemand sagt "Immer wenn ich mit einer Kaffeetasse einen Nagel in die Wand haue, geht die Tasse kaputt, was kann ich dagegen tun?" dann ist doch die Empfehlung "Nimm einen Hammer" näher liegend, als die Empfehlung "Nimm' eine Tasse aus Kohlefaserverstärktem Kunststoff".

Da hat neulich jemand einen passenden Link gepostet: http://thedailywtf.com/Articles/The_Complicator_0x27_s_Gloves.aspx

Wie auch immer. Pack' doch das, was sich nie ändert, in eine kleine Klasse.

class Kohlefaserverstärkung
{
    int foo;
    int bar;
}

class Mother
{
    private Kohlefaserverstärkung commonParameters;

    void addChild(Child child)
    {
        child.commonParameters = this.commonParameters
    }
}

 

[ARadauer]

also die struktur ist wie sie ist mir geht es wirklich nur um das verhältnis von testspezifikation und testfall. bzw. um allgemeine möglichkeiten sowas in java zu modellieren - wie eben vererbung (mit welchen modifiern an welchen stellen auch immer) oder die erwähnte aggregation und kompostion.

aggregation oder komposition (der unterschied ist ja vollkommen egal) sind einfach wörter die man halt gerne in diplomarbeiten schreibt... das heißt ja nur das ein objekt aus einem anderen besteht...

mal grob, wenn zwei objekte gleiche attribute haben, ist es oft sinnvoller, diese attribute nicht zu vererben sondern zu kapseln
also testspezifikation und testfälle habe attribute für "das zu testende stück software " gemeinsam, warum machst du dann aus "das zu testende stück software " nicht eine eigene klasse die diese beiden als member haben...

in diese richtung würde ich gehen...

 

[ARadauer]

aja junit ist open source, vielleicht kannst du da ein bissal klauen ;-)

 

[maki]

@moritz
Das hier könnte dich interessieren

 

[dermoritz]

dann mal danke, das paper werd ich mir mal anschauen. insgesamt bleibt festzustellen das erste projekt in einer neuen programmiersprache ist selten ein vorzeige projekt. man muss nur zusehn, dass das nächste projekt in dieser sprache besser wird. dabei habt ihr mir auf jedenfall geholfen.
ob ich meinen derzeitigen code noch stärker umstrukturiere ist zweifelhaft, zumal das programm ja nur das pinzipielle funktionieren der theorie der diplomarbeit zeigen soll.

 

[Wildcard]

Das erste Projekt ist normalerweise kein Vozeigeprojekt, das ist schon richtig.
Du schreibst aber eine Diplomarbeit und da ist das Vorzeigbare wichtiger als das Funktionale.
Gib dir Mühe, ein schlechtes Design riecht jeder halbwegs brauchbare Dozent auf 10 Meter Entfernung und es wiegt schwere als eine unfertige Implementierung.
Denn:
Die fehlenden Stücke lassen sich ergänzen, beim schlechten Design ist Hopfen und Malz verloren und das Ding für die Tonne.