Mam następujący przypadek. Użytkownik może eksportować kilka typów obiektów (transakcje, faktury itp.) Do zewnętrznego systemu księgowego. algorytm Export zawiera etapy:Implementowanie podobnych przypadków użycia wygląda następująco: powielanie kodu
- pobieranych z obiektów przez jakiś filtr
- eksport obiektów pojedynczo do systemu księgowego (metoda serwis internetowy od rodzaju obiektu)
- zarejestrować fakt, że dany dokument został wyeksportowany, więc wont być eksportowane ponownie
- przygotować podsumowanie dla użytkownika (Lb eksportowanych dokumentów, komunikatów o błędach itp)
algorytm jest taki sam dla wszystkich typów obiektów, ale nie są pewne istotne różnice, które muszą być obsługiwane:
- różne typy
- inny sposób docelowy serwis internetowy, inny obiekt do Dto odwzorowań
- różnych filtrów według rodzaju obiektu
ja uważane za kilka rozwiązań:
- nie traktuj algorytmu eksportu jako duplikacji kodu i implementuj algorytm thm na typ obiektu. Eksport dowolnych danych do dowolnego systemu zewnętrznego może być opisany za pomocą takiego algorytmu - czy to oznacza, że zawsze powinniśmy mieć jedną ogólną klasę do wyeksportowania czegokolwiek do dowolnego miejsca? :)
- przenieść różnice do strategii (jeden interfejs strategii do tworzenia abstrakcji dla wszystkie różnice) - Nawet go wdrożyłem.
- stosowanie leków generycznych - niestety mam kodowania w PHP i nie jest możliwe
Pytanie:
tworzy osobny algorytm eksport za obiekt wpisać powielania kodu?
Może wszystkie z nich powinny być traktowane jako osobne przypadki użycia?
Jeśli to duplikacja, to jakie techniki, aby tego uniknąć, należy wziąć pod uwagę?
opis mojego pierwszego wdrożenia:
W pierwszym podejściu ja zdefiniował eksportowalne abstrakcji, ale nie byłem zadowolony. Każdy obiekt ma zupełnie inny ładunek. Interfejs do eksportu zdefiniował tylko jedną metodę getId i został użyty do zarejestrowania, że obiekt został wyeksportowany (i dzięki temu nie będzie ponownie eksportowany). W tym celu abstrakcja była w porządku, ale problem został przeniesiony do usługi exportService, która musiała sprawdzić konkretną instancję, aby wybrać program odwzorowujący DTO i punkt końcowy. Tak więc exportService złamał SOLID.
Bardzo dobre pytanie. Czy wziąłeś pod uwagę relacje * «obejmują» * i * «rozszerz» *? Prawdopodobnie pomogliby tutaj. Również niektóre wzorce, takie jak * Framework *, * Extensibility * lub * Template Method * mogą być alternatywą dla twoich podejść do implementacji. – Waog
Po pierwsze, powinieneś zobaczyć filtrowanie i eksportowanie jako dwa różne problemy. Zwykle chcesz przenieść różnice do strategii, a następnie ukryć wybór strategii za fasadą/fabryką w zależności od sposobu zaprojektowania interfejsu API. Na przykład, klient może wykonać tylko 'exportService.export (listOfExportable)', ale wewnętrznie w oparciu o typ 'Exportable', wybrany zostanie punkt końcowy usługi WWW, a także asembler dto. Usługa eksportowa może być konfigurowalna z zewnątrz, aby uniknąć naruszenia zasady otwartej zamkniętej. Można również wybrać opcję strategii w obszarze Eksportowalny. – plalx
Zaleta polegająca na zezwoleniu na eksport do określenia strategii pozwoli uniknąć stosowania wzorca lokalizatora usług w usłudze eksportu. Usługa exportService może po prostu podwójnie wysłać wiadomość 'Exportable', aby zebrać informacje. Jednocześnie jest to niekorzystne, ponieważ problemy związane z infrastrukturą mogą wyciekać w warstwach, gdzie nie powinny. Podobna jest walka z "czy powinienem umieścić adnotacje ORM w encji, czy też powinienem używać zewnętrznych plików XML?". – plalx