2015-06-24 20 views
5

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.

+0

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

+2

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

+0

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

Odpowiedz

0

Żadna z opisanych wyżej cech nie jest logiką specyficzną dla domeny (a nawet nie wspominasz o domenie problemu w twoim pytaniu), więc nie sądzę, że jest to projekt oparty na domenie.Ponieważ nie jest to logika specyficzna dla domeny, nie martwiłbym się zbytnio powielaniem kodu, szczególnie biorąc pod uwagę, że rozwiązanie nie wydaje się oczywiste.

Zachowaj prostotę i po prostu wypisz każdy przypadek użycia osobno. Jeśli okaże się, że istnieje wspólny kod, który można łatwo refaktoryzować, zrób to po uzyskaniu płynnego działania. Nie nadużywaj go ani nie dodawaj wzorów, zanim będą one oczywiście konieczne.

+0

Może to być subdomena jego głównej domeny. * "Zarejestruj fakt, że dany dokument został wyeksportowany, więc nie będzie ponownie eksportowany" * to logika domenowa IMO. – guillaume31