Wird Perl-Code hauptsächlich in objektorientiertem Design geschrieben?

Question

Da es für fast alles ein Modul gibt und es immer wieder heißt, dass wir das Rad nicht neu erfinden sollten und da ich keine Module für CPAN schreibe, brauche ich kein OO zu verwenden. Aber meine Frage ist, ist professioneller Perl-Code hauptsächlich in OO-Stil geschrieben?

Answer 1

Kurz gesagt, nur wenn Sie Code-Wiederverwendbarkeit und Lesbarkeit wollen; Zum Schreiben von einfachen Systemskripten oder Code, um eine Aufgabe auszuführen, ist es eine Verschwendung, besonders wenn es sich um Dinge handelt, die nicht gut dokumentiert sind. Wenn man beispielsweise ein komplexes Programm schreibt, hilft es wirklich, seine Gedanken zu ordnen und das Problem zu modularisieren, indem man eine Reihe von Modulen schreibt. Die Vorteile der Objektorientierung steigen exponentiell, wenn Sie an einem Projekt mit mehr als einem Entwickler arbeiten.

Answer 2

Der meiste Perl-Code, den ich schreibe, ist kleinformatige Skripte und ich benutze niemals OOP für sie, auch wenn sie CPAN-Module verwenden, die OOP-entworfen sind. Für die größeren Code-Projekte tendiere ich ungefähr 70% der Zeit zu OOP, aber es hängt davon ab: Wird der Code für eine lange Zeit verwendet werden? Wenn es wahrscheinlich bleibt, und viele Benutzer werden ihre Löffel in den Mix eintauchen, ist OOP wahrscheinlich ein besseres Design.

Answer 3

OO-Design ist keine "Wunderwaffe". Es gibt keinen Schaden beim Schreiben von Code, der nicht-OO ist. Es ist nur die "beliebte" Wahl. Als jemand sagte einmal (und ich paraphrasieren):

OO-design simply had a better marketing group 

Dies ist nur aus der Tatsache ergeben, dass die Menschen „die meisten Code“ sollte glauben OO sein. Natürlich können Sie den Zustand "intern in einem Objekt" verfolgen, aber es werden auch Leute dazu gebracht, dumme Dinge innerhalb des Objekts zu tun, die die Dinge auch komplizierter machen.

Mein Problem ist mit "die meisten Code in OO geschrieben". Ich glaube, dass es ein gesundes Gleichgewicht zwischen Objekten und Funktionen geben sollte. Funktionen können auf Objekte angewendet werden.

Es gibt viele Dinge, die sich für Objekte nicht gut eignen.

Answer 4

Wenn Sie ein einfaches Skript schreiben, um eine relativ einfache Verarbeitung, Dateimodifikation usw. durchzuführen, ist es in Ordnung, mit einem Nicht-OO-Design zu gehen, aber nach meiner Erfahrung wird Ihr Skript länger herumlaufen und potentiell Dinge tun Vielleicht möchten Sie eines Tages in einem anderen Skript oder in einem anderen Kontext als dem, was Sie für den OO-Ansatz geplant haben, wiederverwenden. Im Allgemeinen ist es auch viel einfacher, ein OO-basiertes Design zu skalieren und zu verbessern.

Insbesondere wenn es um die Darstellung von Daten jeglicher Art geht. Sobald Sie eine Klasse zur Darstellung dieser Daten geschrieben haben, ist es sehr praktisch, dieser Datenklasse nützliche Methoden hinzuzufügen (z. B. Anzeigen, Prüfen, Analysieren, Zurücksetzen, Schreiben in Datei, Laden aus Datei usw.).

Dies hat auch einen positiven Nebeneffekt davon, dass Ihre Skripte weniger ausführlich und einfach zu lesen und zu warten sind, da viele Details der Datenverarbeitung den Klassenmethoden überlassen werden. Wenn Sie mit großen Datenmengen zu tun haben, ist es auch viel einfacher, mit Arrays von Objekten umzugehen als mit Hashes, die Sie wahrscheinlich am Ende verwenden werden, wenn Sie kein OO-Design haben.

Wenn Sie in Zukunft ein Skript schreiben müssen, um dieselben Daten auf andere Weise zu verarbeiten, können Sie die Datenklassen einfach in einem anderen Skript wiederverwenden. Wenn Ihre Daten etwas anders sind, müssen Sie mehr Felder oder Methoden hinzufügen. Kein Problem, einfach die ursprüngliche Datenklasse erweitern.

Die beste Referenz für das Lernen OO Perl, die ich gefunden habe, ist: Objektorientierte Perl: Ein umfassender Leitfaden für Konzepte und Programmiertechniken von Damian Conway.Eines der Dinge, mit denen ich zu kämpfen hatte, als ich anfing, OO Perl zu machen, ist, dass es so viele verschiedene Möglichkeiten gibt, es zu tun. Irgendwann habe ich mich auf einen festgelegt und bin über die Jahre mit ihm geblieben.

Answer 5

Ich sehe OOP in erster Linie als eine Möglichkeit zum Binden und Festlegen von Verhaltensweisen zu einer Datenstruktur. Jedes Mal, wenn meine Datenstrukturen aussehen, als würden sie kompliziert werden, komponiere ich Objekte.

Dies hilft, den Code in Bezug auf die Manipulation der Daten zu zentralisieren und zu abstrahieren. Dies wiederum reduziert doppelten Code und vereinfacht das Refactoring. Die gleichen Dinge könnten mit rein prozeduralem Code erreicht werden. Ich finde, dass OOP die Beziehung explizit und einfacher auf eine intuitive Weise zu konzeptualisieren macht.

Betrachten Sie diese Struktur:

my $foo = { 
    meezle => [qw(a d g e l z)], 
    twill => { 
     prat => 'qua', 
     nolk => 'roo', 
    }, 
    chaw => 7, 
    mubb => [ 123, 423,756, 432 ], 
    ertet => 'geflet', 
}; 

Wenn ich mit einer Struktur wie dieser (verschachtelte und nicht einheitlich) aufzuwickeln, beginne ich „Objekt“ zu denken. Ich werde sicher, wenn ich viel Code schreibe, um auf Daten in der Struktur zuzugreifen, sie zu modifizieren und zu validieren.

Da die meisten nicht-trivialen Projekte nicht-triviale Datenmanipulationen erfordern, verwende ich Objekte für mindestens einen Teil der meisten Jobs.

Ich kann oder darf nicht alles in meinem OOP gehen. Normalerweise gibt es ein paar Dinge, die keine Objekte sind. Es kann eine Anwendungsbasisklasse geben oder auch nicht. Einige Elemente können als normaler prozeduraler Code behandelt werden. Einige können funktionelle Ansätze beinhalten. Alles hängt davon ab, was angesichts der Anforderungen des Projekts sinnvoll ist.

Die wichtigste Sache zu erinnern ist, dass Ihr Code klar sein muss, um den armen Schmuck mit der Wartung beauftragt. (Es könnte Sie in 6 Monaten sein, neu aus tiefem 4am aufgewacht, schlafen, mit Chef Chef Ihres Chefs, der Sie anschreie, um die verdammte Software zu reparieren, bevor die Firma bankrott ist.)