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ę
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ę
Czy tylko ja nienawidzę programowania funkcyjnego?
Nie wiem czy to chwilowa moda czy tak już będzie zawsze, ale nie mogę przejść z OOP na FP.
Od razu podam przykłady o co mi chodzi z OOP i FP.
OOP dla mnie skupia się na obiektach i metodach na tych obiektach, kiedy w FP chodzi głównie o to by funkcje były bezstanowe (stateless), z użyciem higher order functions, monad i rekurencji.
Od kiedy
Troche sie meczylem koncepcyjnie z tym tematem, to moze podziele sie wnioskami.
FP, jesli chciec pisac tak kod calosciowo, jest przez powaznych ludzi uzywany *tylko* w domenach, gdzie wymagania matematyczne dot. kodu sa takie, ze jest benefitem / jest taka potrzeba, aby sam kod stanowil dowod matematyczny dla zaprogramowanego elementu / algorytmu / etc.
To jest wazne w niektorych dziedzinach nauki. Glownie takich silnie