Klasse vererben und Eigenschaften übergeben
Alexander Widera
ich will eine Klasse schreiben die eine Grundfunktionalität hat (irgendetwas
ausführen). Jedoch fehlen dazu noch eine Menge Parameter, die je nach
Anwendungszweck konstant in der Klasse vorhanden seien sollen.
Deshalb habe ich mir gedacht, dass ich eine abstrakte Klasse schreibe, die
Parameter null setze und anschließend, je nach Anwendungszweck, eine Klasse
davon ableite in der ich die Parameter fest setze.
Irgendwie will das bei mir nicht funktionieren. Könnte mir jemand ein
korrektes Beispiel geben?
Außerdem habe ich noch ein Problem. Ich habe eine zweite Klasse mit
Funktionen, die instanzen der obigen Klasse benötigen, aber mit(!) den
Parametern und nicht die "Grundklasse". Irgendwie habe ich dabei auch
Probleme das zu realisieren.
Danke für Hilfe,
Alex
Elmar Boye
Alexander Widera <aw...@hrz.tu-chemnitz.de-novaliddomainpleasedeletethispart.de> schrieb ...
> ich will eine Klasse schreiben die eine Grundfunktionalität hat
> (irgendetwas ausführen). Jedoch fehlen dazu noch eine Menge
> Parameter, die je nach Anwendungszweck konstant in der Klasse
> vorhanden seien sollen.
> Deshalb habe ich mir gedacht, dass ich eine abstrakte Klasse
> schreibe, die Parameter null setze und anschließend, je nach
> Anwendungszweck, eine Klasse davon ableite in der ich die Parameter
> fest setze.
Darunter kann man sich nun alles Mögliche vorstellen...
> Irgendwie will das bei mir nicht funktionieren.
> Könnte mir jemand ein korrektes Beispiel geben?
... und so ist das mit einem Beispiel so eine Sache.
Etwas wie
public abstract class ClassA
{
public abstract void MethodeA();
}
public class ClassB : ClassA
{
public override void MethodeA() { /* Tut hier was */ }
}
hilft wohl kaum weiter.
Zumal "eine Menge Parameter" den Verdacht auf Designsünden
aufkommen lassen, ohne das endgültig unterstellen zu wollen.
Vielleicht findest Du über
http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
Eine Gegenindikationsliste:
http://en.wikipedia.org/wiki/Anti-pattern
> Außerdem habe ich noch ein Problem. Ich habe eine zweite Klasse mit
> Funktionen, die instanzen der obigen Klasse benötigen, aber mit(!) den
> Parametern und nicht die "Grundklasse".
ist oben bei ClassA alles abstrakt wäre das zunächst kein Problem.
Doch wie bereits angedeutet, sieht das ziemlich verdächtig aus.
Es wäre besser Du würdest Dein Problem weniger abstrakt ausdrücken
und etwas konkreter in die Details gehen.
Gruss
Elmar
Boris
Wenn ich dich richtig verstehe ist eine abstarkte Klasse nicht
notwendig, der Sinn einer abstrakten Klasse ist ua. die Möglcihkeit
abstrakte Methoden definieren zu können die in
den jeweils von ihr abgeleiteten Klassen überschrieben (override)
werden müssen.
public class Grundklasse
{
protected int param_1 = -1;
protected Object param_2 = null;
}
public class Kind_1 : Grundklasse
{
public Kind_1()
{
param_1 = 999;
param_2 = ne Object();
}
}
zu Prob2:
public class EineKlasse
{
public void EineMethode( Grundklasse gk)
{
....
}
}
deren Aufruf sieht dann eben so aus:
eK ( eine Instanz der Klasse EineKlasse)
eK.EineMethode( new Kind_1());
Alexander Widera
Das ist was ich machen will:
Ich möchte Klassen schreiben, die eine Vorlage für die weitere Arbeit sind.
In ihr sind Grundfunktionen implementiert, diese erweitert und/oder ersetzt
werden können.
Diese Grundklassen benutzen auch Funktionen untereinander. Letztendlich
sollen aber die Funktionen von den abgeleiteten Klassen genutzt werden.
Hier ein Beispiel:
public abstract class Klasse1Vorlage
{
public string testtext = null;
}
public abstract class Klasse2Vorlage
{
public virtual string macheEtwas()
{
// hole testtext von Objekt von Klasse1 (nicht Vorlage) und
gebe diesen aus
}
}
public class Klasse1 : Klasse1Vorlage
{
public string testtext = "mein neuer testtext";
}
public class Klasse2 : Klasse2Vorlage
{
public string macheEtwasAnderes()
{
// gebe etwas aus
}
}
Man soll nun z.B. ein Objekt der Klasse2 erzeugen können und die Funktion
"macheEtwas()" aufrufen können ... sie sollte den testtext aus einem Objekt
der Klasse1 ausgeben... außerdem sollte noch funktionieren, dass man noch
die neue Funktion macheEtwasAnderes() ausführen kann.
Habe ich es relativ verständlich erklärt, was ich vor habe?
Ich habe schon irgendwie mit Interfaces rumgebastelt, aber noch keine Lösung
gefunden. Mir fehlt die Struktur, wie und wo ich anfangen soll.
Danke für Hilfe,
Alex
Mark Spahn
Du hast nun recht "abstrakt" :-) geschildert was Du machen willst, was mir
allerdings fehlt ist der reale Use-Case. Wie sieht Deine Anforderung aus.
Sag mir mal Deinen konkreten Anwendungsfall, dann fällt mir bestimmt ein
Pattern ein - ich kann mir nämlich kaum vorstellen dass Du Strings ausgeben
möchtest.
Caio,
Matthias
Alexander Widera
Es geht um einen recht anpassbaren WebShop.
Die "Basisklassen" sollen alle Basisfunktionen bereitstellen, so dass
theoretisch der komplette Shop funktioniert.
Die ganzen Artikeldaten z.B. werden ja bei unterschiedlichen Shops
unterschiedlich geladen - die einen aus einer Datenbank, die anderen aus
einer Textdatei, u.s.w. ....
Ebenso mit dem Aussehen des Webshops... bei einem werden die Artikel
untereinander angezeit, bei dem anderen nebeneinander (ganz grob gesagt).
Das Ziel ist, dass der Basisshop eine einheitliche Vorlage gibt, aber
trotzdem noch ein Großteil angepasst werden kann.
Ich habe da z.B. die Grundklassen:
- Artikel mit den ganzen Eigenschaften eines Artikels (Preis, Name, etc.),
die ja aber gefüllt werden müssen, z.B. aus einer Datenbank
- Warenkorb ... in dem können die Artikel gespeichert werden
- Kunde ... die Kundendaten, die noch erweitert werden sollen können
und und und...
Diese stehen ja irgendwie alle in Verbindung. Am Ende jedoch sollen die
"Kinder" der Grundklassen in Verbindung stehen, und nicht die Grundklassen.
Ist das schon genauer? Oder noch genauer?
Alex
"Mark Spahn" <jpap...@yahoo.com> schrieb im Newsbeitrag
news:du4t9m$85r$03$1...@news.t-online.com...
Klaus P. Pieper
Alexander Widera schrieb:
> Der Anwendungsfall ist der, :
> Es geht um einen recht anpassbaren WebShop.
>
> Die "Basisklassen" sollen alle Basisfunktionen bereitstellen, so dass
> theoretisch der komplette Shop funktioniert.
warum deklarierst Du die Methode in der Basisklasse nicht einfach als
virtuell?
Gruß
Klaus
--
reply to pub . kp2 . pieper at ibeq . com
Alexander Widera
das hab ich eigentlich sogar schon gemacht, nur hier nichtgepostet.
das Problem liegt dort...
in der Basisklasse sind Methoden, die auf Objekte der (anderen) abgeleiteten
Basisklassen zugreifen. Diese sind ja aber zur Entwicklungszeit noch nicht
da, sondern nur die Basisklassen.
"Klaus P. Pieper" <m...@private.net> schrieb im Newsbeitrag
news:46nkk1F...@individual.net...
Klaus P. Pieper
Hallo Alexander,
Alexander Widera schrieb:
> ja... was bringt das genau?
> das hab ich eigentlich sogar schon gemacht, nur hier nichtgepostet.
>
> das Problem liegt dort...
> in der Basisklasse sind Methoden, die auf Objekte der (anderen) abgeleiteten
> Basisklassen zugreifen. Diese sind ja aber zur Entwicklungszeit noch nicht
> da, sondern nur die Basisklassen.
das ist doch der Sinn der virtuellen Funktionen. Solange keine
abgeleitete Klasse instanziiert wird, wird die Methode der Basisklasse
aufgerufen. Wenn hingegen ein Objekt der abgeleiteten Klasse
instanziiert wird, wird auch dessen Methode aufgerufen.
Wenn Du hingegen die Basisklasse durch die andere Klasse ersetzen
willst, benutze Interfaces.
Alexander Widera
Könntest du mir ein kleines Beispiel geben (virtual)? Es klingt ja
eigentlich genau nach dem, was ich möchte.
Evtl. auch eine kleine Erlärung zu den Interfaces. Also nicht zu Interfaces,
sondern direkt zum Problem :)
Wenn ich das ganze mit Interfaces mache, dann wäre doch keine
Grundfunktionalität in der Basisklasse bzw. im Interface, sondern nur der
Aufbau.
Alex
Klaus P. Pieper
Alexander Widera schrieb:
> @Klaus:
>
> Könntest du mir ein kleines Beispiel geben (virtual)? Es klingt ja
> eigentlich genau nach dem, was ich möchte.
nö, dazu gibt es nun wirklich genügend Beispiele, die man direkt über
Google finden kann. Lesen musst Du schon selbst.
> Evtl. auch eine kleine Erlärung zu den Interfaces. Also nicht zu Interfaces,
> sondern direkt zum Problem :)
> Wenn ich das ganze mit Interfaces mache, dann wäre doch keine
> Grundfunktionalität in der Basisklasse bzw. im Interface, sondern nur der
> Aufbau.
Richtig. Deshalb schrieb ich auch "ersetzen". D.h. Du lieferst die
Basisklasse aus und der Anwender kann sie mit durch eine mit dem
gleichen Interface ersetzen.
Alexander Widera
hab nun die Struktur hinbekommen.