3. Wie benennt Ihr Interface-Klassen?

Wie benennt Ihr Interface-Klassen?

  • A

    Konrad Rudolph schrieb:

    So, jetzt muss ich mich auch mal einmischen.

    Ich bitte darum! 🙂

    Konrad Rudolph schrieb:

    Namensbereiche haben damit nur zwei Ziele:

    1. Namenskonflikte verhindern!
    2. (Eventuell) Objekte leichter auffindbar machen.

    Ja, beides kann der Namespace interface erfüllen. Auch thematisch erfüllt er seinen Zweck. Klar, es kommt darauf an, was thematisiert werden soll. Ich muß ehrlich sagen, das in unserem aktuellen Java-Projekt, sich die Kräfte durchgesetzt haben, für jeden Pups ein Package anzulegen. Da würde ich am liebsten um mich schlagen:

    de.firma.mylib.option
de.firma.mylib.option.core
de.firma.mylib.option.model
de.firma.mylib.option.model.internal
de.firma.mylib.option.ui
de.firma.mylib.option.ui.internal
de.firma.mylib.option.util

    Und es ist kein Ende abzusehen. Zumal option nur ein Thema von ca. 30 ist. 😡

    Da gehe ich mit dir konform, das sowas nicht ausarten darf.

    Konrad Rudolph schrieb:

    Ich denke, ein Namensbereich namens interface hilft da nicht (zumal einige alte Compiler immer noch Probleme mit zu vielen verschachtelten Namensbereichen haben).

    OK, in meiner Lib interessieren mich zu alte Compiler nicht. Die schliesse ich sogar absichtlich aus. Ich finde, man darf ein gewisses Mass an Konformität erwrten.

    Konrad Rudolph schrieb:

    Was lange Namen betrifft: Wo ist das Problem? Wenn ein langer Name nötig ist, um den Zweck einer Methode (o.ä.) ausreichend zu beschreiben, dann wird eben ein langer Name verwendet. In einem aktuellen Projekt (nicht C++) habe ich z.B. eine Klasse namens 'ActionDataSourceControl' und eine Methode namens 'CreateConditionGroupForFields'.

    Gegen aussagekräftige Namen habe ich nicht. Aber dein Methodenbeispiel, würde mich mal interessieren. Ich schätz es sieht ca. so aus:

    ConditionGroup CreateConditionGroupForFields(Fields f);

    Da muß ich sagen, finde ich es unnötig lang. So wäre es kürzbar, und trotzdem verständlich:

    ConditionGroup CreateConditionGroup(Fields f);

    Der Übergabeparameter kann schon aussagen, das was ich "für" machen soll. Ich sehe öffters solche doppelt-gemoppelt-Bezeichner. Dabei gibt die Signatur-Syntax schon vieles her.

    Klar, sowas ist dagegen einfach unschön:

    ConditionGroup CrtCndtonGrp(Fields f);

    😉

    Konrad Rudolph schrieb:

    Ansonsten halte ich es wie Archie: Ich verwende konsistent die Benennung, die die STL und Boost vorgeben, also alles Kleinbuchstaben und Unterstrich als Trenner. Das ist zwar keine schöne Konvention (zumindest für öffentliche Schnittstellen), aber Konsistenz ist hier m.E. wichtiger.

    *zustimm* Das CamelCase von Java finde ich pers. auch schöner. Aber wenn ich ausgiebig die C++-Stdlib und Boost benutze, halte ich mich an deren Konventionen. Denn in Java richte ich mich auch nach der Sun-Konvention, egal obs mir gefällt oder nicht.

    Konrad Rudolph schrieb:

    Zum Schluss noch einen Satz zur eigentlichen Fragestellung: Ich halte die verwendete Konvention für gut. Aus 'button_base' ist zwar nicht erkennbar, ob es sich um eine Schnittstelle oder eine abstrakte Basisklasse handelt, aber das soll es IMHO auch gar nicht (zumal C++ technisch sowieso nicht zwischen den beiden unterscheiden kann).

    Stimmt, haste Recht. Technisch gesehen ist es in C++ egal ob es abstrakt oder ein "Interface" ist.

    0
  • A

    thordk schrieb:

    warum so viele leute probleme mit langen klassen- und methodennamen haben, kann ich ehrlich gesagt immer noch nicht nachvollziehen. lange, beschreibende namen sorgen für sehr viel mehr übersicht, als es die verwendung kurzer namen zum zwecke der "übersichtlichkeit" im code je erreichen könnte.

    Glyph *paragraph = new Paragraph;
DocumentLayoutContentController *controller
  = new DocumentLayoutContentController( Layout::PLAIN );
controller->addGlyph( paragraph );

// find ich z.b. wesentlich übersichtlicher als

glyph *p = new para;
ctrl_doclay *ctrl = new ctrl_doclay( consts::L_PLAIN );
ctrl->add( p );

    (das war ein leicht angepasstes reales beispiel ^^)

    ctrl anstatt Controller finde ich für eine Variable i.O. Zumal ctrl auch noch auf jeder (englischen) Tastatur drauf steht, und jeder wissen sollte was es heißen könnte. 😉

    Im Ernst, solche Zerstückelungen mache ich pers. hauptsächlich bei Variablen und dann meistens nur bei temporären.

    ctrl_doclay als Typname würde ich so auch nicht machen. Höchstens bei privaten lokalen Klassen, die nicht nach draussen dringen. Alles was vor dem User versteckt ist, kürze ich gerne. Alles was der User benutzen muß, versuche ich kurz zu halten. Aber nicht in dem versuche Buchstaben weg zu lassen.

    Anstatt TreeListView finde ich z.B. TreeList i.O., wenn es in einem View-Namespace ist. Wenn es ein TreeListModel gibt, sollte man evtl. einen Model-Namespace überlegen. Wobei TreeListView auch schon recht kurz ist. Nur noch mehr Wörter dürften nicht rein. StuecklistenTreeListView finde ich schon har an der Grenze! Noch ein Wort, und ich würde die Kriese kriegen. 😉

    0
  • K

    Artchi schrieb:

    Konrad Rudolph schrieb:

    Was lange Namen betrifft: Wo ist das Problem? Wenn ein langer Name nötig ist, um den Zweck einer Methode (o.ä.) ausreichend zu beschreiben, dann wird eben ein langer Name verwendet. In einem aktuellen Projekt (nicht C++) habe ich z.B. eine Klasse namens 'ActionDataSourceControl' und eine Methode namens 'CreateConditionGroupForFields'.

    Gegen aussagekräftige Namen habe ich nicht. Aber dein Methodenbeispiel, würde mich mal interessieren. Ich schätz es sieht ca. so aus:

    ConditionGroup CreateConditionGroupForFields(Fields f);

    Da muß ich sagen, finde ich es unnötig lang. So wäre es kürzbar, und trotzdem verständlich:

    ConditionGroup CreateConditionGroup(Fields f);

    Der Übergabeparameter kann schon aussagen, das was ich "für" machen soll. Ich sehe öffters solche doppelt-gemoppelt-Bezeichner. Dabei gibt die Signatur-Syntax schon vieles her.

    Da gebe ich Dir vollommen recht. Leider sieht die Signatur vollkommen anders aus als von Dir vermutet:

    public static void CreateConditionGroupForFields(
    WizardBase dialog,
    StepBase step
);

    Hier schreit ja erst einmal alles nach schlechtem Design. Leider gibt es dafür recht gute Gründe. 'WizardBase' ist eine (Dialog-)Basisklasse aus einem anderen Projekt. Die Methode mit dem Monsternamen befindet sich in einer statischen Helper-Klasse und stellt quasi ein Mixin dar. Eine Member-Methode wäre hier konzeptuell besser gewesen, kommt aber leider nicht in Frage, weil die Vererbungshierarchie sonst ausgeartet wäre (na ja, um genau zu sein ist fehlende Planung Schuld, es wäre einiges Refactoring notwendig gewesen, um das nachträglich zu korrigieren). Bei der im Namen genannten 'ConditionGroup' handelt es sich um ein UI-Konzept aus der Anwendung. Die 'Fields' sind Teil der 'StepBase'-Klasse (nicht ganz korrekt, aber nahe genug). Elemente der Klasse 'Field' direkt zu übergeben ist leider auch nicht möglich, weil diese nicht direkt existieren sondern durch diese Methode erst extrahiert werden.

    => Aber im Prinzip hattest Du schon recht: Dieser umständliche Name kompensiert in großem Maße für ein schlechtes Design.

    *zustimm* Das CamelCase von Java finde ich pers. auch schöner.

    *brr*. CamelCase ist für mich persönlich das schlimmste überhaupt; es stört den Lesefluss. Herfried Wagner hat das recht anschaulich erläutert (runterscrollen bis „Probleme der Camel Case-Konvention“).

    Ich bevorzuge aus diesem Grund für öffentliche Schnittstellen die PascalCase-Konvention. Aber wie Du auch sagtest: Ich halte mich an die „lokalen Gepflogenheiten“, d.h. in Java verwende ich z.B. ebenfalls CamelCase.

    0
  • T

    die in dem artikel erläuterten probleme betreffen aber auch ausschließlich die betrachtete sprache und nicht java, die sprache, welche camel case populär gemacht hat.

    public int foo;
public foo();

//...

this.foo = 0; // ist *immer* eindeutig
foo = 0; // ebenso
foo(); // und zwar deshalb
foo() = 0; // und weil sowas falsche syntax wäre ;)
    0
  • K

    thordk schrieb:

    die in dem artikel erläuterten probleme betreffen aber auch ausschließlich die betrachtete sprache und nicht java, die sprache, welche camel case populär gemacht hat.

    ACK. In Java gelten *diese* Bedenken so nicht. Die anderen Bedenken bezüglich der Lesbarkeit und des Schriftbilds aber schon und die sind meiner Erfahrung nach nicht unerheblich, was sich aber nur auf subjektiven Eindrücken begründet.

    0
  • B

    Was ich an Camel-Case schön finde: Dadurch gibt es jetzt vier Stile, mit denen man Code-Arten voneinander abgrenzen kann. Z.B.

    class PascalCamel
{
public:
    void kissMyCamel()
    {
        camel_hunches = TWO_HUNCHES;
    }

protected:
    enum Hunches
    {
        ONE_HUNCH,
        TWO_HUNCHES
    };

private:
    int camel_hunches; // Nachgeguckt, hunch->Höcker :)
};

    Damit kann man auf einen Blick sehen, um was es sich handelt, ähnlich wie Makros oder Konstanten meist GROß geschrieben werden. Ansonsten würde ich nicht so recht damit zurecht kommen:

    class default_button // einmal Klasse
{
};
default_button my_btn;

// oder aber
button default_button; // diesmal Variablen-Bezeichner

// oder auch
button* default_button( int nr );

    Klar, man erkennt es aus dem Kontext, aber ich finde es angenehmer, sie auch vom Erscheinungsbild unterscheiden zu können.

    0
Anmelden zum Antworten