C
hustbaer schrieb:
sehr viele klassen haben "init-only" member. die mache ich dann gern konstant. um fehler zu vermeiden, und es dokumentiert auch gut was veränderlicher state ist, und was nicht.
Viele Klassen, selbst wenn sie Kopieren nicht unterstützen, könnten problemlos movable oder swapable sein - und das dürfte auch für viele die init-Fälle zutreffen. In solchen Fällen ist die Verwendung von const-Membern unnötig einschränkend.
Teilbaren (in veräbnderbaren/nicht-veränderbaren) State zu haben, scheint mir schwer mit dem one-class-one-responsibility-Prinzip vereinbar zu sein. Jedenfalls sind mir bisher kaum überzeugende Beispiele eingefallen, die den Sinn von konstanten Membern darstellen würden.
Zwei Fallgruppen sind noch die wahrscheinlichsten Kandidaten:
- Singletons: hier entfällt das movable/swapable-Argument
- Proxies: da diese Referenzen imitieren, überrascht hier nicht, dass Referenzen als Member verwendbar sind, da Kopier- und Zuweisungssemantik auseinanderfallen. Andererseits könnte man auch das Proxieobjekt selbst während seiner gesamten Lebenszeit als konstant (eigentlich: stateless) ansehen, die Konstanz der Member ist dann wiederum nur Folge der Konstanz des gesamten Objektes.
Meine Aussage war auch primär eher an weniger Erfahrene gerichtet: im Forum sieht man öfter Code, in dem Member nur deshalb const sind, weil der Schreiber nicht die Absicht hat, das Klassenobjekt jemals zu verändern, aber nicht weil diese Konstanz im einzelnen Member selbst angelegt ist. Das ist dann ein typischer Fall der Kategorie: "wenn es konnst sein kann, mach es const", was ich nicht für zielführend halte.
