Wie hat sich OOP entwickelt, um den Begriff der Eigenschaften aufzunehmen?

11

Ich komme aus einem C ++ - Umfeld und habe in meinem aktuellen Job alles mit C # zu tun. Ich habe gerade eine Menge Fragen und Antworten darüber gelesen, was der Unterschied zwischen öffentlichen Feldern und Eigenschaften und all dem Hin und Her in Variationen und Inkarnationen davon ist Grundfrage (zB dieser SO-Beitrag und alle damit verbundenen verknüpften Fragen ). All diese Fragen werden im Hinblick auf praktische Unterschiede behandelt, die die Existenz eines Immobiliensystems für selbstverständlich halten, aber ich denke, es wäre gut, dieses Thema im Hinblick auf das zu betrachten, was die Designer aller Sprachen, die sich entschieden haben, Immobilien im ersten zu unterstützen Ort haben nachgedacht (siehe die Liste im Wikipedia-Artikel hier). Wie hat sich OOP von C ++ / Java zu dem entwickelt, was der Wikipedia-Artikel interessanterweise als Mittelweg zwischen Methoden und Mitgliedsdaten identifiziert:

"Das heißt, Eigenschaften liegen zwischen Elementcode (Methoden) und Elementdaten (Instanzvariablen) der Klasse, und Eigenschaften bieten eine höhere Kapselungsstufe als öffentliche Felder."

MSDN fügt weiteren Hintergrund hinzu:

"Obwohl Eigenschaften Methoden technisch sehr ähnlich sind, unterscheiden sie sich in ihren Verwendungsszenarien erheblich. Sie sollten als intelligente Felder angesehen werden. Sie haben die aufrufende Syntax von Feldern und die Flexibilität von Methoden."

Ich würde gerne wissen, wie es dazu kam, dass sich diese mittlere Kapselungsstufe für die Programmierung im Allgemeinen als nützlich erwies. Ich gehe davon aus, dass dieses Konzept bei der ersten Inkarnation von Programmiersprachen, die das OOP-Paradigma ausdrückten, nicht vorhanden war.

jxramos
quelle
8
Die Bare-Language-Funktion ist nur ein praktischer syntaktischer Zucker für Getter- und Setter-Methoden. Ob es tiefere Gründe für die Interpretation und Terminologie gibt, weiß ich nicht.
In einer Runde von OO-Experten kann Ihr Fragentitel provozieren und von dem ablenken, was Sie wirklich gefragt haben. Nicht dass ich mich selbst als OO-Experte betrachte, ich bin nur ein "OO-Benutzer" für mehrere Jahre.
Doc Brown
Es ist eine syntaktische Besonderheit, die ich vermisst habe, von 'parameterlosen Methoden' in Python zu C ++ zu wechseln. BMI = bob.weight/sq(bob.height)liest sich besser ohne ()IMO.
OJFord
Ich denke, Eigenschaften waren im ursprünglichen (nicht .net) Visual Basic, um Active X (COM) -Objekt zu konfigurieren. Das Eigenschaftsraster in diesem Tool hatte wahrscheinlich etwas mit der Übernahme von Eigenschaften in Sprachen zu tun. Beachten Sie, dass das ursprüngliche Visual Basic in vielerlei Hinsicht nicht objektorientiert war, aber die Fähigkeit hatte, so etwas wie Klassen zu erstellen.
Frank Hileman
Fortsetzung: Das Eigenschaftenfenster war eine Möglichkeit, Objekte zu konfigurieren, ohne Code zu schreiben. Es wurde RAD-Entwicklung genannt. Dieser Link enthält einen Screenshot des VB6-Eigenschaftenfensters: microsoft.com/mspress/books/WW/sampchap/4068.aspx
Frank Hileman

Antworten:

5

Alles dreht sich um die Kapselung und das Prinzip des einheitlichen Zugriffs.

Ein Objekt sollte in der Lage sein, auf eine Nachricht zu antworten, indem es entweder vorhandene Daten zurückgibt oder eine Methode ausführt, aber der Absender sollte nicht erkennen können, welche welche ist. Oder wenn Sie dies von der Seite des Absenders aus betrachten: Der Absender sollte in der Lage sein, auf vorhandene Daten zuzugreifen oder eine Methode über eine einheitliche Schnittstelle auszuführen.

Es gibt verschiedene Möglichkeiten, dies zu erreichen:

  • Daten insgesamt loswerden, nur Methoden haben (Newspeak macht das)

    • eine weniger radikale Form des oben Gesagten: Daten in der öffentlichen Schnittstelle entfernen , dh Daten immer privat machen, in der öffentlichen Schnittstelle nur Methoden verfügbar machen (Smalltalk, Ruby tun dies)
  • Methoden insgesamt loswerden, nur Daten haben (Selbst tut dies, "Methoden" sind nur MethodObjekte, die Instanzvariablen zugewiesen sind, Instanzvariablen werden mit virtuellem Versand nachgeschlagen)

  • Nehmen Sie keine syntaktische oder semantische Unterscheidung zwischen Methoden und Daten vor (Scala führt dies aus. Der Zugriff auf ein Feld ist syntaktisch nicht vom Aufrufen einer Methode ohne Argumentliste ( foo.bar) zu unterscheiden. Die Zuweisung zu einem Feld ist syntaktisch nicht vom Aufrufen einer speziell benannten Methode ( foo.bar = baz) zu unterscheiden B. das foo.bar_=(baz)Aufrufen einer benannten Methode foo_=und schreibgeschützte Werte können von einer Methode ohne Parameterliste überschrieben oder implementiert werden (dh val foo) in einer Oberklasse kann abstract valin einer Unterklasse mit einer Methode überschrieben (oder implementiert def foo) werden.

Java folgt jedoch nicht dem Prinzip des einheitlichen Zugriffs. In Java kann zwischen dem Zugriff auf Daten und dem Ausführen einer Methode unterschieden werden. foo.barist anders als foo.bar(). Der Grund dafür ist, dass Felder und Methoden semantisch und syntaktisch unterschiedlich sind.

C # versucht, dies zu beheben, indem der Sprache Eigenschaften hinzugefügt werden, im Grunde Methoden, die wie Felder aussehen. Methodenaufrufe sehen jedoch immer noch anders aus als Feld- und Eigenschaftszugriffe. Felder und Eigenschaften haben jetzt einheitlichen Zugriff, Methoden jedoch immer noch nicht.

Dies behebt das Problem also nicht wirklich: Sie können nicht zwei verschiedene Möglichkeiten für den Zugriff auf Dinge beheben, indem Sie eine dritte Möglichkeit für den Zugriff auf Dinge hinzufügen! Selbst wenn dieser dritte Weg wie einer der beiden anderen Wege aussieht, haben Sie (mindestens) zwei verschiedene Wege. Sie können das Problem nur beheben, indem Sie entweder alle verschiedenen Möglichkeiten außer einer oder die Unterschiede beseitigen.

Es ist vollkommen in Ordnung, eine Sprache mit Methoden, Eigenschaften und Feldern zu haben, aber alle drei sollten einen einheitlichen Zugriff haben.

Jörg W Mittag
quelle
1
Warum halten Sie (und andere) die Aufrechterhaltung eines einheitlichen Zugangs für so wichtig? Mit einer Methode möchten Sie ihr möglicherweise Parameter geben, um zu ändern, was sie tut oder wie sie wirkt. Bei einem Feld oder einer Eigenschaft, über die Sie nicht verfügen, geben Sie im Allgemeinen nur Daten zurück (obwohl eine Eigenschaft so implementiert werden kann, dass eine Methode ausgeführt wird, anstatt nur ein privates Feld verfügbar zu machen). Das erscheint mir intuitiv, vielleicht nur, weil ich daran gewöhnt bin, aber was würden Sie an Eleganz oder Produktivität gewinnen, wenn Sie einen einheitlichen Zugang erzwingen? Haben Sie Angst, dass Sie Implementierungsdetails außerhalb der Klasse preisgeben?
Mike unterstützt Monica
1
Beim UAP geht es darum, die Freiheit zu behalten, Implementierungsdetails zu ändern, ohne die öffentliche Schnittstelle zu beschädigen. Das übliche Beispiel ist das Hinzufügen von Protokollierung. Wenn ich den Zugriff über eine Methode anbiete, kann ich die Interna der Methode trivial ändern, um sie in ein Protokoll zu schreiben. Bei einem öffentlichen Feld kann ich keine Protokollierung hinzufügen, ohne sie zuvor in eine Methode umzuwandeln, die den gesamten Clientcode zerstört. Wenn Änderungen nicht riskiert werden können, ist die Verwendung von Methoden ein Muss. Eigenschaften sind der optimale Kompromiss, da es sich um vollständige Methoden handelt, die jedoch wie Felder aussehen. Das Festhalten an der UAP verbessert die Einkapselung und verringert die enge Kopplung.
Amon
Viele gute Antworten auf diese Frage, aber ich denke, diese hat den Nagel auf den Kopf getroffen, indem sie die grundlegenderen Aspekte der Natur von Programmiersprachen herausgearbeitet und das relevante formale Konzept von UAP herausgearbeitet hat. Solid
jxramos
18

Nun, ich bin nicht 100% sicher, aber ich denke, die Dinge sind wahrscheinlich einfacher als Sie erwarten. Von den OO-Modellierungsschulen der 90er Jahre gab es eine Nachfrage nach Modellierungsklassen mit gekapselten Mitgliedsattributen, und wenn sie in Sprachen wie C ++ oder Java implementiert wurden, führte dies normalerweise zu Code mit vielen Gettern und Setzern, also viel "Rauschen". Code für eine relativ einfache Anforderung. Beachten Sie, dass die meisten (wahrscheinlich alle, die dies nicht überprüft haben) der in Ihrem verlinkten Wikipedia-Artikel aufgeführten Sprachen Ende der 90er Jahre oder später damit begannen, "Eigenschaften" von Objekten einzuführen.

Ich denke, das war der Hauptgrund, warum Sprachdesigner beschlossen, syntaktischen Zucker hinzuzufügen, um dieses Rauschen zu reduzieren. Und obwohl Eigenschaften sicherlich kein "Kern-OO-Konzept" sind, haben sie zumindest etwas mit der Objektorientierung zu tun. Sie zeigen keine "Entwicklung von OOP" (wie in Ihrem Fragentitel angenommen), unterstützen jedoch die OO- Modellierung auf der Ebene der Programmiersprache, um die Implementierung zu vereinfachen.

Doc Brown
quelle
Es hat nichts mit objektorientierter Programmierung zu tun, außer in dem Sinne, dass eine Eigenschaft eine Abstraktion eines Feldes ist und Felder Teil der objektorientierten Programmierung sind. Wie Sie richtig bemerken, werden für die objektorientierte Programmierung jedoch keine Eigenschaften benötigt.
Frank Hileman
2
@FrankHileman: „eine Eigenschaft ist eine Abstraktion eines Feldes, und Felder sind Teil der objektorientierten Programmierung“ - nun ja, das klingt für mich wie Sie das Konzept zustimmen hat tatsächlich zumindest etwas mit OOP zu tun. Und deshalb hast du mich herabgestimmt?
Doc Brown
3
lol. Kannst du ihm die Schuld geben? Er rutschte von seiner Toilette und schlug mit dem Kopf auf sein Waschbecken. Wie auch immer ... Ich habe es immer so gesehen, dass Immobilien keine reine OO-Sache sind. Sie helfen bei der Einkapselung und die Einkapselung hilft bei der OO.
MetaFight
1
Ha! Dies ist für mich eine Einführung in programmers.stackexchange. Lol, viel heißer als meine vergleichbare Erfahrung mit einfachem Stackoverflow :-p Gute Möglichkeit, den Tag zu verwechseln!
Jxramos
11

Sie haben es rückwärts (irgendwie). Lambda Calculus ist seit Jahrzehnten die wichtigste formale Grundlage für Programmiersprachen. Es hat keine Felder.

Um einen veränderlichen Zustand zu modellieren, müssen Sie zwei Abstraktionen erstellen. Eine stellt das Festlegen eines Status dar und eine andere, die diesen Status abruft (Kapitel 13 in meiner Version von TaPL als Referenz). Klingt bekannt? Aus theoretischer Sicht hat sich OO nicht weiterentwickelt, um dieses Zeug zu haben. OO las Programmiersprachen 101 und machte einen kleinen Schritt nach vorne.

Aus praktischer Sicht gibt es zwei ziemlich klare Motivationen. Sie haben einen C ++ - Hintergrund. Was müsste also passieren, wenn Sie ein öffentliches Feld hätten? Sagen Sie ... den Text in einem Textfeld. Was passiert, wenn Sie Ihr Design so ändern möchten, dass "wann immer sich dieses Textfeld ändert, tun Sie es bla"? Sie können dieses Feld töten, eine oder zwei Funktionen erstellen und diese Logik verkabeln, da Sie Entwicklern nicht vertrauen können, dass sie "UpdateTextbox" selbst aufrufen. Dies ist eine sehr bahnbrechende Änderung an Ihrer API (und leider immer noch eine bahnbrechende Änderung an der Implementierung von Eigenschaften in .NET). Diese Art von Verhalten ist ganz über den Platz in dem Windows - API. Da dies bei Microsoft eine große Sache ist, wollte C # dies wahrscheinlich weniger schmerzhaft machen.

Die andere große Motivation sind Java Beans und ihre Verwandten. Eine Reihe von Frameworks wurden gebaut für Java Reflexion Look zu verwenden GetXund SetXPaare und effektiv wie moderne Eigenschaften zu behandeln. Da es sich jedoch nicht um tatsächliche Sprachkonstrukte handelte, waren diese Frameworks fragil und unfreundlich. Wenn Sie einen Namen tippen würden, würden die Dinge einfach lautlos brechen. Wenn einer umgestaltet wurde, bewegte sich nichts auf der anderen Seite des Grundstücks. Und das ganze Feld / Get / Set-Boilerplate zu machen war ausführlich und mühsam (sogar für Java!). Da C # größtenteils als "Java mit gewonnenen Erkenntnissen" entwickelt wurde, war diese Art von Schmerz eine dieser Lektionen.

Das Größte ist jedoch, dass das Immobilienkonzept erfolgreich war. Es ist leicht zu verstehen, es ist einfach zu bedienen. Diese helfen bei der Einführung erheblich, und als Werkzeug haben Programmierer festgestellt, dass Eigenschaften eine Teilmenge von Problemen sauberer lösen als Funktionen oder Felder.

Telastyn
quelle
7
Ich habe Sie meistens wegen zu vieler Hinweise auf irrelevanten formalen Mist herabgestimmt. Tatsächliche Implementierungen von Programmiersprachen müssen viel schwerwiegendere Aspekte berücksichtigen, als ob ihr Modell in die Lambda-Rechnung aufgenommen wurde oder nicht.
DeadMG
9
@DeadMG - das ist sicherlich wahr, aber andererseits werden Programmiersprachenimplementierer immer mit diesem irrelevanten formalen Mist vertraut sein . Zu denken, dass es ihre Designs nicht beeinflusst hat, ist naiv.
Telastyn
3
Dies ist definitiv kein "irrelevanter formaler Mist". Der Lambda-Kalkül wurde jedoch für frühe Programmiersprachen möglicherweise nicht viel berücksichtigt. In diesem Fall wären CPUs wahrscheinlich eher auf diese Mentalität ausgerichtet.
Frank Hileman
3
@ FrankHileman - Ich bin mir ziemlich sicher, dass Lisp darüber nachgedacht hat ...
Telastyn
4
@Telastyn - ja - und Lisp sollte ursprünglich keine Programmiersprache sein, erinnerst du dich?
Frank Hileman
3

Insbesondere in .net stammen Eigenschaften aus den alten Visual Basic-Tagen, die nicht so objektorientiert waren, wie wir es heute sehen. Es wurde größtenteils um das damals neue COM-System herum aufgebaut, das oberflächlich alles nicht unbedingt als Klassen behandelte, sondern als Komponenten, die Eigenschaften offenlegen würden, auf die sowohl im Code als auch in grafischen Editoren zugegriffen werden konnte. Als VB und das neu erstellte C # in .net zusammengeführt wurden, erhielt VB eine ganze Reihe von OOP-Funktionen und behielt die Eigenschaften bei, da das Entfernen wie ein Rückschritt wäre - stellen Sie sich vor, das automatische Code-Update-Tool in Visual Studio wäre es gewesen Das Ersetzen aller Ihrer Eigenschaften durch Getter und Setter hat die Kompatibilität mit allen COM-Bibliotheken beeinträchtigt. Es wäre nur logisch, sie insgesamt zu unterstützen.

Niwax
quelle
Ich denke nicht, dass Sie C #s Vorfahren ignorieren sollten, die von Delphi und zuvor von Object Pascal und Turbo Pascal mit Objekten stammten. Diese waren objektorientiert und hatten Eigenschaften (obwohl ich mich nicht erinnern kann, ob OP Eigenschaften von TP5.5 hatte oder ob sie hinzugefügt wurden; vermutlich wurden sie von Anders in C # fortgesetzt, weil sie pragmatisch eine gute Idee waren.
amaca
Sehr interessant, dass Sie zufällig der einzige waren, der auf den Komponentenaspekt dieser Frage gestoßen ist. Ich habe meiner Frage gerade einen Kommentar hinzugefügt, der auf eine Site verweist, auf der Eigenschaften als Teil eines Ereignismodells für Eigenschaften, Methoden und Methoden aufgeführt sind, das C # erfüllt. Ich habe dann die Seite meiner Frage erneut nach "Komponente" durchsucht und dabei ein paar Fehlalarme erhalten, aber Ihre Antwort überschneidet sich meiner Meinung nach tatsächlich mit dem, mit dem ich verlinkt habe.
Jxramos
3

Eigenschaften haben nichts mit objektorientierter Programmierung zu tun, da Eigenschaften nur syntaktischer Zucker sind. Eigenschaften sehen oberflächlich wie Felder aus, und in der .net-Welt wird empfohlen, dass sie sich in gewisser Weise wie Felder verhalten, aber in keiner Weise Felder sind. Eigenschaften sind syntaktischer Zucker für eine oder zwei Methoden: eine zum Abrufen eines Werts und eine zum Festlegen eines Werts. Entweder die set-Methode oder die get-Methode können weggelassen werden, aber nicht beide. Möglicherweise ist kein Feld vorhanden, in dem der von der get-Methode zurückgegebene Wert gespeichert ist. Da sie eine Syntax mit Feldern teilen und häufig Felder verwenden, verknüpfen Benutzer Eigenschaften mit Feldern.

Eigenschaften haben Vorteile gegenüber Feldern:

  • In einer Eigenschaftssatzmethode kann vor dem Speichern eines Eigenschaftswerts der neue Wert oder der Status des Objekts anhand einer Reihe von Voraussetzungen oder Invarianten überprüft werden.
  • Eine Eigenschaftsabrufmethode kann der Einfachheit halber existieren, wenn das Abrufen des Eigenschaftswerts logisch als dem Abrufen eines Feldwerts äquivalent angesehen werden kann.
  • Eine Eigenschaftssatzmethode kann andere Vorgänge ausführen, z. B. das Benachrichtigen eines übergeordneten Objekts oder das Abhören von Objekten über eine Änderung eines Eigenschaftswerts.

Da Eigenschaften die Abstraktion von Feldern sind und aus syntaktischen Gründen Sprachen wie C # die Feldsyntax für Eigenschaften übernehmen.

Frank Hileman
quelle
2
Erste Zeile aus dem Wikipedia-Artikel. "Eine Eigenschaft ist in einigen objektorientierten Programmiersprachen eine besondere Art von Klassenmitglied ...". Ihr erster Satz ist also einfach falsch. Und der verbleibende Teil beantwortet die Frage nicht.
Doc Brown
1
@ DocBrown: Interessante Antwort. Viele Wikipedia-Artikel sind eindeutig falsch. Ich nehme an, Sie verteidigen den Autor dieses speziellen Artikels?
Frank Hileman
1
Nicht alle Merkmale objektorientierter Programmiersprachen beziehen sich auf objektorientierte Konzepte.
Frank Hileman
1
Das ändert nichts an der Tatsache, dass Sie die Frage nicht beantworten.
Doc Brown
3
Es ist zu beachten, dass nicht nur der Setter optional ist. Sie können nur Setter-Eigenschaften haben.
Telastyn
2

Es geht um Implementierung und Implikation . Die Eigenschaften befanden sich in OOP, bevor C ++ oder Java die Szene betraten (sie befanden sich in Simula mit einer gewissen Rauheit an den Rändern und sind für Smalltalk von grundlegender Bedeutung). Entitäten mit Eigenschaften unterscheiden sich konzeptionell von Werten mit angehängtem Code. Die get & set-Präfixe in einigen Sprachkonventionen dienen nur dazu, das Wasser zu trüben. Sie machen Sie auf den Unterschied zwischen Feldern und Eigenschaften aufmerksam, vorausgesetzt, dass auf Felder direkt zugegriffen werden kann, ohne dass get / set auf eine für die Sprache idiomatische und undichte Weise erfolgt.

Der springende Punkt bei OOP ist, Dinge so zu behandeln, als wären sie Entitäten in der "realen" Welt, nicht nur als Strukturen mit eingemischtem Code. Ein anderer Programmierer sollte sehr, sehr wenig über die Art und Weise wissen müssen, wie ich Dinge implementiert habe, und sollte sich überhaupt nicht darum kümmern, welche der verschiedenen Werte, die sie erhalten und / oder setzen dürfen, real und welche virtuell sind. Wenn Sie auf einen meiner Vektoren stoßen, sollten Sie nicht wissen müssen, ob ich Winkel und Größe oder reale und imaginäre Komponenten innerhalb des Vektorobjekts speichere. Wenn ich die Darstellung in V2.0 meiner Bibliothek ändere, sollte dies keinen Einfluss auf Ihren Code haben (obwohl Sie möglicherweise die coolen neuen Funktionen nutzen möchten). Ebenso gibt es Eigenschaften, die eine Entität haben kann und die von Daten außerhalb der Entität abhängen. aber die sind zweifellos Eigenschaften aus lexikalischer Sicht. Sie fragen die Leute "wie alt sind Sie", nicht "bitte führen Sie die Berechnung durch, die mir Ihr Alter offenbart", obwohl Sie wissen, dass die für dieses "Objekt" verfügbaren Daten das Geburtsdatum (ein privates unveränderliches Mitglied) und das heutige sind Datum (eine öffentliche, automatisch inkrementierende Umwelteigenschaft, abhängig von der Zeitzone, der Sommerzeit und der internationalen Datumsgrenze). Alter ist eine Eigenschaft, keine Methode, obwohl es einige Berechnungen erfordert, um dorthin zu gelangen, und nicht (außer in Spielzeugcomputer-Darstellungen von Dingen mit künstlich begrenzten Lebensdauern) als Feld gespeichert werden kann. obwohl Sie wissen, dass die für dieses "Objekt" verfügbaren Daten das Geburtsdatum (ein privates unveränderliches Mitglied) und das heutige Datum (eine öffentliche, automatisch inkrementierende Umwelteigenschaft, abhängig von der Zeitzone, der Sommerzeit und der internationalen Datumsgrenze) sind ). Alter ist eine Eigenschaft, keine Methode, obwohl es einige Berechnungen erfordert, um dorthin zu gelangen, und nicht (außer in Spielzeugcomputer-Darstellungen von Dingen mit künstlich begrenzten Lebensdauern) als Feld gespeichert werden kann. obwohl Sie wissen, dass die für dieses "Objekt" verfügbaren Daten das Geburtsdatum (ein privates unveränderliches Mitglied) und das heutige Datum (eine öffentliche, automatisch inkrementierende Umwelteigenschaft, abhängig von der Zeitzone, der Sommerzeit und der internationalen Datumsgrenze) sind ). Alter ist eine Eigenschaft, keine Methode, obwohl es einige Berechnungen erfordert, um dorthin zu gelangen, und nicht (außer in Spielzeugcomputer-Darstellungen von Dingen mit künstlich begrenzten Lebensdauern) als Feld gespeichert werden kann.

Anstatt Eigenschaften als das Bastardkind von Feldern und Methoden zu betrachten, ist es weitaus befriedigender, Methoden als eine spezielle Art von Eigenschaft zu betrachten - Dinge, die Ihre Entitäten tun können, anstatt Dinge, die sie sind. Andernfalls handelt es sich nicht konzeptionell um Objekte / Entitäten, sondern um Datensammlungen, an die zufällig Code angehängt ist. Die Implementierungen mögen identisch sein, aber die Implikationen sind unterschiedlich.

Es ist jedoch unnötig zu erwähnen, dass diese Abstraktion mit Kosten verbunden ist. Wenn ein Programmierer, der eine Klasse verwendet, nicht feststellen kann, ob er auf gespeicherte Daten zugreift oder Werte abruft / einstellt, die berechnet werden müssen, gibt es eine Ebene, auf der die Sprache ebenfalls notwendigerweise unsicher ist (und daher möglicherweise unsicher ist) erfordern, dass alles Code erfordert, um zwischen Accessoren / Selektoren und Werten zu wechseln). Es ist konzeptionell nichts Falsches an "Strukturen mit Code" - sie können sicherlich viel effizienter sein -, aber sie lecken überall die Implementierung, und das ist eines der Dinge, die OOP beseitigen soll.

Stan Rogers
quelle
Ich stimme mit einigen Punkten nicht einverstanden sind und mit anderen, aber die gesamte Nachricht ist gut: Einige Informationen über ein Objekt Bedarf berechnet werden , ist aber nach wie vor technisch Informationen , die ist eher als eine Aktion , die werden kann getan .
Pharap
0

Absolut nichts. Eigenschaften und OOP haben nichts miteinander zu tun. Eigenschaften sind nichts anderes als syntaktischer Zucker für Funktionsaufrufe und haben daher genau den gleichen OOP-Anhang wie Funktionsaufrufe, dh keine.

Wikipedia ist übrigens völlig falsch. Das in Java angezeigte Muster getMember / setMember bietet genau die gleichen Vor- und Nachteile wie die Eigenschaften in C #. Und Sie können dieses Muster auch in C replizieren, wenn Sie möchten.

Eigenschaften in C # sind nichts anderes als sprachgestützter syntaktischer Zucker.

DeadMG
quelle
3
Haben Sie das Eigenschaftskonzept jemals in einer Programmiersprache außerhalb eines Klassen- oder Objektkontexts gesehen? I hatte nicht.
Doc Brown
1
@ DocBrown: Ich habe es implementiert. Tatsache ist, dass Eigenschaften für Sprachautoren ziemlich geringwertige Ziele sind, da ihre Verbesserung gegenüber regulären Funktionsaufrufen gering ist.
DeadMG
1
OP hat nach der Geschichte der Eigenschaften als Konzept in gängigen Programmiersprachen gefragt . Und tatsächlich besteht im historischen Sinne ein Zusammenhang zwischen Immobilien und OOP.
Doc Brown
2
Vielleicht war ich ein bisschen voreilig, dieses Konzept von Eigenschaften dem OOP-Paradigma an sich zuzuschreiben, aber als Konzept geht es sicherlich über einzelne Sprachen und ihre Merkmale hinaus. Vielleicht kämpfe ich darum, die richtige Ontologie zwischen den beiden zu artikulieren. Ich behaupte nicht durch den Titel der Frage, dass Eigenschaften ein grundlegendes Merkmal / Konzept von OOP sind , das den OOP-Formalismus macht oder bricht, und dennoch spüre ich, dass sie nur in diesem OOP-Raum eine Realität haben, weshalb ich die Frage als solche formuliert habe .
Jxramos
4
Sie sind nicht nur Syntaxzucker in C #, sie existieren in den Assembly-Metadaten als unterschiedliche Elemente, und Sie können Dinge mit Eigenschaften tun, die Sie mit Feldern nicht können, wie z. B. Datenbindung.
Andy