Czy stosować interfejs przy różnych celach metod?

Taka sobie sytuacja:
Trzeba wykonać pewne czynności na pewnym obiekcie X. Do robienia każdej czynności powstała osobna klasa. Zadania poszczególnych klas są zupełnie różne (biznesowo) i nie są ze sobą wymienialne. Co więcej, czynności są zależne od poprzednych czynności oraz ważna jest kolejność. Przypadkiem sygnatury metod są takie same, tzn metoda publiczna w klasach przyjmuje obiekt X plus jakiś zestaw danych.
Dostałem zalecenie aby wyekstraktować interfejs, wrzucić klasy do jakiejś listy i po niej iterować. Nie jestem jednak przekonany, że interfejs jest tu uzasadniony. Jak myślicie?

Trzeba wykonać pewne czynności na pewnym obiekcie X. Do robienia każdej czynności powstała osobna klasa

To już brzmi jakbyś nie miał OOP. Ponieważ jestem hejterem OOP to plus dla ciebie

Dostałem zalecenie aby wyekstraktować interfejs, wrzucić klasy do jakiejś listy i po niej iterować. Nie jestem jednak przekonany, że interfejs jest tu uzasadniony.

A co to za język? Może da się pójść jeszcze dalej i użyć jakiegoś wbudowanego w język interfejsu. Np BiFunction w Javie?
Co do iterowania po liście to trochę overengineering. Tzn kiedyś zrobiłem coś takiego w kodzie produkcyjnym, ale kolejność elementów była czytana z konfiguracji

Moim zdaniem wygląda to całkiem ok. Czemu widzisz tu jakis problem? Jw. pewnie samo Function<X,Y> by starczyło, ale nie szkodzi zrobić swój interfejs

Lwojtow napisał(a):

Taka sobie sytuacja:

Co więcej, czynności są zależne od poprzednych czynności oraz ważna jest kolejność.

gdyby to miało być zupełnie głupotoodporne, to widziałem buildery w wersji zaawansowanej się tak robi, że każdy etap zwraca inną klasę.
Takie podobieństwo mi się skojarzyło. I wtedy by tego było więcej (tego tzn klas /interfejsów)

Pytanie, czy takiej głupotoodporności potrzebujesz

Ja bym pewnie w każdej z tych klas implementował BiFunction
plus jedna klaska, która orkiestruje całe przetwarzanie tj. jest odpowiedzialna za kolejność.

Ten pomysł jest równie pokręcony jak dolewanie wody do pralki w trakcie jej pracy.

Jeżeli Twoje obiekty-algorytmy będą implementowały ten sam interfejs i będą na jednej liście, to znaczy, że będzie można dowolnie zmieniać ich kolejność w tej liście, i przetwarzać dane wejściowe w dowolnej kolejności. To się wyklucza ze stwierdzeniem, że kolejność jest istotna.
Tak jak @Stój Halina zauważył(a), procesu powinny pilnować typy, tzn. metoda A zwraca obiekt typu XA, metoda B zwraca obiekt typu XB, itd., wówczas nie ma ryzyka popełnienia błędu. Utworzenie jednego interfejsu do wszystkiego, w tym przypadku zbliża Twój kod do jakiegoś języka dynamicznego. Fuj.

Jeszcze niech ktoś wrzuci te wszystkie obiekty do kontenera IoC i umieści tam logikę tworzącą listę zgodnie z jakąś kolejnością, to dopiero będzie happy debugging i czarna magia.

Widziałem takie rozwiązania w praktyce, to jest po prostu szambo.

Lwojtow napisał(a):

Taka sobie sytuacja:

Trzeba wykonać pewne czynności na pewnym obiekcie X. Do robienia każdej czynności powstała osobna klasa. Zadania poszczególnych klas są zupełnie różne (biznesowo) i nie są ze sobą wymienialne. Co więcej, czynności są zależne od poprzednych czynności oraz ważna jest kolejność. Przypadkiem sygnatury metod są takie same, tzn metoda publiczna w klasach przyjmuje obiekt X plus jakiś zestaw danych.

Jeżeli każda z klas robi coś kompletnie innego, a przez przypadek sygnatury się zgadzają, to nie ma sensu (i nie należy) wprowadzać wspólnego interface'u.

Dostałem zalecenie aby wyekstraktować interfejs, wrzucić klasy do jakiejś listy i po niej iterować. Nie jestem jednak przekonany, że interfejs jest tu uzasadniony. Jak myślicie?

Jeżeli wrzuca się je do jednej listy i na wszystkich wykonuje się to samo, to jednak coś wspólnego ze sobą mają. Domyślam się, że część funkcjonalności.

Przykład:
Masz obiekty z kompletnie różnych bajek, robiące kompletnie różne rzeczy, ale z jakiegoś powodu istotny jest moment stworzenia każdego z nich
tworzysz więc interface HasCreationTime, wrzucasz w nim metodę Instant getCreationTime() i dzięki temu jesteś w stanie wrzucić je do kolekcji List<HasCreationTime> i np. obliczyć i zsumować łączny wiek tych obiektów. To w jaki sposób wykonywana jest realizowana ta metoda jest kompletnie bez znaczenia i może to być różny sposób w różnych klasach, tak długo jak zwraca to, co w danym przypadku jest uznane za datę utworzenia obiektu. Może to być wartość podana przez konstruktor, pobrana z krotki w bazie danych, data systemowa pobrana z zegara systemowego w konstruktorze i inne dziwactwa.

@somekind:

Jeżeli Twoje obiekty-algorytmy będą implementowały ten sam interfejs i będą na jednej liście, to znaczy, że będzie można dowolnie zmieniać ich kolejność w tej liście, i przetwarzać dane wejściowe w dowolnej kolejności. To się wyklucza ze stwierdzeniem, że kolejność jest istotna.

Nic się moim nie zdaniem nie wyklucza. Ja widzę to trochę na takiej zasadzie, ze mamy pipeline do przetwarzania obrazków. Mamy akcje w stylu Resize, Rotate, BlackAndWhite, Cutout, Sharpen... Każda taka akcja robi coś innego, ale jednocześnie każda jest funkcją Image->Image.
Kolejność ułożenia operacji w konkretny pipeline ma oczywiście znaczenie, ale takich pipeline można poskładać wiele różnych. Dla mnie jak najbardziej w takiej sytuacji ma sens jakis interfejs ImageTransformer i zbudowanie sobie listy kroków dla konkretnego pipeline.

Jeszcze niech ktoś wrzuci te wszystkie obiekty do kontenera IoC i umieści tam logikę tworzącą listę zgodnie z jakąś kolejnością, to dopiero będzie happy debugging i czarna magia.

Nie widzę powodu, żeby nie móc konfigurować sobie takich pipeline bo to będzie przecież tylko lista kroków

@Shalom: no dobrze, to trzymając się przykładu z obrazkami, przy takich potrzebach każdy taki pipeline operacji wykonywanych na obrazku należy jakoś opakować, wprowadzając klasy np. PrzygotujDoWydrukuNaDrukarce albo PrzygotujDoWyświetleniaNaStroniePodczasŻałoby aby było dało się tym zarządzać i reużywać w sensowny sposób.
A do zaimplementowania tego nie trzeba ani żadnej listy, ani żadnego interfejsu.

@somekind nie jeśli chcesz móc taki pipeline składać dynamicznie :) Np. twój soft pozwala ułożyć sobie listę operacji a potem wykonać je na 1000 obrazków w podanym katalogu. Zresztą nawet w tym twoim przykładzie to bez sensu, bo jak masz interfejs i listę to nie potrzebujesz zadnych osobnych klas, tylko jedną klasę Pipeline która ma List<ImageTransformer> i tworzysz sobie ile chcesz obiektów takiej klasy z odpowiednimi listami kroków.

Jeżeli kod wygląda np. tak:

mailSender.Execute(context);
smsSender.Execute(context);
reportGenerator.Execute(context);
// etc...

to zdaje się, że ma to sens. Zależy jaki jest... kontekst.

Shalom napisał(a):

@somekind nie jeśli chcesz móc taki pipeline składać dynamicznie :) Np. twój soft pozwala ułożyć sobie listę operacji a potem wykonać je na 1000 obrazków w podanym katalogu.

No ok, jeżeli to jest ten przypadek, że użytkownik może sobie składać proces w locie, to faktycznie, interfejs i lista potrzebne.
Tylko OP jakoś o tym nie pisał. ;)

Zresztą nawet w tym twoim przykładzie to bez sensu, bo jak masz interfejs i listę to nie potrzebujesz zadnych osobnych klas, tylko jedną klasę Pipeline która ma List<ImageTransformer> i tworzysz sobie ile chcesz obiektów takiej klasy z odpowiednimi listami kroków.

A jak mam klasy, których nazwy opisują do czego służą, to nie muszę mieć zbędnego interfejsu ani anonimowej listy, która nic nie mówi o jej przeznaczeniu.