it-swarm.com.de

Warum werden Datenklassen als Codegeruch betrachtet?

This Artikel behauptet, dass eine Datenklasse ein "Code-Geruch" ist. Der Grund:

Es ist normal, wenn eine neu erstellte Klasse nur wenige öffentliche Felder enthält (und vielleicht sogar eine Handvoll Getter/Setter). Die wahre Stärke von Objekten besteht jedoch darin, dass sie Verhaltenstypen oder Operationen für ihre Daten enthalten können.

Warum ist es falsch, wenn ein Objekt nur Daten enthält? Wenn die Hauptverantwortung der Klasse darin besteht, Daten darzustellen, würden dann keine Methoden, die mit den Daten arbeiten, das Prinzip der Einzelverantwortung verletzen?

18
Sipo

Es ist absolut nichts Falsches daran, reine Datenobjekte zu haben. Der Autor des Stückes weiß ehrlich gesagt nicht, wovon er spricht.

Ein solches Denken beruht auf einer alten, gescheiterten Idee, dass "echtes OO" der beste Weg zum Programmieren ist und dass es bei "wahrem OO" um "Rich Data Models" geht, bei denen Daten und Funktionen gemischt werden.

Die Realität hat uns gezeigt, dass das Gegenteil der Fall ist, insbesondere in dieser Welt der Multithread-Lösungen. Reine Funktionen, kombiniert mit unveränderlichen Datenobjekten, sind nachweislich eine bessere Möglichkeit zum Codieren.

34
David Arno

Es ist absolut nichts Falsches daran, reine Datenobjekte zu haben. Der Autor hat eine Meinung, die von den mir bekannten Softwareentwicklern nicht geteilt wird.

Insbesondere für die Datenbankzuordnung haben Sie im Allgemeinen Entitätsklassen, die nur die in der Datenbank gespeicherten Felder sowie Getter und Setter enthalten. Wikipedia Hibernate (Framework)

Die ganze Idee von Java Beans, die von vielen Tools/Frameworks verwendet werden, basiert auf Datenklassen, die Beans genannt werden und nur Felder und die zugehörigen Getter und Setter enthalten. Wikipdia JavaBeans

Fazit:
Wenn jemand behauptet, etwas sei "schlecht" oder "ein Code-Geruch", sollten Sie immer nach den angegebenen Gründen suchen. Wenn die Gründe nicht überzeugen, fragen Sie jemanden nach besseren Gründen oder einer anderen Meinung. (Wie du es in diesem Forum getan hast)

7
MrSmith42

Ein gutes Argument warum von Martin Fowler:

"Tell-Don't-Ask ist ein Prinzip, das Menschen daran erinnert, dass es bei der Objektorientierung darum geht, Daten mit den Funktionen zu bündeln, die mit diesen Daten arbeiten. Es erinnert uns daran, dass wir ein Objekt nicht nach Daten fragen und auf diese Daten reagieren sollte stattdessen einem Objekt mitteilen, was zu tun ist. Dies ermutigt dazu, das Verhalten in ein Objekt zu verschieben, das zu den Daten passt. "

https://martinfowler.com/bliki/TellDontAsk.html

4
Curtis Yallop

Was Sie verstehen müssen, ist, dass es zwei Arten von Objekten gibt:

  • Objekte mit Verhalten. Diese sollten es unterlassen, den meisten/einem ihrer Datenmitglieder öffentlichen Zugang zu gewähren. Ich erwarte nur sehr wenige Accessor-Methoden, die für diese definiert sind.

    Ein Beispiel wäre ein kompilierter regulärer Ausdruck: Das Objekt wird erstellt, um ein bestimmtes Verhalten bereitzustellen (um eine Zeichenfolge mit einem bestimmten regulären Ausdruck abzugleichen und die (Teil-) Übereinstimmungen zu melden), aber wie der kompilierte reguläre Ausdruck seine Arbeit geht den Benutzer nichts an.

    Die meisten Klassen, die ich schreibe, gehören zu dieser Kategorie.

  • Objekte, die wirklich nur Daten sind. Diese sollten lediglich alle ihre Mitglieder für öffentlich erklären (oder ihnen den vollständigen Satz von Accessoren zur Verfügung stellen).

    Ein Beispiel wäre eine Klasse Point2D. Es gibt absolut keine Invariante, die für die Mitglieder dieser Klasse sichergestellt werden muss, und Benutzer sollten nur über myPoint.x Und myPoint.y Auf die Daten zugreifen können.

    Persönlich verwende ich solche Klassen nicht viel, aber ich denke, es gibt keinen größeren Code, den ich geschrieben habe und der eine solche Klasse nicht irgendwo verwendet.

Um die Objektorientierung zu beherrschen, muss man erkennen, dass diese Unterscheidung besteht, und lernen, die Funktion einer Klasse in eine dieser beiden Kategorien einzuteilen.


Wenn Sie in C++ codieren, können Sie diese Unterscheidung explizit machen, indem Sie class für die erste Objektkategorie und struct für die zweite verwenden. Natürlich sind die beiden gleichwertig, außer dass class bedeutet, dass alle Mitglieder standardmäßig privat sind, während struct alle Mitglieder standardmäßig als öffentlich deklariert. Welches ist genau die Art von Informationen, die Sie kommunizieren möchten.