Ich würde zumindest eine gerade Gabel betrachten. So können sich Ihre individuellen Projekte selbstständig entwickeln. Sie können Bits bereinigen, die sie nicht verwenden, und wenn Sie wirklich gemeinsam genutzte Bibliotheken benötigen, identifizieren Sie sie nach dem Wort und refaktorieren Sie, um sie nach Bedarf zu verwenden.
Ich habe in der Vergangenheit festgestellt, dass, wenn ich es so gemacht habe, ich festgestellt habe, dass die "Abhängigkeiten" nicht so häufig sind, wie ich dachte, und dass ich sie in dasselbe gehorcht habe Form im Laufe der Jahre. Zum Beispiel, in Modul A (nennen wir es Billing) Ich habe einen Kunden, der Dinge wie Kreditbedingungen, ausstehenden Saldo usw. hat. In Modul B (nennen Sie es Support) Ich werde den gleichen Kunden haben , aber sie haben völlig andere Eigenschaften, wie Softwareversionen oder Support-Verlauf.
Abgesehen davon, dass beide "Benutzer" genannt werden und einen gemeinsamen ID-Wert haben, haben sie nichts miteinander zu tun und gehören nicht wirklich in dieselbe Klasse. Sobald Modul A aus Modul B abgeleitet wurde, wurden die Benutzerobjekte viel kleiner und fokussierter.
Dies ist die gleiche Entdeckung, die Menschen in Micro-Services machen. Die Dinge, von denen sie dachten, dass sie geteilt werden müssten, mussten nicht wirklich geteilt werden und profitierten davon, sie zu zersetzen. Es ist kein Allheilmittel, denn manchmal gibt es wirklich komplexe Objekte, die wirklich geteilt werden, aber es ist nicht so häufig, wie du denkst. Oft ist es nur eine Sache von zwei verschiedenen Dingen, die denselben "Namen" haben und somit in derselben Klasse/demselben Modul abgelegt werden.
Ich gehe davon aus, dass A und B nicht verwandt sind, aber sie müssen die Funktionen des jeweils anderen aufrufen. Heute rufen sie direkt an. Nach der Gabelung, was ist der beste Weg? B stellt seine Implementierung als Schnittstelle zur Verfügung, und A verwendet class.forName und type konvertiert es in die Implementierungsschnittstelle und verwendet sie. – cloudpre