Heim  >  Artikel  >  Was ist der Zweck der Codierung beim Codedesign von Managementinformationssystemen?

Was ist der Zweck der Codierung beim Codedesign von Managementinformationssystemen?

青灯夜游
青灯夜游Original
2020-08-28 14:16:568074Durchsuche

Der Zweck der Codierung ist: Einzigartigkeit, Standardisierung und Systematisierung. Codes verwenden Zahlen oder Zeichen, um verschiedene objektive Einheiten darzustellen. Der Zweck des Codeentwurfs während des Systementwicklungsprozesses ist: Einzigartigkeit, Standardisierung und Systematisierung.

Was ist der Zweck der Codierung beim Codedesign von Managementinformationssystemen?

Code verwendet Zahlen oder Zeichen, um verschiedene objektive Einheiten darzustellen:

1. Standardisierung;

Sechs Prinzipien des Codedesigns

Prinzip der Einzelverantwortung

Definition: Eine Klasse oder eine Schnittstelle ist am besten für nur eine Verantwortung verantwortlich. Ursprung des Problems: Klasse T ist für zwei unterschiedliche Verantwortlichkeiten P1 und P2 zuständig. Da die Verantwortung P1 geändert werden muss und die T-Klasse geändert werden muss, kann es zu einer Fehlfunktion der Funktion der Verantwortung P2 kommen, die ursprünglich normal ausgeführt wurde.

Lösung: Befolgen Sie das Prinzip der Einzelverantwortung. Erstellen Sie neue Klassen, die den entsprechenden Verantwortlichkeiten entsprechen. Auf diese Weise können Sie verhindern, dass sich Änderungen an der Klasse auf andere Verantwortlichkeiten auswirken. Wenn die Logik einfach genug ist, können Sie die einzelne Einheit auf Codeebene verletzen Verantwortungsprinzip: Nur wenn die Anzahl der Methoden in einer Klasse klein genug ist, kann das Prinzip der Einzelverantwortung auf Methodenebene verletzt werden.

Vorteile: Die Komplexität der Klasse wird verringert, die Lesbarkeit wird erheblich verbessert Auch die Wartbarkeit wird verbessert.

Liskov-Substitutionsprinzip

Wenn eine Basisklasse verwendet wird, können ihre Unterklassen beliebig verwendet werden, um sicherzustellen, dass die Unterklasse die Basisklasse perfekt ersetzen kann. Dieser Geist ist tatsächlich die Verkörperung der Einschränkungen und Spezifikationen des Vererbungsmechanismus. Bei der spezifischen Implementierung von übergeordneten Klassen und Unterklassen werden die Beziehungsmerkmale in der Vererbungshierarchie streng kontrolliert, um sicherzustellen, dass das Programmverhalten beim Ersetzen der Basisklasse durch eine Unterklasse keine Probleme verursacht und normal fortgesetzt werden kann.

Für die Vererbung definiert die übergeordnete Klasse eine Reihe von Spezifikationen und Verträgen. Obwohl nicht alle Unterklassen diese einhalten müssen, führt eine willkürliche Änderung dieser nicht abstrakten Methoden zu Schäden am gesamten Vererbungssystem.

Wenn Sie die Methode der übergeordneten Klasse neu schreiben müssen, ist die gebräuchlichere Methode: Die ursprüngliche übergeordnete Klasse und die Unterklasse erben beide eine beliebtere Basisklasse, entfernen die ursprüngliche Vererbungsbeziehung und verwenden Abhängigkeit, Aggregation, Kombination usw Beziehungen. Das

-Prinzip umfasst die folgenden vier Bedeutungsebenen:

* Unterklassen können abstrakte Methoden der übergeordneten Klasse implementieren, aber keine nicht-abstrakten Methoden der übergeordneten Klasse überschreiben.

* Unterklassen können ihre eigenen hinzufügen eindeutige Methoden;

* Wenn eine Methode einer Unterklasse eine Methode einer übergeordneten Klasse überschreibt, sind die formalen Parameter der Methode lockerer als die Eingabeparameter der Methode der übergeordneten Klasse.

* Wenn eine Methode einer Unterklasse eine Zusammenfassung implementiert Methode der übergeordneten Klasse, der Rückgabewert der Methode Strenger als die übergeordnete Klasse;

Prinzip der Abhängigkeitsinversion

Definition: Module auf hoher Ebene sollten nicht von Modulen auf niedriger Ebene abhängen, beide sollten sich auf ihre Abstraktionen verlassen; Abstraktionen sollten sich nicht auf Details stützen; Details sollten auf Abstraktionen beruhen. Die Idee besteht darin, sich auf Abstraktionen zu verlassen.

Der Ursprung des Problems: Klasse A hängt direkt von Klasse B ab Bei Klasse C müssen Sie den Code von Klasse A ändern. In diesem Szenario handelt es sich bei Klasse A normalerweise um ein High-Level-Modul. Die Klassen B und C sind Low-Level-Module, die für die Grundprinzipien der Klasse verantwortlich sind Wenn A geändert wird, birgt dies unnötige Risiken für das Programm.

Lösung: Ändern Sie Klasse A so, dass sie von Schnittstelle I abhängt. Klasse B und Klasse C implementieren jeweils Schnittstelle I. Klasse A kontaktiert Klasse B und Klasse C indirekt über Schnittstelle I, wodurch die Wahrscheinlichkeit einer Änderung von Klasse A verringert wird.

In der Praxis Im Allgemeinen müssen wir die folgenden drei Dinge tun:

* Low-Level-Module müssen abstrakte Klassen oder Schnittstellen oder beides haben

* Die deklarierten Variablentypen sollten möglichst abstrakte Klassen oder Schnittstellen sein; Befolgen Sie das Liskov-Substitutionsprinzip, wenn Sie Vererbung verwenden.

Interface-Segregation-Prinzip

Definition: Der Client sollte sich nicht auf Schnittstellen verlassen, die er nicht benötigt; die Abhängigkeit einer Klasse von einer anderen Klasse sollte auf der kleinsten Schnittstelle basieren, andernfalls führt zu einer Schnittstellenverschmutzung; Klasse A hängt von Klasse B über Schnittstelle I ab, und Klasse C hängt von Klasse D über Schnittstelle I ab. Wenn Schnittstelle I nicht die Mindestschnittstelle für Klasse A und Klasse B ist, müssen Klasse B und Klasse D sie implementieren. Methoden, die sie nicht benötigen; Die Bedeutung des

-Prinzips ist: Erstellen Sie eine einzige Schnittstelle, erstellen Sie keine riesige und aufgeblähte Schnittstelle, versuchen Sie, die Schnittstelle so weit wie möglich zu verfeinern, und haben Sie so wenige Methoden wie möglich in der Schnittstelle Das heißt, wir müssen für jede Klasse eine eigene Schnittstelle einrichten. Versuchen Sie nicht, eine riesige Schnittstelle für alle Klassen zu erstellen, die darauf angewiesen sind.

Beachten Sie, dass die Schnittstelle so klein wie möglich sein sollte. Es muss jedoch eine Grenze geben, die die Programmierflexibilität verbessern kann. Wenn sie jedoch zu klein ist, wird die Anzahl der Schnittstellen so gering wie möglich gehalten, was das Design verkompliziert. Seien Sie also moderat, passen Sie Dienste für Klassen an, die auf Schnittstellen basieren, stellen Sie der aufrufenden Klasse nur die Methoden zur Verfügung, die sie benötigt, und verbergen Sie die Methoden, die sie nicht benötigt.

Regel:

* Eine Schnittstelle bedient nur eine Submodul oder Geschäftslogik, Serviceanpassung;

* Komprimieren Sie die öffentlichen Methoden in der Schnittstelle durch Geschäftslogik, um die Schnittstelle schlanker zu gestalten

* Ändern Sie verschmutzte Schnittstellen so weit wie möglich, verwenden Sie den Adaptermodus zur Transformation.

* Verstehen Sie die Logik im Detail und kontrollieren Sie die Designideen mit Herz Wahrnehmung;

So implementieren Sie die Schnittstellenisolierung. Es gibt zwei Hauptmethoden:

1. Durch Hinzufügen eines neuen Schnittstellentyps wird die direkte Abhängigkeit des Kunden von der Schnittstelle isoliert erhöht auch den Systemaufwand;

2. Mehrfache Trennung der Vererbung, Realisierung von Kundenbedürfnissen durch mehrfache Vererbung von Schnittstellen; Sprechen Sie nicht mit Fremden, um es für Laien auszudrücken. Dies bedeutet, dass ein Objekt weniger über die Klassen wissen sollte, die zum Aufrufen gekoppelt und zugeordnet werden müssen. Dies führt zu einer Verringerung des Kopplungsgrads zwischen Klassen, und jede Klasse wird es versuchen um die Abhängigkeit von anderen Klassen zu verringern.

Prinzip der Synthese und Wiederverwendung

Das Prinzip besteht darin, so viel wie möglich Synthese/Aggregation anstelle der Vererbung zu verwenden;

Öffnungs- und Schließprinzip

Definition: Eine Software-Entität wie eine Klasse, eine Vorlage usw Funktion sollte erweitert werden, Änderung ist geschlossen;

Lösung: Wenn die Software geändert werden muss, versuchen Sie, die Änderung durch Erweitern des Verhaltens der Software-Entität zu erreichen, anstatt den vorhandenen Code zu ändern.

Prinzip der Einzelverantwortung: Implementierungsklassen muss eine einzige Verantwortung haben;

    Richter-Substitutionsprinzip: Das Vererbungssystem nicht zerstören;
  • Interface-Isolationsprinzip: Seien Sie einfach beim Entwerfen von Schnittstellen
  • Dimit-Regel: Kopplung reduzieren;

  • Öffnungs- und Schließprinzip: allgemeine Gliederung, offen für Erweiterung, geschlossen für Änderung;

  • Weitere Informationen zu diesem Thema finden Sie auf:
  • PHP-Chinese-Website

    !

Das obige ist der detaillierte Inhalt vonWas ist der Zweck der Codierung beim Codedesign von Managementinformationssystemen?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn