static const?

[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

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

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

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

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

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

[AmicaNoctis]

Ohne global erreichbare, ungeschützte Objekte sind größere Projekte meist garnicht möglich - ein einzige Zugriffspunkt muss immer uneingeschränkt erreichbar sein

Das stimmt so nicht. Für Schnellschussprojekte oder Machbarkeitsstudien muss man static nicht dogmatisch vermeiden, aber wenn es um Wiederverwendbarkeit und Wartbarkeit geht, ist es gerade bei großen Projekten mehr als sinnvoll, dass man bessere Ansätze verwendet.

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.

[derschbedsi]

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.

[fireweasel]

Das ist wie so oft Ansichtssache. Viele Wege führen nach Rom. Mich stört es aber, wenn nur ein(!) Weg progagiert wird.

Da widerspreche ich dir nicht.

Wenn statische Eigenschaften und Methoden aus Sicht der Informatik Müll wären, hätte man sie nicht in diverse Sprachen eingebaut.

Wende das Argument mal auf GOTO an ...

Hinzu kommt, dass (statische) Klassen in PHP nunmal "defekt", also nur eingeschränkt zu gebrauchen, sind.

... Ich verweise hier nur auf Singletons.

... Und auch für mich ist das eine echtes "anti Pattern".

Ich habe kein Problem mit dem Singleton-Pattern. Dass es falsch angewandt wird, ist eine Eigenschaft, die es mit anderen Werkzeugen teilt.

OffTopic:

---

Die GoF beißen sich sicherlich mittlerweile in den Hintern, dass sie das mit aufgenommen haben...

Das ist mir schnurz. Sowas kommt halt dabei heraus, wenn man die Realität in Schablonen pressen will.

---

Singletons sind insofern interessant, weil man sie in PHP nur mithilfe von statischen Methoden bauen kann (notfalls noch mit einer "gewöhnlichen" Funktion).

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.

Und schließlich ist ein Singleton in PHP eine Alternative zu einer "rein statischen" Klasse, wenn sowas wie ein Konstruktor oder/und ein Destruktor gebraucht wird. Mehr als ein paar skalare Werte kann man einer Klasse bei der "Initialisierung" ja nicht mitgeben, und das "Aufräumen" am Schluss geht nur über Krücken.

[combie]

Die "Gang of Four" haben ein durchaus lesenswertes Buch geschrieben.
u.A. hier erwähnt: Entwurfsmuster ? Wikipedia

Es wurde nur zu oft bei jedem Mist progagiert. Zum Beispiel bei Datenbank-Verbindungen.

100% richtig!

[Kropff]

Was ist ein GoF? Ich kenne die FoBs und die FoGs. Aber GoFs? Btw: Ein Singleton ist kein Anti-Pattern. Es wurde nur zu oft bei jedem Mist progagiert. Zum Beispiel bei Datenbank-Verbindungen.

Peter

[combie]

Ich verweise hier nur auf Singletons.

Die GoF beißen sich sicherlich mittlerweile in den Hintern, dass sie das mit aufgenommen haben...
Und auch für mich ist das eine echtes "anti Pattern".

[Kropff]

Das wäre EIN Weg von mehreren. Du könntest auch ein zusätzliches Objekt erstellen, welches die Zusammenarbeit koordiniert.

Das ist wie so oft Ansichtssache. Viele Wege führen nach Rom. Mich stört es aber, wenn nur ein(!) Weg progagiert wird. Wenn statische Eigenschaften und Methoden aus Sicht der Informatik Müll wären, hätte man sie nicht in diverse Sprachen eingebaut. Ich verweise hier nur auf Singletons.

Peter

[fireweasel]

Das sehe ich anders. Wenn mehrere Objekte eine gemeinsame Basis benötigen, so sind statische Methoden und Eigenschaften eine Form von Kommunikation zwischen den einzelnen Objekten.

Das wäre EIN Weg von mehreren. Du könntest auch ein zusätzliches Objekt erstellen, welches die Zusammenarbeit koordiniert.

[combie]

Das sehe ich anders. Wenn mehrere Objekte eine gemeinsame Basis benötigen, so sind statische Methoden und Eigenschaften eine Form von Kommunikation zwischen den einzelnen Objekten.

Peter

Wie wäre es mal mit einem konkreten Beispiel...