2017-05-24 2 views
0

Ich lese Zed Shaw Ruby Einführung Buch. Ich bin auf einen Code gestoßen, den ich nicht ganz verstehe.Stück Ruby Code ist verwirrend - super

class Person 

def initialize(name) 
    @name = name 
    @pet = nil 
end 

attr_accessor :pet 
end 

class Employee < Person 

def initialize(name, salary) 
    super(name) 
    @salary = salary 
end 

attr_accessor :salary, :name 
end 

Ich verstehe den super (Name) Teil sehr grob. Ich glaube, das bedeutet, dass es sich auf die Elternklasse bezieht? Ich bin mir nicht sicher, ob ich verstehe, warum dies in der realen Welt geschehen würde. Warum sollte jemand Super (name) machen anstatt nur @name = name zu schreiben?

Ich lerne immer noch. Danke im Voraus!

Antwort

5

Warum sollte jemand super (name) anstatt nur @name = name schreiben?

Lassen Sie uns aus einem anderen Blickwinkel betrachten. Warum sollte jemand die (möglicherweise komplexe) Funktionalität duplizieren, die bereits in der Elternklasse existiert, anstatt die Arbeit einfach an die Eltern zu delegieren?

Wenn Sie die Funktionalität duplizieren und die Anforderungen ändern, müssen Sie alle Kopien ändern. Dies ist fehleranfällig und unnötig teuer (in Bezug auf Zeit/Aufwand).

1

Ich sehe hier zwei verschiedene Programmier-Best-Practices.

Zuerst ist das beste Verfahren, Code niemals zu duplizieren. Sie werden sehen, oft Code wie folgt:

class MyClass 

    def blah 
    @blah 
    end 

    def do_something 
    puts blah 
    end 

end 

Sie mögen sich fragen, „warum der Programmierer die Methode aufrufen blah(), wenn sie nur die Variable @blah stattdessen könnte die Antwort ist, dass @blah jetzt eine einfache Variable sein kann? was aber, wenn Sie es in einem Hash zu speichern und später, zugänglich wie myData[:blah]? es wäre ein Schmerz durch jede Zeile Code zu gehen, für jeden @blah suchen und es zu myData[:blah] ändern. Verwendung des Verfahrens blah() stellt sicher, dass, wenn Sie jemals ändern Sie die Art und Weise @blah funktioniert, müssen Sie nur an einem Ort ändern: die Methode

Das gleiche gilt für super(name) vs @name = name. Im Moment könnte die initialize() Methode für Person einfach sein, aber irgendwann könnte es wirklich kompliziert werden. Sie würde nicht wollen den Code jeder Klasse ändern müssen Person vererben, so ist es am besten super() zu nennen.


Zweitens ist die beste Praxis der Verkapselung. Stellen Sie sich für eine Sekunde, dass Ihr Code wie folgt aussieht statt:

require "person" 

class Employee < Person 

    def initialize(name, salary) 
    super(name) 
    @salary = salary 
    end 

    attr_accessor :salary, :name 
end 

In der objektorientierten Programmierung ist es üblich, Bibliotheken, die von anderen Menschen gemacht zu bedienen, mit Klassen und Objekten, die Sie nicht schreiben und nicht haben die Fähigkeit sich zu ändern.

Encapsulation ist die Idee, dass eine Klasse eine autarke und unabhängige Maschine ist. Sie übergeben ihm Eingabedaten und empfangen Ausgabedaten, aber Sie haben keine Ahnung, was im Inneren passiert. Also in diesem Code, obwohl EmployeePerson erbt, sollte Employee keine Annahmen darüber, was die Person Klasse unter der Haube tut. Der Aufruf super(name) vertraut, Person selbst einzurichten, ohne sich Gedanken über die Details, wie ein Person sollte eingerichtet werden.

Auch wenn die beiden Klassen in der gleichen Datei geschrieben sind und Sie den Quellcode für beide sehen können, ist es wichtig, die Best Practice der Kapselung zu befolgen, um Ihren Code sauber und robust für Ihre zukünftigen selbst und andere Programmierer zu halten Eines Tages könnten sich diese beiden Klassen in verschiedenen Dateien oder sogar in verschiedenen Bibliotheken befinden.