static const?

[h3ll]

Ohmann ... als ich "public static sollte vermieden werden" gelesen hab hörte ich auch auf, den Thread zu verfolgen

Ohne global erreichbare, ungeschützte Objekte sind größere Projekte meist garnicht möglich - ein einzige Zugriffspunkt muss immer uneingeschränkt erreichbar sein wenn die Software lesbar sein soll und/oder von mehr Leuten als nur dem kleinen Hans in seinem Kinderzimmer gebaut wird

Das ist auch durchaus vertretbar - sofern diese variable oder dieses Objekt einigermassen isoliert ist und wirklich nur die wichtigsten Infos / Zugriffspunkte bietet. Das ist nunmal Fakt - da können sich einige Spezis im Internet auch noch so sehr gegen wehren.

Und nun viel Spaß beim Sabbern ob der Ironie meines Nicknames.

Schon mal was von Dependency Injection gehört? Welche Objekte sollten denn unbedingt global erreichbar sein? Kannst du ein Beispiel nennen?

Ich kenne genug größere Projekte und statische Klassen sind zu 99% nur Bequemlichkeits-Dirty-Hacks, die eigentlich vermeidbar wären.

[mermshaus]

So wie ich das sehe, verhält sich eine Klasse mit statischen Methoden und statischen Eigenschaften auch wie ein Singleton, ist also nur ein anderer Name für (fast) das gleiche Konzept.

Ist alles „global state“. Verdeckt Abhängigkeiten, „versaut“ Unit-Testing. (potentiell)

- http://misko.hevery.com/code-reviewers-guide/

[derschbedsi]

Das stimmt so nicht. Für Schnellschussprojekte oder Machbarkeitsstudien muss man static nicht dogmatisch vermeiden

Welchen Teil des Wortes "große" habe ich versehentlich in einer unbekannten Sprache verfasst?

, aber wenn es um Wiederverwendbarkeit und Wartbarkeit geht, ist es gerade bei großen Projekten mehr als sinnvoll, dass man bessere Ansätze verwendet.

Jo ... netter Gedanke - funktioniert in der Realität eben nicht, ganz besonders dann wenn Hunderte von Entwicklern an der selben Software arbeiten.

Dass große Projekte ohne static nicht auskommen würden, ist aber absolut unzutreffend. Es gibt so viele gute Entwurfsmuster, die einen würdigen Ersatz darstellen.

In der Schule und im Studium lernt man das so - danach holt die Realität aber schnell auf ;-)

Man kann froh sein, in großen Projekten überhaupt noch lesbaren Code anzutreffen - viele "Entwickler" stammen eben immernoch aus Urzeiten und setzen auf streng prozeduralen Code, geben nichts auf Lesbarkeit, flechten überall Magic Numbers ein oder schreiben sogar vollkommen absichtlich auf eine unwartbare, unlesbare Art u. Weise --> Willkommen auf dem Planeten Erde.

[h3ll]

In der Schule und im Studium lernt man das so - danach holt die Realität aber schnell auf ;-)

Also ich kenn den umgekehrten Weg. In der Schule haben wir quasi gar kein richtiges Programmieren gelernt. Studium hab ich keins gemacht. Aber in der Realtität merkt man sehr schnell, welche Nachteile der ganze statische Mist bringt, je mehr man damit konfrontiert wird.

Man kann froh sein, in großen Projekten überhaupt noch lesbaren Code anzutreffen - viele "Entwickler" stammen eben immernoch aus Urzeiten und setzen auf streng prozeduralen Code, geben nichts auf Lesbarkeit, flechten überall Magic Numbers ein oder schreiben sogar vollkommen absichtlich auf eine unwartbare, unlesbare Art u. Weise --> Willkommen auf dem Planeten Erde.

Ein Projekt hat nun mal Coding Standards, an die sich jeder halten muss. Und diejenigen, die sich nicht daran halten, die werden halt früher oder später nicht mehr an diesem Projekt mitarbeiten. Das ist die Realität.

[onemorenerd]

viele "Entwickler" stammen eben immernoch aus Urzeiten und setzen auf streng prozeduralen Code, geben nichts auf Lesbarkeit, flechten überall Magic Numbers ein oder schreiben sogar vollkommen absichtlich auf eine unwartbare, unlesbare Art u. Weise

Mag sein, aber deswegen ist es noch lange nicht gut so! Ganz im Gegenteil: Gerade weil es so ist, kann man gar nicht oft genug "sauberen" Stil propagieren.

[derschbedsi]

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

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

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

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

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

[mermshaus]

Offtopic:

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

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

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

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