Private zu Public machen

Oh, so hatte ichs auch versucht, aber hat bei privaten Methoden net hingehauen. Macht irgendwie auch Sinn. Dass es bei protected geht, is aber gut und hilft mir weiter. Problem damit gelöst, danke

SeppJ

---

Funktioniert das auch mit überladenen Methoden? Beispiel:

class base
{
    protected:
        void foobar() {}
        void foobar(int i) {}
};

class derived : public base
{
    public:
        using base::foobar();
};

So funktioniert es aber leider nicht.

David_pb

Aber auch nur weil die Klammern zu viel sind:

class derived : public base
{
    public:
        using base::foobar;
};

Max0r

Hab mich falsch ausgedrückt. Ich will nur foobar ohne Übergabeparameter public machen, die andere soll protected bleiben.

Michael E.

Am besten zeigst du mal, was du vorhast. Diese Frickelei riecht nämlich nach einem schlechten Design. Ich habe solche using-Deklarationen noch nie gebraucht.

Max0r

Ich bau mir grade ein paar Klassen (sozusagen ein "Framework") zum Erstellen von WinApi-Controls (Fenster, Buttons, Listboxen, ...). Eine meiner Klassen ist die Basis für alle anderen. Sie stellt Methoden wie setBounds(), show(), hide() und auch create() zur Verfügung. Nun ist create() überladen. Einmal gibt es alle Parameter, die CreateWindowEx() annimmt und einmal nimmt sie einen Pointer auf meine Basisklasse an. Zweitere Methode erstellt dann das Fenster beispielsweise mit irgendwelchen Default-Parametern.

Wie gesagt leite ich von dieser Basisklasse meine anderen Controls ab. Meine Klasse für Fenster [abgeleitet von der Basisklasse] soll beide create-Methoden public zur Verfügung stellen. Für Controls, die Systemklassen darstellen (Button, Listbox, ...) habe ich noch eine "Zwischenklasse", die nur die create-Methode mit dem parent-Control public und die andere protected, damit ich von außen nicht darauf zugreifen kann, aber ggf. in weiteren abgeleiteten Klassen schon.

Hoffentlich hab ich mich klar ausgedrückt...

Michael E.

Du deklarierst also in einer Basisklasse eine Funktion, die nicht in allen abgeleiteten Klassen zur Verfügung stehen soll, d. h. du hast das is-a-Prinzip verletzt. Du solltest Funktionalitäten erst dort in deinen Vererbungsbaum hinzufügen, wo sie auch hingehören.

Max0r

Die Methoden sollen in allen abgeleiteten Klassen zur Verfügung stehen, nur nicht public.

SideWinder

Kann es sein, dass du evtl. eine abstrakte Methode deklarieren wolltest? Oder geht es dir um die andere Richtung? public in base und private in derived? Das sollte nicht vorkommen. Warum sollte ich mit dem Basisobjekt etwas tun können, was mit abgeleiteten Objekten nicht mehr möglich ist?

Was genau hast du denn vor? Wie kommst du darauf? Zeig uns (d)ein Code-Beispiel.

MfG SideWinder

Michael E.

Was ist das denn für ne "Zwischenklasse", die weniger kann als die Basisklasse?

Ich hab noch nie was mit der WinAPI gemacht und weiß deshalb nicht, wie du dein Framework strukturell am besten aufstellen kannst, aber wie wärs, wenn du dir ne ABC CreateWithWindowsExParam erstellst?

Max0r

@Michael E.: Die WinApi benötigt pro Fenster eine Fensterklasse, die das Aussehen und die WindowProcedure (Callback für Windows-Nachrichten) definiert. Es gibt schon vordefinierte Klassen wie "Button", "Listbox" usw.. Meine Zwischenklasse, die eben für diese System-Fensterklassen steht, hat dann unter anderem folgende Methode:

create(std::string sClassName, basisKlasse *pParent);

wobei sClassName dann z. B. "Button" und pParent die Adresse des Parent-Fensters (falls vorhanden) wäre. Danach wird die (protected) Methode create() aufgerufen, die dann CreateWindowEx() aufruft, was das Fenster erstellt. Das ganze hat den Hintergrund, dass ich bei den genannten Systemklassen nur beschränkte Möglichkeiten zum Erstellen zur Verfügung stellen will.

Verschiedene Namen für die Funktionen zu nehmen könnte ich natürlich auch machen. Nur beantwortet sich damit immer noch nicht die Frage, ob (und wenn ja, wie) es möglich ist, einzelne Überladungen von Methoden in andere Zugriffsbereiche zu schieben.

@SideWinder

Ja, ich will in manchen Ableitungen bestimmte Methoden protected implementieren, die in der Basisklasse public sind. Und nein, ich will keine abstrakte Methode.

Nexus

Das Problem ist folgendes. Wenn du eine in der Basisklasse öffentliche Methode in einer abgeleiteten Klasse verdeckst, kannst du nach wie vor über die Basisklassenversion zugreifen, notfalls mit einem Cast.

Kann es sein, dass Vererbung hier nicht angebracht ist und Aggregation (Membervariablen) mehr Vorteile hätte? Zumindest könntest du dann das Interface in der abgeleiteten Klasse selbst bestimmen. Unter anderem hättest du dieses Problem nicht.

Shade Of Mine

sieht für mich so aus als würde jede klasse sich selber createn können. bzw. alle von deiner zwischenklasse abgeleiteten klassen verwenden eben diese zwischenklasse für das create.

aber warum soll die basisklasse das create machen wenn es doch unterschiedliche arten gibt ein control zu createn? was wenn ich ein control erstellen will dass physisch aus 2 oder mehr winapi controls besteht, die aber eine logische einheit bilden?

create raus aus der basisklasse.

Michael E.

Du hast meiner Meinung nach zwei Möglichkeiten:

1. Du verabschiedest dich von dem CreateWindowEx-Interface in den einzelnen Klassen.
2. Du verabschiedest dich von deiner Typhierarchie.

Ich bin ganz klar für 1.

Wie stellst du dir das vor? Du willst explizit Klassen anlegen für die unterschiedlichen Typen (eigene Buttons etc.) und in diesen Klassen eine Funktion create anbieten, in der über einen String der Typ des Objekts bestimmt wird. Das ist doppelt gemoppelt.