[linux-l] Designfrage bzgl. Deckverwaltung

[Oliver Bandel]

On Sat, Oct 22, 2005 at 12:07:24AM +0200, Kai Kuehne wrote:
> Hi Axel,
> 
> On 10/21/05, Axel Weiß <aweiss at informatik.hu-berlin.de> wrote:
> > Hai Kai,
> >
> > für solche Fälle haben die Erfinder von C enums vorgesehen.[1]
> 
> C++, ich will C++ machen und somit auch die "Features" nutzen.
[...]

Aha, ein Kandidat für Featuritis. ;-)

( Willst Du später mal für Billy the Gates arbeiten? ;-) )

Wenn es mit weniger geht, warum dann alles aufblähen (bloaten)?

BTW: Wäre mir neu, wenn man enums aus C++ entfernt hätte. ;-)



> Danke trotzdem fuer deinen Vorschlag. :)

Vielleicht mal den vorschlag annehmen, denn enums
sind IMHO auch der sinnvollste Weg.

     ( oder ein krasseres Beispiel nehmen ;-) )


Ob Du Klassen brauchst, für so ein kleines Beispiel,
sei mal noch dahin gestellt.

Wenn ja, spricht das aber noch nicht gegen Enums.

Man könnte das auch in C machen und in einer Datei
hat man das Low-Level-Zeugs drinne, macht nur die
Funktionen nach aussen sichtbar, mit denen man
etwas erreichen will, das auf den Daten arbeitet
 und versteckt alles andere
(Datenstrukturen und Hilfsfunktionen => static) in der
Datei, die diesen Low-Level-Krams macht.

Das wäre ein Ansatz a la Module statt Klassen.
In ANSI-C statt C++ lässt sich auch programmieren,
es muß nicht immer C++ sein ( obwohl das ja in Mode
gekommen ist;-) ).

Klassen/OO sollte man IMHO erst nehmen, wenn zwingend
notwendig, also wenn z.B. zwingend dynamische Eigenschaften
gebraucht werden, die man nicht statisch abbilden kann.

Das ist aber bei den Eigenschaften von Spielkarten nicht notwendig,
ausser Du bemalst die Spielkarten während des Spiels...
...und mußt daher die Karteneigenschaften auch in Deiner
Software ändern können. (Und selbst das ginge auch anders...)

Es spricht also erst mal garnichts für OOP.

Die Funktionalität kannst Du in einer *.c-Datei kapseln,
also "compilation unit" statt Klassen (Module-like).

Ciao,
   Oliver