z.b.

class XYZ
{
 namespace a
 {
  //iwas
 };
};

Und wieso probierst du sowas nicht einfach aus?

P.S.: Namespace-Blöcke brauchen kein Semikolon zum Abschluss.

die elemente der klasse haben ja sowieso einen eigenen Gültigkeitsbereich, warum willste denn da noch ein namespace rein tun?

Vermutlich um weitere Unterbereiche zu bilden, eben das was namespaces im globalen Bereich auch machen.
Jud4s: du kannst dir helfen indem du in der Klasse statt des namespace ein struct mit statischen Methoden und Membern definierst. Die Wirkung ist ähnlich der eines namespace.

@Nexus: habe ich? allerdings klappte es nicht (wie auch wenns nicht geht ) und ich dachte vll habe ich was falsch gemacht, und siehe da, ich habe zwar nix falsch gemacht, aber eine Lösung habe ich dennoch gesagt bekommen....

@uhsuz: ich fand die idee gut und sinnvoll

thx @ pumukl, hast recht mit deiner Therorie, ich will in einer Klasse auf bestimmte Elemente immernoch ohne Schwierigkeiten zugreifen können, allerdings will ich beides von einander trennen damit ich nicht durcheinander komme und die Lesbarkeit immernoch gewärleistet ist...

Bei mir läuten gerade die Alarmglocken. Ich kann falsch liegen, aber ich schätze fast das du dein Klassendesign überdenken solltest. Klassen sollten immer nur eine Aufgabe abdecken (große Klassen tendieren dazu deutlich mehr zu machen), und noch extremer wird dies im Buch "Code Complete" gesagt: Eine Klasse sollte nur 5 +/- Membervariablen besitzen. Letzteres halte ich zwar etwas für übertrieben, geht aber schon in die richtige Richtung.

Bei einem guten Klassendesign sollte die Klasse eigentlich noch überschaubar bleiben. Lieber etwas feiner untergliedern als das man den überblick verliert.

Um mal ein Beispiel zu geben:
In einer Anwendung habe ich eine Klasse verwendet die auf Grund der Vorgaben sowohl eine Adresse dargestellt hat (mit Getter/Setter sowie direkt damit zusammenhängende Logik) - soweit noch akzeptabel, außer das dieses Adressobjekt schon alleine aus ca. 40 Membervariablen+ bestanden hat - zudem hat sich die Klasse aber auch mit dem Auslesen und Speichern der Daten beschäftigt, ebenso wie mit Angaben zum HTML-Export.

Ein Besseres Design würde die 3 genannten Aufgabenbereiche herauslösen:
a) Representation der Adresse
b) Laden/Speichern der Daten
c) HTML-Export

Zudem könnte man schauen ob man nicht auch die Memberanzahl verringert. Das Objekt war eine 1:1 Abbildung der Datenbank und enthielt u.a. einige Kommunikationsangaben, die Anschrift etc. zu einer Adresse. Bereits aus den Begrifflichkeiten kannst du sehen wie ich persönlich weiter aufsplitten würde (Anschrift als separate Klasse, was auch noch den Vorteil der möglichen 1:n Beziehung später hätte, sowas wie getrennte Rechnungs- und Lieferanschrift...; Herauslösen der Kommunikationsdaten wie Telefon, Fax... auch hier gleich mit dem Hintergrund das eine Adresse mehrere einer Art haben kann).

Man erhöht zwar die Klassenanzahl damit, anderseits werden die Klassen übersichtlicher, leichter wartbar und können zudem unter Umständen auch flexibler verwendet werden (z.B. die von mir erwähnten 1:n Beziehungen).

cu André

Wenn du/ihr/allesamt mir eine bessere/sinnvoller Lösung vorschlagen könnt, bin ich aufnahmebereit....

diese Wiederverwendbarkeit ist bruache ich (immo) nicht, da diese Klasse genau für eine Sache konstruiert worden ist...

Nicht desto trotz habe ich die Befürchtung das es eben nicht nur eine Sache ist. Klassen die sich wirklich nur eine Aufgabe stellen tendieren dazu immer überschaubar zu bleiben.

Jud4s schrieb:

Nun aber will cih das der Computer auch einen "Spieler" "spiel" allerdings müssen da die Methoden etwas anders sein da der Computer ja selber berechnen soll was er macht...

Mehrere Möglichkeiten:
1. Gemeinsame Basisklasse, alle unterschiede werden in die Abgeleiteten verfrachtet (z.B. ISpieler, Spieler, Computerspieler).
2. Unterschiedliche Logik als Strategie auslagern (Siehe Entwurfsmuster "Strategie"). Diese Variante kann sinnvoll sein wenn du noch unterschiedliche Computerspieler implementierst.
usw.

Jud4s schrieb:

wie bitteschön soll cih das sinnvoll in weitere Klassen untergliedern?

Grundsätzlich besagt schon das es Unterschiede gibt die nötige Untergliederung. Eine Klasse eine Aufgabe: entweder Computerspieler oder menschlicher Gegenpart.

Deine "."-Taste sollte auch mal repariert werden.

cu André

ich habe mir mal meine Klassen angeguckt, bin aber nicht zu einer Lösung gekommen wie ich die Klassen in kleinere Klassen auslagern kann. Da ich z.b. nicht einfach ein paar Methoden in eine andere Klasse schreiben kann, da sich sonst Zugriffsprobleme ergeben, bzw sihc das ganze dann total unüberichtlich gestalten wird. Ich will jetzt nicht das ihr die Arbeit für mich macht aber ihc habe keinen blassen Schimmer wie ich deine Vorschläge umsetzen kann/soll.

Mfg Judas

PS: anscheinend hatte die "." - Taste nen Kurzen.

class IPlayer
{
    private:
        // Membervariablen sollten niemals direkt veröffentlicht werden,
        // dann lieber Getter/Setter bei denen du zumindestens jederzeit
        // noch überprüfungen einbauen kannst. Unter umständen (bin kein
        // Freund davon, würde auch protected gehen
        Card Deck[5];
        int money;
        int ValueOfCards;

    public:
        // Sprechender geht es nicht? 
        void first_of_all_functions();
        void getcards();
        void sortcards();
        int givemoney(int);
        virtual void changecards(Card*,int&) = 0; // Ich finde es eine Abart die
          // Bezeichner im Header (der zum Überschauen besser ist) wegzulassen
        void recognizecardvalue();
        virtual int steigern(int&) = 0;
};

class HumanPlayer : public IPlayer
{
    public:
        void changecards(Card*,int&);
        int steigern(int&);
};

class ComputerPlayer : public IPlayer
{
    public:
        void changecards(Card*,int&);
        int steigern(int&);
};

Und nun les dir erstmal etwas über Vererbung/Polymorphie durch. Es gibt andere Alternativen mit schwächerer Bindung, aber für den Anfang wird dieser Weg für dich leichter sein.

cu André

Mfg Judas