static const?

[mermshaus]

Offtopic:

@derschbedsi: Es wäre der Gesprächskultur zuträglich, wenn du die Aussagen anderer Poster nicht kategorisch und ohne jedwede Begründung ins Lächerliche ziehen würdest. Auf diese Weise ist kein Dialog möglich, was mich gerade sehr ärgert, da ich Threads zu solchen Themen gerne verfolge. Leider wird dieser Thread wohl immer mehr zum Schließkandidat.

Edit: ↓ Okay, das mit Wikipedia hatte ich falsch gelesen.

[derschbedsi]

@derschbedsi: Es wäre der Gesprächskultur zuträglich, wenn du die Aussagen anderer Poster nicht kategorisch und ohne jedwede Begründung ins Lächerliche ziehen würdest.

Die Begründung steht jedesmal dabei. Wer Wikipedia widersprechen will ist entweder sehr mutig und hat erstaunliche Fakten auffer Hand oder will einfach nur rumstänkern weil der eigene Glaubenskomplex soeben angezweifelt wurde

Leider wird dieser Thread wohl immer mehr zum Schließkandidat.

Na hoffentlich - die Frage wurde ja sowieso beantwortet ... denke ich

[combie]

Nach aufmerksamen lesen des ganzen Threads habe ich kein einziges unwiderlegbares Argument FÜR static gefunden.
Außer: Das ist in manchen Situationen bequemer.

Aber viele dagegen, es leiden:
Testbarkeit
Wartbarkeit
Wiederverwendbarkeit

[combie]

Wer Wikipedia widersprechen will ist entweder sehr mutig und hat erstaunliche Fakten auffer Hand oder will einfach nur rumstänkern weil der eigene Glaubenskomplex soeben angezweifelt wurde

Natürlich bin ich viel zu feige dem Wikipedia zu widersprechen.

Aber die deutsche Übersetzung von "Dependency Injection" zeigt schon ganz klar welchen Vorgang dieses Pattern beschreibt.
Und wenn "Dependency Injection" in Fabriken richtig Sinn macht, dann ist das ein anderes Thema. Und es sind durchaus Fabriken ohne "Dependency Injections" denkbar und auch üblich.

Bedenke: Nur weil ein Auto ein Rad hat, ist doch das Auto noch kein Rad.

[AmicaNoctis]

Wer Wikipedia widersprechen will ist entweder sehr mutig und hat erstaunliche Fakten auffer Hand oder will einfach nur rumstänkern weil der eigene Glaubenskomplex soeben angezweifelt wurde

Ein Bauwerk kann auch als Verallgemeinerung eines Gebäudes verstanden werden, dennoch gibt es kapitale Unterschiede in Form, Funktion und juristischer Betrachtung. Ich wohne jedenfalls in einem Gebäude (Wohnhaus) und wäre ziemlich betrübt, wenn ich behaupten müsste, ein Bauwerk (z. B. Brücke) mein Heim nennen zu müssen.

Das ist halt das Problem, wenn man sich bestimmte Aussagen herauspickt und als Argumente verwendet, ohne sie im Kontext zu sehen. Auch der Wikipedia-Eintrag macht klar, dass Dependency Injection schon etwas mehr ist als das Fabrikmethoden-Muster, welches sich in gewisser Weise auch im Singleton wiederfinden lässt. Trotzdem würde ich nicht behaupten, dass es dasselbe ist wie Singleton oder dass die beiden etwas miteinander zu tun hätten.

Egal, ich geb's jetzt auf.

Edit: Eins noch. ich halte den englischsprachigen Wikipedia-Eintrag über Dependency Injection für besser als den deutschen. Dort wird auch erklärt, dass der Provider unter anderem als Fabrikmethode implementiert werden kann. Das trifft den Kern der Sache besser, als die fehlinterpretierbare Aussage in der deutschen Wikipedia, man könne es generell als Verallgemeinerung ansehen.

[derschbedsi]

Nach aufmerksamen lesen des ganzen Threads habe ich kein einziges unwiderlegbares Argument FÜR static gefunden.
Außer: Das ist in manchen Situationen bequemer.

Da gäbe es zB generische Schnittstellen und die Entwicklung von Modulen - wenn man erstmal die halbe Software erweitern muss um ein neues Modul einzupflegen dann liegt ein Designfehler vor, hier können die o.g. Schnittstellen hilfreich sein. Ausserdem wird immer wieder ein einfacher Fakt vergessen : implizit hat jede Software mind. 1 öffentliche Schnittstelle bzw. mind. 1 Einsprungpunkt - bei C und C++ zB. die die "main" - Funktion, bei PHP bin ich mir nicht ganz sicher.

Zusätzlich spart man ganz einfach eine Menge Code wenn erstmal das Projekt gewisse Dimensionen angenommen hat - keine oder nur wenige, im Grunde überflüssige Abhängigkeiten, keine Laufzeitprobleme (im Falle von static)

Ich persönlich vermeide es auch grundsätzlich jedoch geht es manchmal einfach nicht anders - zumindest nicht ohne signifikante Anteile der eigenen Arbeitszeit zu investieren