Bricht die n-Tier-Architektur das OO-Konzept der Kapselung

Question

Ich habe eine n-Tier-Anwendung mit Präsentationsschicht, Geschäftsschicht, DAL und Geschäftsobjektschicht. Die Trennung der Objekte und der auf die Objekte geschriebenen Operationen bricht das objektorientierte Konzept der Kapselung.

Answer 1

Nein. Bedenken Sie, was "Kapselung" bedeutet: Die Implementierungsdetails einer Klasse sind hinter der Schnittstelle (Nachrichten oder Methoden) der Klasse verborgen.

Tatsächlich lässt sich die n-Tier-Architektur direkt aus den OO-Prinzipien und dem Parnas'schen Gesetz ableiten: Ein Modul sollte das kapseln, was sich wahrscheinlich ändern wird. Die Präsentationsschicht kapselt die Details der Erstellung einer "sichtbaren" Schnittstelle, die mittlere Schicht das Modell des Unternehmens selbst und das Backend die Details des Zugriffs auf den persistenten Datenspeicher.

Answer 2

Nehmen Sie dieses Beispiel, das aus dieser Artikel :

public class Position
{
  public double distance( Position position )
  {
    // calculate and return distance...
  }

  public double heading( Position position )
  {
    // calculate and return heading...
  }

  public double latitude;
  public double longitude;
}

Demselben Artikel zufolge ist dies ein gutes Beispiel für eine Kapselung, da Daten und Operationen, die mit diesen Daten durchgeführt werden, gebündelt werden. Beachten Sie, dass die Verkapselung hier keine Garantie für das Verstecken oder den Schutz von Daten bietet.

Im Gegensatz dazu würde Steve McConnell in Code Complete (2. Aufl., Abschnitt 6.2, Good Encapsulation) argumentieren, dass die Kapselung gebrochen ist, weil die Mitgliedsdaten offen liegen.

In Ihrem Fall, wenn Ihre Datenobjekte und die Objekte, die sie bearbeiten, getrennt sind, aber keine öffentlichen Felder haben, dann ist die Kapselung gemäß der ersten Definition gebrochen, aber nicht unbedingt im zweiten Fall. Wir haben also zwei gegensätzliche Ansichten. Die eine besagt, dass Data Hiding kein Bestandteil der Kapselung ist, die andere, dass Data Hiding ein wesentlicher Bestandteil der Kapselung ist.

Data Hiding kann als Teil des Information Hiding gesehen werden, das besagt, dass man komplexe Designentscheidungen und Quellen von Veränderungen verbergen sollte. Der allgemeine Konsens scheint zu sein, dass die Kapselung als eine Manifestation des Information Hiding, einschließlich des Data Hiding, angesehen wird.

Oder, wie Wikipedia drückt es aus:

Der Begriff Verkapselung wird oft verwendet austauschbar mit Information Hiding verstecken. Nicht alle sind sich über die Unterscheidungen zwischen den beiden Begriffen; Man kann das Verstecken von Informationen als das Prinzip und Verkapselung die Technik ist. Ein Softwaremodul verbirgt Informationen, indem es sie in einem Informationen in ein Modul oder ein anderes Konstrukt, das eine Schnittstelle darstellt.

Aber... der Verweis, der auf diesen Absatz folgt, ist derselbe Artikel, dem ich das erste Beispiel entnommen habe, so dass sogar Wikipedia hier etwas durcheinander bringt. Auch die Verwendung des Wortes "Unterscheidungen" scheint hier falsch zu sein.

Es ist ein bisschen lahm, das am Ende sagen zu müssen, aber die Terminologie für Kapselung und Informationsverschleierung ist überladen, so dass es auf die Quelle ankommt. In Ihrem Fall würde ich mich an die Definition von Kapselung als "Verbergen von Implementierungsdetails hinter einer Abstraktion" halten. Sie brechen also nicht unbedingt die Kapselung.

Answer 3

Das ist ein wirklich guter Punkt, AP!

In einigen Fällen würde ich zustimmen, dass die Aufteilung eines einzelnen Vorgangs in mehrere Objekte in der Tat negative Auswirkungen auf die Verkapselung hat. Ich denke, das ist ein großes Problem, das ich in vielen Web-Architekturen gesehen habe.

Andererseits sind bestimmte Dinge nützlich, um sie zu zerlegen, z. B. als Objekt, um Abfragen an die Datenbank zu senden, usw.

Meiner Meinung nach spricht in vielen Fällen einiges dafür, eine Webseite besser zu "kapseln", so dass ein größerer Teil der Funktionalität in einem einzigen Objekt oder weniger Objekten enthalten ist. Also ein eher "seitenorientierter" Ansatz, anstatt die Logik über eine große Anzahl von Klassen zu verstreuen.

Ich denke, das ist eine wichtige Frage, die wir uns bei jedem System, das wir entwerfen, stellen müssen: Wie viel abstrahieren wir? Wie viel soll spezifisch bleiben? Wie soll effektiv das System in Klassen zu zerlegen.

Answer 4

Beides ist nicht dasselbe. Eine Architektur bezieht sich eher auf Module (Gruppen von Klassen). Verkapselung bezieht sich auf das Verbergen des Innenlebens einer Klasse. Sie können beides haben, wenn Sie Ihr System gut genug entwerfen.

Worauf Sie möglicherweise achten müssen, ist die klare Abgrenzung der Zuständigkeiten. Solange Sie sich darüber im Klaren sind, wozu jedes Modul/jede Schicht dient, und genau wissen, was jede Klasse tut (und was jede Methode der Klasse tut), sollten Sie in der Lage sein, einen guten Entwurf zu erstellen.

Ich spekuliere hier nur, aber vielleicht interessieren Sie sich für die Fassadendesign-Muster beim Entwurf einer Schnittstelle zu einem Modul.

Was Ihren Kommentar weiter unten betrifft, so sollte die Logik definitiv in der Mitarbeiterklasse selbst liegen. Ich würde die Logik einer separaten Schicht für Geschäftsobjekte in Frage stellen. Es ist oft eine Versuchung, Klassen wie "Employee" zu definieren, weil sie reale Objekte oder Konzepte modellieren. Ihre Motivation für die Definition einer Klasse sollte jedoch nicht die "Modellierung eines realen Objekts" sein.

Sie sollten den Zweck Ihres Moduls definieren (warum haben Sie eine Geschäftslogikschicht? Um die gesamte Geschäftslogik zu enthalten.) und dann das, was Sie brauchen, dort hineinlegen. Wenn die Klasse "Employee" die Klasse ist, die die Geschäftslogik berechnen muss, dann sollte sie in die Geschäftslogikklasse aufgenommen werden. Wenn nicht, dann sollte sie in die Klasse "Business Objects" (was auch immer das sein mag) aufgenommen werden. Wenn sie zwei verschiedene Aufgaben erfüllen muss und daher in zwei Schichten passen könnte, sollten Sie sie in zwei Klassen aufteilen - denken Sie daran, dass Ihre Objekte keine realen Dinge modellieren müssen. Robert C. Martin schlägt vor, die Klassen so zu definieren, dass die Grenzen der Klassen auch die Grenzen des Zwecks sind.