[czlowiek_z_lisciem_na_glowie]

Jak nazwać Interface A, który mówi że obiekt, który go rozszerza jest w stanie przetworzyć Interface B?

Na przykład: mam klasę C z pakietu 3th party, która na podstawie danych z tablicy renderuje formularz opcji. Mój framework podnosi abstrakcję wyżej i zamiast tablicy operuje na interfejsach. Dlatego Powstała klasa D, która dziedziczy po klasie 3th party C i zamiast tablicy z parametrami przyjmuje interfejs A. Interfejs A jest uniwersalnym interfejsem zawierającym konfigurację formularza i chcę go teraz używać jako danych wejściowych nie tylko dla klasy D, ale także dla kilku innych klas 3th party.
Będę miał zatem klasę D, E i F, które są w stanie przetworzyć interfejs A. Skoro już są 3 klasy więc wypadałoby nadaćim jakiś wspólny interfejs B, który by mówił, że "Potrafię przetworzyć jako dane wejściowe interfejs A". Jak nazwać taki interfejs?

Pytanie też, czy nie przekombinowuję i czy to nie jest sztuka dla sztuki?
Uprzedzając, nie posłużę się żadnymi wbudowanymi ficzerami w Symfony bo to projekt oparty o Wordpress a tak jak wiecie, panuje noarchitecture ;)

#programowanie #php #oop #programowanieobiektowe

[Rhodium]

nie wiem jakie są konwencje w php ale gdybym robił to w c# to użyłbym np: IFormOptionsConfiguration i IFormRenderer (jeśli przeznaczeniem ich wszystkich jest renderowanie tego co mają dostarczone z konfiguracji) lub po prostu IFormOptionsConfigurationHandler

[cmsp]

Brak realnego przypadku trochę utrudnia w zrozumieniu... ogólnie to co opisujesz brzmi mi na wzorzec strategii
- A to dane wejściowe
- D,E,F to strategie
- B to interfejs strategii

Więcej o wzorcu strategii: https://refactoring.guru/pl/design-patterns/strategy

[Krolik]

@czlowiek_z_lisciem_na_glowie: z tego co piszesz to lepiej zastosować adapter. Adapter to wspólny interfejs do konfiguracji formularza. Implementacje adaptera robisz dla każdego typu formularza i te implementacje otrzymują formularz jako zależność. Nie należy dziedziczyć z klas 3rd party. W ogóle w tym designie nie masz dziedziczenia a jedynie interfejsy.

[zakopiak]

@czlowiek_z_lisciem_na_glowie:

Klasy D, E, F, to są adaptery, i zgodnie z praktyką composition over inheritance, nie powinieneś rozszerzać klas 3rd party, tylko klasa 3rd party jest zależnością adaptera.

Interfejs B, który będzie implementowany przez D,E,F, powinien nazywać się od tego, co reprezentuje. "Przetwarzanie A", to mało konkretna informacja, więc ciężko powiedzieć jak dokładnie ma się nazywać.

na podstawie danych z tablicy renderuje formularz opcji.

Interfejs A jest uniwersalnym interfejsem zawierającym konfigurację

[Jurigag]

@czlowiek_z_lisciem_na_glowie: A jakie metody planujesz mieć w tym interfejsie? Bo to już często sugeruje nazwe interfejsu, np mając metodę drive, masz interfejs Vehicle albo Car itp

ja bym poszedł w takim kierunku, zastanów się dokładnie jakie metody będziesz miał w tym interfejsie, i jak skategoryzować te wszystkie 3 klasy implementujące to, musiałbyś dać jakieś konkretnie przypadki i tyle, jak nazywała się zmienna dla tej tablicy?

skoro mowa formularzu no to ja