Im ersten Beitrag dieser Serie habe ich darüber gesprochen, wie ich eine Einführung in die objektorientierte Programmierung im Kontext von WordPress angehen wollte.

Es gibt einige großartige Ressourcen für die objektorientierte Programmierung, aber sie können erfundene Beispiele verwenden oder sich zu schnell bewegen für diejenigen, die nur anfangen möchten.

Um dies zu verhindern, denke ich, dass das Reden über OOP in WordPress uns auf einer starken Grundlage verankert und die Verwendung praktischer Beispiele immer besser ist als die Verwendung allgemeiner Beispiele, die schwer in den Bereich zu übersetzen sind, in dem wir arbeiten.

Für diejenigen, die noch beitreten oder noch nicht aufgeholt haben, befasst sich der erste Beitrag mit den folgenden Themen:

• Objektorientierte Analyse,
• Bestimmung von Must-Haves versus Nice-To-Haves,
• Und warum ist es schwer?

Und genau da wird dieser Beitrag anknüpfen.

Objektorientierte Programmierung: Mehr Analyse

Ich weiß: Wenn es darum geht, Code zu schreiben, wollen wir uns als erstes hinsetzen und anfangen, Code zu schreiben. Was gibt es Schöneres, als etwas auf dem Bildschirm passieren zu lassen?

Und wenn Sie das für sich selbst tun, ist es keine große Sache, aber wenn Sie Code schreiben, wird das sein:

• gepflegt von einem Team von Menschen,
• zu verkaufen,
• oder für alle oben genannten

Es macht einen Unterschied. Denn eine gute Analyse kann zu einer guten Organisation führen, die zu einer guten Wartbarkeit führen kann.

Andernfalls basteln Sie etwas zusammen, um es zu versenden, und es wird sich nicht gut mit zukünftigen Versionen skalieren lassen. Und das ist etwas, worüber wir in der gesamten Serie ausführlich sprechen werden.

Aber wie lässt sich eine gute Analyse in drei einfachen Schritten zusammenfassen? Dies ist nicht unbedingt eine kugelsichere Antwort, aber wir versuchen dies zu tun, wenn wir an Projekten arbeiten:

1. Stellen Sie sicher, dass der Code das tut, was der Client will,
2. Wenden Sie gute objektorientierte Praktiken an,
3. Streben Sie ein wartbares Design an.

Theoretisch klingt das alles gut, aber ohne näher darauf einzugehen, woher wissen wir, ob wir das richtig machen? Mit anderen Worten, hier finden wir oft Bücher, Ressourcen und andere Dienstprogramme, die es schwierig machen, ein besserer objektorientierter Programmierer zu werden.

Genau das möchte ich vermeiden, also gehe ich auf jeden Punkt etwas tiefer ein.

1 Was der Kunde will

Dies kann oft einer der herausforderndsten Aspekte des gesamten Projekts sein, da wir als Entwickler eine andere Sprache sprechen als der Kunde.

Sie verwenden nicht nur oft eine Terminologie, die wir nicht verwenden würden, sie denken oft, dass das, was sie auf dem Bildschirm haben wollen, der beste Weg ist, dies zu tun. Das lässt es wirklich herablassend und falsch klingen, zu versuchen, sie zu korrigieren, nicht wahr?

Ich meine, stellen Sie sich vor, Sie versuchen jemandem zu sagen, dass Sie wissen, was Sie wollen, und er korrigiert Sie. Sorgfältig damit umzugehen ist etwas, das eine große Beziehungsgerechtigkeit schaffen kann, aber es braucht eine gewisse Zeit, um „auszugraben“, was sie wirklich wollen im Vergleich zu dem, was sie sagen, dass sie wollen.

Und wir werden in einem zukünftigen Beitrag mehr darauf eingehen.

2 Objektorientierte Praktiken

Offensichtlich ergibt sich dies daraus, dass ich weiß, was die guten objektorientierten Praktiken sind, und das ist etwas, das ich behandeln möchte.

Viele Leute sagen Dinge mit Dingen wie:

• die SOLID-Prinzipien,
• Nachlass,
• DRY-Code,
• Abhängigkeitsspritze,
• usw

Sind alle wichtig, um gute objektorientierte Praktiken zu befolgen.

Und vielleicht ist das keine beliebte Aussage, aber ich bin der Meinung, dass es nicht immer eine gute Idee ist, zu versuchen, alle Dinge die ganze Zeit zu benutzen. Das heißt, Sie möchten definitiv keinen Code in Ihrer gesamten Codebasis wiederholen, aber müssen Sie Vererbung in Ihrer Codebasis haben?

Nein.

Es gibt Zeiten, in denen Prinzipien angewendet werden sollten und in denen sie ignoriert werden können. Aber sie zu kennen, wann sie am besten verwendet werden und wann sie zu verwenden sind, ist der Schlüssel zur richtigen Anwendung dieser Praktiken.

3 Wartbares Design

Einfach ausgedrückt, die Anwendung von Mustern und Prinzipien auf Ihre Software beim Schreiben wird es viel einfacher machen, sie in Zukunft zu verwenden und zu warten.

Dies ist aber wiederum abhängig von:

1. vollständig verstehen, was der Kunde will,
2. Wissen, welche Praktiken es gibt, wann man sie anwendet und wann man sie vermeidet.

Und um all dies zu tun, müssen wir jeden Punkt in seinem Kontext betrachten, bevor wir einen Schritt zurücktreten, um das Gesamtbild zu betrachten.

Was will der Kunde?

Offensichtlich gibt es viel zu tun, wenn es um die oben genannten drei Punkte geht. Aber wenn Sie gute, wartbare Software innerhalb der WordPress-Ökonomie schreiben möchten, ist es wichtig zu verstehen, wie all dies zusammenpasst.

Anstatt also Code zu schreiben oder an einem Projekt zu arbeiten, werden wir uns als Nächstes damit befassen, wie wir die Wünsche des Kunden nehmen und diese dann in eine Reihe von Anforderungen entschlüsseln können, die es uns ermöglichen, eine zu erstellen Lastenheft.

Auf diese Weise haben wir letztendlich ein Arbeitsdokument darüber, was der Kunde will und was wir bauen werden, und wir werden alle auf derselben Seite sein.