patterns:inheritancerolestragegyoverview:role
Differences
This shows you the differences between two versions of the page.
|
patterns:inheritancerolestragegyoverview:role [2013/01/08 21:20] rtavassoli [Der abstrakte Mitarbeiter] |
patterns:inheritancerolestragegyoverview:role [2013/01/08 21:21] (current) rtavassoli [Der abstrakte Mitarbeiter] |
||
|---|---|---|---|
| Line 11: | Line 11: | ||
| Die Antwort lautet wie in so vielen Fällen: es kommt darauf an. Lohnt sich die zusätzliche Komplexität? Ich kann mir keinen anderen Mitarbeiter vorstellen als eine Person. Wenn man die Person weg abstrahieren möchte, und den Employee an eine beliebige Implementierung von einer Person über abgeleitete Klassen von Employee((ProMPersonEmployee, MSCRMPersonEmployee, usw.)) hängen können möchte, würde man keine Domäne mehr bauen, sondern ein Framework. Man würde sich dann tot-abstrahieren, jede konkrete Implementierung ablehnen, und nie fertig werden. | Die Antwort lautet wie in so vielen Fällen: es kommt darauf an. Lohnt sich die zusätzliche Komplexität? Ich kann mir keinen anderen Mitarbeiter vorstellen als eine Person. Wenn man die Person weg abstrahieren möchte, und den Employee an eine beliebige Implementierung von einer Person über abgeleitete Klassen von Employee((ProMPersonEmployee, MSCRMPersonEmployee, usw.)) hängen können möchte, würde man keine Domäne mehr bauen, sondern ein Framework. Man würde sich dann tot-abstrahieren, jede konkrete Implementierung ablehnen, und nie fertig werden. | ||
| \\ \\ | \\ \\ | ||
| - | Man müsste sich höchstens Gedanken über die möglichen Berührungspunkte für potenzielle Schnittstellen machen. In dem Fall wäre es nicht, dass man den Mitarbeiter als Schnittstellenpunkt nehmen würde, sondern die Person. Wenn die Person somit aus einem anderen Bereich kommt, würde man eine Schnittstelle bauen, die eine FremdsystemPerson in eine Person wandelt. Der Mitarbeiterkontext hat dann immer den Personenkontext auf den er sich beziehen kann. Wenn die Kontexte klein genug gehalten werden, dann sind auch solche Schnittstellen schnell und einfach umzusetzen. | + | Man müsste sich höchstens Gedanken über die möglichen Berührungspunkte für potenzielle Schnittstellen machen. In dem Fall wäre es nicht so, dass man den Mitarbeiter als Schnittstellenpunkt nehmen würde, sondern die Person. Wenn die Person somit aus einem anderen Bereich kommt, würde man eine Schnittstelle bauen, die eine FremdsystemPerson in eine Person wandelt. Der Mitarbeiterkontext hat dann immer den Personenkontext auf den er sich beziehen kann. Wenn die Kontexte klein genug gehalten werden, dann sind auch solche Schnittstellen schnell und einfach umzusetzen. |
| \\ \\ | \\ \\ | ||
| Vor allem aber wird der Personenbereich nicht ersetzt werden. Und wenn doch, dann wird der vorhandene Person BC einfach als Schnittstelle verwendet zwischen dem neuen Personenbereich und dem Mitarbeiterbereich. Wenn sich in dem anderen Bereich ein Name ändert, dann fängt ein Handler das OtherPersonBCPersonNameChanged Ereignis ab und sendet ein ChangePersonName Befehl an die Person in der Person BC. Befehle an die Person BC werden in Befehle an die OtherPersonBCPerson umgeleitet. Das ist flexibel und pragmatisch genug. | Vor allem aber wird der Personenbereich nicht ersetzt werden. Und wenn doch, dann wird der vorhandene Person BC einfach als Schnittstelle verwendet zwischen dem neuen Personenbereich und dem Mitarbeiterbereich. Wenn sich in dem anderen Bereich ein Name ändert, dann fängt ein Handler das OtherPersonBCPersonNameChanged Ereignis ab und sendet ein ChangePersonName Befehl an die Person in der Person BC. Befehle an die Person BC werden in Befehle an die OtherPersonBCPerson umgeleitet. Das ist flexibel und pragmatisch genug. | ||
patterns/inheritancerolestragegyoverview/role.1357676446.txt.gz · Last modified: 2013/01/08 21:20 by rtavassoli
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 3.0 Unported
