Wie helfen Ihnen Klassen bei der Verwaltung großer Anwendungen?

Question

Das kam in ein Gespräch Ich war online ist, und es fiel mir ein, dass ich keine Ahnung, wie das funktionieren soll: Viele Programmierer scheinen ganz einfach in der Tat als given- zu nehmen, offensichtlich, dass Klassen a sind notwendige Sprachfunktion für die Verwaltung riesiger Softwareprojekte.

Es ist mir nicht klar, wie sie dies tun.

Sie Meine Frage ist, wie Sie wissen? Welche objektiven Maßnahmen zeigen, dass Klassen die Produktivität, die Wiederverwendung von Code und die Komplexität der Produktion eines Programms erhöhen? Welche Aspekte der Klassen machen sie ideal für große Teams zur Zusammenarbeit?

Und jetzt, es gibt eine Frage, die ich gerne stellen möchte, das ist etwas schwierig auszudrücken. Es tut mir leid, wenn ich das falsch verstehe und jemanden verwirre oder verärgere:

Objektiv wissen Sie, dass die Verwendung von Klassen nicht die Ursache dafür ist, dass die Anwendung zu Beginn groß ist? Das heißt, ist es möglich, dass ein Programm mit äquivalenter Funktion geschrieben werden könnte, mit viel weniger Code, klein genug, um keine speziellen Maßnahmen zu ergreifen, um es "zu managen", mit einer anderen Code-Wiederverwendungsstrategie? (Es gibt viele, aus denen man wählen kann, etwa solche in funktionalen Programmierparadigmen oder aspektorientierte Programmierung).

Das letzte Stück ist etwas, das Steve Yegge in seinem Blog angedeutet hat. Aber ich bin etwas skeptisch gegenüber beiden Seiten des Arguments, aufgrund eines wirklichen Mangels an harten Daten von irgendjemandem und nicht genug Erfahrung, um selbst zu einem Schluss zu kommen.

Was denkst du?

edit: Insbesondere interessiert mich, warum viele Programmierer denken, dass Prototyp-Stil Vererbung nicht die Aufgabe ist, wenn es um große Anwendungen geht. Es tut mir leid, diese Frage ist vage - es ist ein Produkt meines Unverständnisses zu diesem Thema.

edit2: Es scheint etwas Verwirrung darüber zu bestehen, was ich mit funktionaler Programmierung meine. (Ich glaube nicht, dass irgendeine Version von VB jemals funktional war, sicherlich nicht ältere Versionen). Bitte beachten Sie den Wikipedia-Artikel. http://en.wikipedia.org/wiki/Functional_programming

edit3: und lassen Sie mich betonen, dass ich nach objektiven Maßnahmen suche. Keine subjektiven Meinungen.

Answer 1

Die Kapselungstheorie liefert einen objektiven Grund, warum Klassen besser sind als überhaupt keine Klassen zu haben. Die internationale Organisation für Normung definiert Kapselung als "Die Eigenschaft, auf die die in einem Objekt enthaltenen Informationen nur über Interaktionen an den vom Objekt unterstützten Schnittstellen zugreifbar sind".

Da einige Informationen über diese Schnittstellen zugänglich sind, müssen daher einige Informationen verborgen und nicht im Objekt verfügbar sein. Die Eigenschaft, die solche Informationen aufweisen, wird als "Information Hiding" bezeichnet, was Parnas mit dem Argument definierte, dass Module so konzipiert sein sollten, dass sie sowohl schwierige Entscheidungen als auch Entscheidungen, die sich wahrscheinlich ändern, verbergen.

Beachten Sie das Wort: ändern. Das Verstecken von Informationen betrifft potenzielle Ereignisse wie die Änderung schwieriger Designentscheidungen in der Zukunft.

Betrachten Sie eine Klasse mit zwei Methoden: Methode a(), die Informationen innerhalb der Klasse verborgen ist, und Methode b(), die öffentlich und damit direkt von anderen Klassen zugänglich ist.

Es gibt eine gewisse Wahrscheinlichkeit, dass eine zukünftige Änderung der Methode a() Änderungen an Methoden in anderen Klassen erfordert. Es besteht auch eine gewisse Wahrscheinlichkeit, dass eine zukünftige Änderung der Methode b() Methodenänderungen in anderen Klassen erfordert. Die Wahrscheinlichkeit, dass solche Welligkeitsänderungen für die Methode a() auftreten, wird jedoch gewöhnlich geringer sein als die für die Methode b(), einfach weil die Methode b() von mehr Klassen abhängig sein kann.

Diese verringerte Wahrscheinlichkeit von Welligkeitseinwirkungen ist ein Hauptvorteil der Verkapselung.

Betrachten Sie die maximale mögliche Anzahl der Quellcodeabhängigkeiten (MPE - das Akronym ist von der Graphentheorie) in jedem Programm. Extrapolieren wir von den obigen Definitionen, können wir sagen, dass angesichts zweier Programme, die den Benutzern die gleiche Funktionalität liefern, das Programm mit dem niedrigsten MPE besser gekapselt ist und dass statistisch das besser eingekapselte Programm wegen der Kosten billiger zu warten und zu entwickeln ist der maximalen potenziellen Änderung wird niedriger sein als die maximale potenzielle Änderung zu dem weniger gut gekapselten System.

Betrachten Sie darüber hinaus eine Sprache mit nur Methoden und keine Klassen und damit keine Mittel zum Verstecken von Methoden voneinander. Sagen wir, unser Programm hat 1000 Methoden. Was ist der MPE dieses Programms?

Die Kapselungstheorie sagt uns, dass bei einem System von n öffentlichen Knoten der MPE dieses Systems n (n-1) ist. Somit ist der MPE unserer 1000 öffentlichen Methoden 999.000.

Jetzt brechen wir dieses System in zwei Klassen mit jeweils 500 Methoden. Da wir jetzt Klassen haben, können wir wählen, ob einige Methoden öffentlich und einige Methoden privat sind. Dies ist der Fall, wenn nicht jede Methode tatsächlich von jeder anderen Methode abhängig ist (was unwahrscheinlich ist). Nehmen wir an, dass 50 Methoden in jeder Klasse öffentlich sind. Was wäre der MPE des Systems?

Kapselungstheorie sagt uns, es ist: n ((n/r) -1 + (r-1) p) Dabei ist r die Anzahl der Klassen und p ist die Anzahl der öffentlichen Methoden pro Klasse. Dies würde unserem Zwei-Klassen-System einen MPE von 499.000 geben. Somit sind die maximalen potentiellen Kosten einer Änderung dieses Zwei-Klassen-Systems bereits wesentlich niedriger als die des ungekapselten Systems.

Sagen wir, du brichst dein System in 3 Klassen auf, die jeweils 333 Klassen haben (naja, eine hat 334 Klassen) und wieder jede mit 50 öffentlichen Methoden. Was ist der MPE? Unter Verwendung der obigen Gleichung würde der MPE ungefähr 482.000 betragen.

Wenn das System in 4 Klassen mit jeweils 250 Methoden aufgeteilt wird, beträgt der MPE-Wert 449.000.

Wenn es so aussieht, als würde die Erhöhung der Anzahl der Klassen in unserem System immer die MPE verringern, aber das ist nicht so. Die Verkapselungstheorie zeigt, dass die Anzahl der Klassen, in die das System zerlegt werden sollte, um MPE zu minimieren, ist: r = sqrt (n/p), was für unser System eigentlich 4 ist. Ein System mit 6 Klassen hätte zum Beispiel einen MPE von 465.666.

Answer 2

Ich bin keineswegs ein Frömmler gegenüber irgendeinem Programmierparadigma, aber ich arbeite seit einiger Zeit in einer OO-Mode.

Ich persönlich habe eine Menge hatte 'a-ha!' Momente, in denen mir der Unterricht direkt geholfen hat, die Domäne, in der ich arbeite, besser zu verstehen.

insbesondere meist, in den Fällen, in denen es Verwirrung darüber, warum ein System funktioniert nicht richtig, oder was für ein System tun sollte, haben Klassen oft gezwungen, mich darüber nachzudenken, was das diskrete Stück des Ganzen tun soll, und mehr oft dazu führen, dass die Klassen/Methoden umstrukturiert werden.

Kurz gesagt, Kapselung macht mich wirklich ein glücklicher Mensch. ;)

Hoffnung, das hilft.

Answer 3

Ich bevorzuge Klassen, damit ich ein großes Problem in überschaubare Teile aufteilen kann, die als einzelne Einheiten testbar sind. IMHO, Code Wiederverwendung ist überbewertet - ich habe es kaum gesehen, wo ich arbeite. Was ich aus gutem OO am meisten herausgehe, ist eine gute Testbarkeit.Das andere Extrem besteht darin, eine Menge globaler Variablen zu verwenden und alle Ihre Logik in public static void main (oder Page_Load in ASP.NET) zu blockieren und statische Methoden aufzurufen, die andere statische Methoden aufrufen usw. (Ich wurde schwindlig bei das Ende des letzten Satzes.)

Die einzige Sache, die meine OO Denkweise brechen würde, wenn ich mit einer reinen funktionalen Sprache arbeite, über die ich seit dem College leider nicht nachgedacht habe.

Answer 4

Das ist eine sehr gute Frage. Das Organisieren von Code in Klassen ist eine Möglichkeit für ein Entwicklungsteam, kleine wiederverwendbare Module zu erstellen. Auch diese Module haben ausdrucksstarke und begrenzte Schnittstellen, die nur das zum Ausdruck bringen, was die Klasse kann und nicht wie sie es tut. Jede Klasse ist orthogonal zu den anderen und ist daher im Falle eines Fehlers sehr überprüfbar und modular.

Nun, was ich gerade beschrieben habe, ist eine seltsame Szene aus einer perfekten Welt. Aber jeder gute Entwickler, der OOP-Arbeit macht, sollte nach so etwas streben.

OOP ist eine Bestätigung, dass wir, die Entwickler, einfach menschlich sind und nicht ein ganzes System auf einmal verstehen können. Wir zerlegen das System in winzige wiederverwendbare Teile und konzentrieren uns auf diese.

Nehmen Sie eine zehnstellige US-Telefonnummer als Beispiel. Es ist schwierig, sich eine zehnstellige Nummer in deinem Kopf zu merken, also tun wir, was Psychologen "Chunking" nennen. Das bedeutet, dass wir die Zahlen im Geist in Stücke zerlegen, an die wir uns besser erinnern können.

So 1234567890 wird 123-456-7890. Zum Glück für uns brechen die Telefongesellschaften diese Nummern auch auf die gleiche Weise ab und weisen den Brocken Bedeutung zu. 123 ist die Vorwahl, 456 ist das Präfix und 7890 ist die Zeilennummer. Jeder dieser Brocken ist wie eine Klasse, sie alle haben individuelle Verantwortlichkeiten, Formate und Bedeutungen.

Also das Beste, was ich sagen kann, ist, dass OOP uns erlaubt, große, skalierbare Systeme zu bauen, die zentralisierte und gekapselte Funktionalität haben. Es erlaubt uns, nicht ständig das große Bild zu sehen und sich darauf konzentrieren zu können, etwas zu tun und es gut zu machen.

Answer 5

Zwei Dinge.

Die erste ist die Idee, dass eine Klasse undurchsichtig Domäne Entität ist. Bei korrekter Ausführung führen objektorientierte Programme eine Ebene der Abstraktion ein: Auf der nächsthöheren Ebene marshalieren Sie Objekte, um das zu tun, was Sie wollen, anstatt sich um Details zu kümmern. Sie müssen nicht wissen, wie die Objekte und Klassen funktionieren: nur was sie tun. Dies ist eine Art von Informationsverbergung und reduziert die Komplexität, die ein Team bei der Arbeit im Kopf behalten muss. Die zweite besteht darin, dass die OO-Programmierung eine Art der Wiederverwendung von Code ermöglicht: Sie können Klassen definieren, die bestimmte Verhaltensweisen in anderen Klassen überschreiben (Vererbung), oder Klassen, deren Instanzen Instanzen anderer Klassen enthalten, um diese zu erreichen (Verkapselung und Zusammensetzung).

Korrekt Mithilfe von OO-Techniken können Sie die Menge an Code reduzieren, die Sie verwalten müssen, und die Anzahl der Dinge reduzieren, die Sie beim Arbeiten oder Warten des Systems beachten müssen. In der Praxis funktioniert dieser Ansatz nicht immer.

Answer 6

Ich denke Klassen können helfen, weil sie dem sehr allgemeinen kognitiven Konzept von categorization entsprechen und so helfen können, große Anwendungen natürlich zu beschreiben.

Answer 7

Sachlich, wie Sie wissen, dass die Verwendung von Klassen nicht die Ursache für die zu beginnen ist groß Anwendung ist?

Nehmen Sie eine große Programm/Anwendung, die nicht in einer OO-Sprache geschrieben wurde (beispielsweise C, COBOL, sogar Ebene SQL), und Sie sollten diese Codegröße Zeuge in der Lage ist, auf die Sprache Paradigma nicht direkt zugeschrieben. Für jede Anzahl von gut entworfenen, hochentwickelten, wiederverwendbaren C# - oder Java-Komponenten gibt es auch eine gleiche Anzahl von gut entworfenen, hochentwickelten, wiederverwendbaren C-DLLs. Umgekehrt gibt es die gleiche Anzahl von schrecklichen, aufgeblähten Code.

Der Punkt ist, gute Programmierer sind in der Lage, ihre Systemdesigns unabhängig von Sprache/Plattform zu verfeinern.

In Bezug auf OOP, zumindest für mich, bringt es auf die Tabelle ein "Potenzial" - ein Blick auf die Programmierwelt abit näher zu unserer realen Welt. Wir alle kennen unsere Welt und dieses Universum der Materie sind voller Objekte, die aus kleineren Objekten bestehen. Von galaktischen Sternsystemen bis hin zu Molekülen, Atomen und subatomaren Teilchen reicht es, zu zoomen. Es ist wirklich erstaunlich, wie sehr unterschiedliche Materie aus denselben winzigen Teilchen besteht, die in verschiedenen Mustern kombiniert sind. Schauen Sie sich auch unsere eigene Biologie an, es ist manchmal verblüffend zu denken, dass 60% unserer Körper tatsächlich nur Wasser sind, wenn es bis zum Feinsten gebrochen ist. Doch schauen Sie sich all die verschiedenen Systeme und Organe an, die mit Chemie verbrennen, um uns am Laufen zu halten und am Leben zu erhalten.

Wenn wir lernen, die Einfachheit (oh wirklich ... ha ha) der Bausteine ​​zu verstehen, die die Systeme der realen Welt bilden, die wir in der alltäglichen Natur sehen, sollten wir dann in der Lage sein, das Entwerfen und Bauen zu verstehen extrem komplizierte oder hochentwickelte Systeme sollten mit kleinen Komponenten beginnen, die selbst sehr wenig tun. Und indem wir sie langsam zu immer größeren Komponenten kombinieren und miteinander verbinden, können wir mehr Funktionalität und Fähigkeiten erhalten. Bis wir das gewünschte System erreicht haben.

Die (richtige) Verwendung von Klassen ist es, ein System in seine besten zu zerlegen. Wie möglich. Damit Sie etwas zu einer bestimmten Zeit und auf einer bestimmten Ebene der Abstraktion betrachten können und nicht von Zielen und Logik überwältigt werden, die sich nicht mit Ihrem gegenwärtigen Bereich befassen. Wann immer Sie ein System entwerfen, denken Sie an Ihre eigene Anatomie; Denken Sie wie Sie den menschlichen Körper entwerfen würden. Wann immer Sie ein System entwerfen, denken Sie an , das eine neue Firma beginnt; Was sind die wichtigsten Abteilungen, die Abteilungen, die Sie benötigen, um das Geschäft zu betreiben. Wer sind die Mitarbeiter, die für diese Abteilungen benötigt werden? Die verschiedenen Geräte, die sie benutzen und mit denen sie interagieren müssen, um ihre Arbeit auszuführen. Wie brichst du den Geschäftsbetrieb in sein Bestes, um es besser verstehen zu lassen?

Wenn Sie das Grundprinzip verstehen, dass ein Objekt einfach aus kleineren Objekten besteht, sind Sie auf dem Weg zur Herstellung hoch wiederverwendbarer Zellen oder Moleküle.

Answer 8

Klassen haben mir in dem Aspekt, dass ich gleichzeitig an einem kleinen Aspekt eines komplexen Projekts arbeiten kann, sehr geholfen. Die Möglichkeit, einen Aspekt des Codes vom großen Projekt zu entkoppeln, ist sehr hilfreich, damit Sie nicht überfordert werden. Am Ende kann der Zusammenhalt zwischen diesen Klassen Ihnen einen schnellen Überblick darüber geben, wie ein Programm funktioniert, ohne sich mit den Innereien herumschlagen zu müssen.

Soweit es die Wartbarkeit betrifft, ist es viel einfacher, ein UML-Klassendiagramm zu betrachten und herauszufinden, wie alles aufgebaut ist, als eine Liste von Funktionen zu betrachten, meiner Meinung nach.

Answer 9

Ich denke, indem Sie Klassen sagen, sollten Sie Objekte meinen. Klassen sind nichts anderes als ein Ort, an dem Sie Ihre Objekte einfügen können. Das OOP-Paradigma ist aus einem bestimmten Grund so erfolgreich. Sobald du das "Aha!" Moment, wenn Sie denken, dass Sie das Konzept der OOP endlich verstanden haben, können Sie viel organisierter mit der Programmierung beginnen.

Ich habe in Visual Basic 3 für eine lange Zeit programmiert, also hatte ich viel Erfahrung mit der funktionalen Programmierung, dann zu VB5 zu kommen und Objekte zu entdecken war eine immense Erleichterung, weil ich reale Elemente in meinen Code beziehen konnte und es hat sehr geholfen.

Das ist der springende Punkt, echte Entitäten in Ihrem Code neu zu erstellen. Es macht das Lesen und Arbeiten einfacher, weil man etwas aufheben und damit arbeiten kann.

Answer 10

Es ist wahrscheinlich möglich, ein einfaches Problem zu überarbeiten, indem es unnötig komplex gemacht wird (OO ganz unten). Aber für jedes ausreichend große Problem glaube ich nicht, dass das OO-Paradigma wahrscheinlich dafür verantwortlich ist, dass es überhaupt groß ist. Nehmen Sie zum Beispiel ein Betriebssystem, es ist schwer vorstellbar, dass es leicht zu pflegen ist (Code-weise), wenn es nicht objektorientiert geschrieben ist.

Answer 11

Wenn Sie eine Reihe von "bare" Funktionen in einer großen Anwendung haben, ist es schwierig, Änderungen an diesen Funktionen vorzunehmen.

• schwerer zu sehen, wer die Funktion verwendet („wenn ich das ändern, die wirkt sich das?“)
• schwierig, ohne zu brechen Code anderen Leute zu den Funktionen, Änderungen vorzunehmen.

Wenn Sie die Funktionen in Klassen einschließen, helfen Sie, den Geltungsbereich des Codes zu isolieren. Es ist keine magische Kugel, aber es hilft.