static const?

[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

[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.

[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.

[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

[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

[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]

Dependency Injection hat erstmal genau gar nichts mit Fabrikklassen zu tun

Oh mann ...

Sie kann als Verallgemeinerung der Fabrikmethoden verstanden werden

Lass mich raten - nun kommt "Wikipedia hat nicht immer recht!!1eins"

Bitte informier dich über den Unterschied zwischen dem Factory-Pattern und Dependency Injection.

Dickes Eigentor.

Bisher vermittelst du den Eindruck, dass du da was falsch verstanden hast, was auch deine Affinität zu static erklären würde.

Jaja ... "Affinität" und so. Wird schon so sein. Ich hab alle meine Klassen, Methoden auf public ... bestimmt.

Übrigens trollt hier niemand außer dir.

Ja, Argumente sind ja bekanntlich "Getrolle". Aber ich merk schon dass hier religiöse Glaubensparadigmen vorherrschen - typisch Internetforum eben.

Du hast schon vom ersten Beitrag an deine Meinung dogmatisiert und alle die anders darüber denken mehr oder weniger subtil abgewertet.

"Ein Forentroll" === "alle"
"bekanntermassen unwahre Behauptungen als solche deklariert " === "mehr oder weniger subtil abgewertet"

Nun, normalerweise mag ich kindliche Symbolik nicht ... doch in diesem Fall passt es ausnahmsweise einmal :

[AmicaNoctis]

Fabrikklassen sind in der Tat sehr empfehlenswert ... aber erst in mittelgroßen bis großen Projekten. Bei 500 Zeilen ... naja ... "Overkill" eben.

Dependency Injection hat erstmal genau gar nichts mit Fabrikklassen zu tun und lohnt sich sehr wohl auch in kleinen Projekten, die dadurch sogar in hohem Maße wiederverwendbar werden. Bitte informier dich über den Unterschied zwischen dem Factory-Pattern und Dependency Injection. Bisher vermittelst du den Eindruck, dass du da was falsch verstanden hast, was auch deine Affinität zu static erklären würde.

Übrigens trollt hier niemand außer dir. Du hast schon vom ersten Beitrag an deine Meinung dogmatisiert und alle die anders darüber denken mehr oder weniger subtil abgewertet.

[h3ll]

Na wenn das dein Niveau ist, dann kann man die Diskussion mit dir gleich beenden...

Wenn du Smarty für das Allheilmittel hältst, wird eigentlich sehr schnell klar, dass du von Programmieren keine Ahnung hast.

[mermshaus]

Offtopic:

Im Ernst, bisschen mehr inhaltliches Niveau wäre der Hit, sonst springt der Thread so langsam endgültig von der Klippe.

[derschbedsi]

Smarty steht nicht für das Prinzip der Trennung von Programmlogik und Darstellungslogik.

[ ] Smarty verstanden
[x] einfach mal was gesagt

Wenn du nur mit Smarty Programm- von Darstellungslogik trennen kannst, spricht das Bänder und disqualifiziert dich automatisch.

[x] rumgetrollt
[x] nun auf der Ignorierliste

[h3ll]

Das Prinzip der Trennung von Programmlogik und -Darstellung "Müll" zu nennen spricht Bände und disqualifiziert dich vollautomatisch ;-)

Bitte genau lesen. Ich hab nur gesagt, dass Smarty Müll ist. Smarty steht nicht für das Prinzip der Trennung von Programmlogik und Darstellungslogik.

Wenn du nur mit Smarty Programm- von Darstellungslogik trennen kannst, spricht das Bänder und disqualifiziert dich automatisch.

Unabhängig davon wie toll / nicht toll Smarty implementiert ist - solche Libs sind mehr als sinnvoll und mitunter auch ein Merkmal von lesbarem Code.

Quatsch. Man kann auch ohne Smarty lesbaren Code schreiben.

[derschbedsi]

Smarty ist generell Müll.

Das Prinzip der Trennung von Programmlogik und -Darstellung "Müll" zu nennen spricht Bände und disqualifiziert dich vollautomatisch ;-)
Unabhängig davon wie toll / nicht toll Smarty implementiert ist - solche Libs sind mehr als sinnvoll und mitunter auch ein Merkmal von lesbarem Code.

Dependency Injection

Fabrikklassen sind in der Tat sehr empfehlenswert ... aber erst in mittelgroßen bis großen Projekten. Bei 500 Zeilen ... naja ... "Overkill" eben.

Das nennst du Lesbarkeit?

Jop, allerdings. Das ist schonmal ein Riesenschritt im Vergleich zu prozeduralem Code - auch OOP unterliegt einer Kosten/Nutzen - Einschätzung.

[h3ll]

... und trotzdem haben öffentliche Variablen / Objekte ihre Daseinsberechtigung - man sollte sie eben sparsam und sinnvoll einsetzen.

Beispiel :

class myClass
{

    public static $smarty; 

    function __construct()
    {
        require_once("libs/Smarty.class.php");
        $this->smarty = new Smarty();
    } 

} 

Tatsächlich HILFT in diesem Falle die Variable doch sehr - HTML-Code wird komplett weggekapselt und somit bleibt der PHP-Code lesbar. Das nun über getter und setter zu realisieren ... naja, ich weiss nicht - ein bischen Overkill für eine einzige oder einige wenige Variablen

Smarty ist generell Müll. Aber mal davon abgesehen, wozu eine statische public Variable? Ist doch hier vollkommen überflüssig.

[AmicaNoctis]

Dependency Injection wäre auch hier der sinnvollere Weg. Deine Klasse musst du ja schon alleine umschreiben, wenn sich der Pfad ändert. Wenn du aus dem Code API-Docs generierst, sieht kein Entwickler mehr, dass du eine fest verdrahtete Abhängigkeit zu Smarty hast, die auch noch auf einen bestimmten Pfad festgenagelt ist. Das nennst du Lesbarkeit?