[JAVA] Wie man über Klassengestaltung (Division) in einem Geschäftssystem nachdenkt (1)
Es ist ein Thema, das ich noch erforsche, aber ich werde es aufschreiben, weil die Richtlinie festgelegt wurde und die Ergebnisse erzielt wurden. Für diejenigen, die es wissen, ist es "natürlich", also überspringen Sie den Artikel. Der Inhalt ist für junge bis mittlere Karriere. Ich hoffe, dass die Diskussion es weiter verbessern wird.
Annahme
- Java-App (C # ist in Ordnung, wenn es sich um eine objektorientierte Sprache handelt)
- Für Geschäftssysteme unabhängig von BtoC oder BtoB
- Beinhaltet Web-API usw. Kurz gesagt, Java-Batch usw. werden nicht behandelt.
- Die Programmierkenntnisse des Projektteams sind nicht so hoch.
- Stellen Sie sich ein Team vor, das viele SEs (nicht mehr Codierer) hat, die keine Fähigkeiten haben, obwohl die Kosten aufgrund der schädlichen Auswirkungen mehrerer Unteraufträge voll sind.
Was zu beachten ist
- Ich möchte eine Konfiguration haben, die flexibel auf Änderungen im Geschäft reagiert (Änderungen / Ergänzungen / Löschen von Anforderungen).
- Es wird in Zukunft kontinuierlich renoviert. Da jedoch die Wahrscheinlichkeit groß ist, dass sich die Mitglieder ändern, möchten wir die Lesbarkeit wichtig machen.
- Ich möchte keine zu schwierigen Theorien aufstellen, weil ich die Fähigkeiten der Projektmitglieder nicht erwarten kann. (Ich mag DDD nicht)
Ist es so ein Ort? Der Punkt ist: "Ich möchte Code schreiben, der leicht mit einfachem Code erweitert werden kann."
Fazit
Schreiben Sie eine kurze Schlussfolgerung. Teilen Sie die Klasse vertikal (prozedural) und horizontal (objektorientiert) entsprechend der Rolle. Es ist keine große Geschichte, aber wie man Controller / Service / Repository in Spring Boot aufteilt.
Konzept 1: Die Prämisse, dass das Geschäft einzigartig ist und der Mechanismus gemeinsam ist
Einfach ausgedrückt geht es bei der Systementwicklung häufig darum, das Geschäft eines Kunden zu verwalten. Es geht um Effizienz und Unternehmensgründung. Was zu diesem Zeitpunkt wichtig ist, ist ** Wenn Sie sich verschiedene Systeme ansehen, was sind die gemeinsamen Teile und die Teile, die nicht gemeinsam sind ** </ font>? Genau das steht in der Überschrift, und das Geschäft des Kunden selbst ist nicht üblich. Es besteht jedoch eine hohe Wahrscheinlichkeit, dass der Mechanismus, um dies zu erreichen, üblich ist.
Das Geschäft ist einzigartig
Wie viel sind beispielsweise die Verfahren gemeinsam, wenn man das System des internationalen Geldtransfergeschäfts von Banken und das Bestellgeschäft von Convenience-Stores betrachtet? Ist es nicht 0? Auf diese Weise ist das Geschäft völlig anders, wenn der Geschäftstyp unterschiedlich ist. Auch im selben internationalen Geldtransfergeschäft wird es anders sein, wenn die Bank dies tut und wenn die Wertpapierfirma dies tut. Selbst bei denselben Banken unterscheiden sich UFJ und Sumitomo (wenn das Geschäft dasselbe ist, kann es durch die Installation desselben Systems zu geringen Kosten realisiert werden). Mit anderen Worten, der Geschäftsteil kann grundsätzlich nicht wiederverwendet werden.
Der Mechanismus ist üblich
Selbst wenn das Geschäftssystem völlig anders ist, ist der darin verwendete Mechanismus normalerweise der gleiche. Dies bedeutet, dass Sie, wenn Sie Daten speichern möchten, LDAP oder SQL verwenden und wenn Sie eine Nachricht senden möchten, HTTP oder SOAP verwenden. Mit anderen Worten, Sie können sehen, dass der Teil des Mechanismus, z. B. das Speichern in der Datenbank oder das Senden der Anforderung an einen anderen Ort, häufig vorkommt (oder wiederverwendet wird). Wenn Sie sich auf eine Branche konzentrieren, entsprechen Sie möglicherweise dem Standard. Zum Beispiel wurde beschlossen, Swift Telegram für internationale Überweisungen zu verwenden, so dass der Mechanismus im Rahmen des internationalen Überweisungsgeschäfts anscheinend der gleiche ist.
Konzept 2: Akzeptieren Sie aus geschäftlichen Gründen doppelten Code
Gelegentlich gibt es Radikale, die überhaupt keinen doppelten Code zulassen und Code aufrufen können, der mehr als einmal als Methode angezeigt wird, aber (obwohl dies nicht so weit geht ...), wenn Sie eine Klasse oder Methode mit dieser Idee erstellen Es wird unmöglich, sich nach der Rolle zu trennen, und es wird ein chaotischer Code in Bezug auf Benennung und Funktionsteilung erstellt.
Auch wenn es anfangs wunderschön durch Erweiterungen usw. unterteilt war, gibt es Fälle, in denen Sie nur einen kleinen Teil der geerbten Klasse ändern möchten, während Sie die Reparatur fortsetzen (im schlimmsten Fall zum Zeitpunkt der nächsten Reparatur).
Selbst wenn eine solche Klasse zuerst erstellt und wunderschön aufgeteilt wird, wird AbstractClass2 erstellt und für die Verarbeitung doppelt vererbt, die sich in der nächsten Änderung nur teilweise unterscheidet. Es ist der Beginn der Hölle.
Ich habe bis zu vierfache Vererbung gesehen.
In der Vergangenheit wurde gesagt, dass eindeutige Codes schön sind, aber in Fällen, in denen Mitglieder mit geringen Fähigkeiten häufig ersetzt werden, werden komplizierte Codes zu einem Gepäckstück. Der Code ist unverständlich und nicht wartbar.
Was sollen wir dann tun? Denken Sie getrennt über Geschäft und Mechanismus nach, implementieren Sie den Geschäftsteil in jeder Klasse und standardisieren Sie den Mechanismusteil.
Selbst wenn doppelter Code auftritt, wird der Geschäftsteil einzeln implementiert. Selbst wenn die meisten von ihnen häufig sind, ist die Reparatur einfacher.
Methode1 wird wie folgt in der Business Class implementiert. Der Inhalt von Methode1 kann duplizierter Code sein, aber wir akzeptieren das Duplikat als ein anderes Geschäft. Selbst wenn die Anforderung besteht, dass Sie nur eine der Aufgaben ändern möchten, die zu Beginn gleich waren, können Sie sie korrigieren, indem Sie die Mindeständerungen vornehmen.
Methode2 wird als allgemeiner Mechanismus in AbstractClass platziert.
Es wird etwas länger, also fahren wir mit dem nächsten Artikel fort.
Recommended Posts