moje pytanie dotyczy sposobu radzenia sobie z dziedziczeniem w sposób funkcjonalny w języku F #. Aby to trochę opisać, podaję prosty przykład. Załóżmy, że chcemy modelować świat składający się z różnych gatunków zwierząt. Każdy rodzaj zwierząt ma pewne atrybuty z innymi rodzajami (np. Nazwa, rozmiar itp.). Ponadto każdy rodzaj może mieć inne, które nie są dzielone przez inne osoby (np. Liczba dzieci jest odpowiednia dla psów i kotów, jednak na przykład dla pająków). Ponadto, mogą istnieć sposoby lub funkcje związane z każdym typem zwierzęcia, które mogą być lub nie być takie same dla dwóch rodzajów zwierząt, tj. Istnieje domyślna implementacja, która może być pominięta dla określonego rodzaju. Każdy rodzaj zwierząt może mieć metodę (metody), która jest zdefiniowana tylko dla tego rodzaju.F # i modelowanie dziedziczenia
Teraz, w świecie OOP, prawdopodobnie doprowadziłoby to do powstania klasy abstrakcyjnej o wspólnych cechach i abstrakcyjnych metodach, a następnie klasach pochodnych dla każdego rodzaju zwierząt. Nie jestem pewien, jak określić funkcjonalnie model domeny w F #. Tutaj: Which to use , abstract class or interface in F#? jest twierdził, że "idiomatyczny kod F # używa różnych punktów rozszerzalności niż C# (np. Przyjmując funkcję/interfejs jako argument), więc naprawdę nie potrzebujesz klas abstrakcyjnych".
Jeśli jest to sposób, który powinien zostać przyjęty, czy można podać jakiś element tego przykładu?
Jeśli chodzi o moje dalsze rozważania na ten temat, przypuszczam, że atrybuty powinny być zamknięte w pewnej strukturze. Wtedy najbardziej idiomatyczna struktura pod tym względem w F # jest rekordowa. Czy to oznacza, że ma istnieć zapis nadrzędny, który będzie zawarty w innych zapisach odpowiadających konkretnym "dzieciom", tj. Kompozycji zamiast dziedziczeniu. Wydaje mi się to jednak rozwiązaniem tymczasowym, które nie jest ani idiomatyczne, ani szczególnie eleganckie.
Myślę, że preferowanym sposobem modelowania dziedziczenia w F # są dyskryminowane związki. Jednak nie rozwiązuje to problemu wspólnych atrybutów i metod.
Modele podobne do wspomnianych powyżej są dość częste w moim widoku, ponieważ są domyślnie zawarte w większości aplikacji dla przedsiębiorstw. Czy jest więc jakaś sugestia, jak można to potraktować w sposób funkcjonalny (np. Sposób sugerowany pod powyższym linkiem lub jakakolwiek inna sugestia)? Czy możemy powiedzieć, że nie jest to domena, którą można łatwo modelować za pomocą podejścia funkcjonalnego?
Dziękuję.
Dobre pytanie, wspaniała odpowiedź! – mydogisbox
Odpowiedź Tomasa Petricka jest bardzo dobra. Chciałbym również polecić następującą odpowiedź Normana Ramseya: http://stackoverflow.com/a/2079678/631115. – Shredderroy
Tomas, dziękuję za przykład. To jest ładne i proste. Jeśli chodzi o opis, który podałem, starałem się wyraźnie odróżnić opis i możliwą implementację (klasa abstrakcyjna). Zastanawiam się, czy wspólne funkcje (np. Funkcja zwracająca nazwę zwierzęcia w jakiś fantazyjny sposób - dla wszystkich zwierząt - lub niektóre współczynniki dla dzieci - dla wszystkich ssaków) mają być częścią poszczególnych typów (AnimalInfo - które jeszcze zostałyby utworzone) oraz MammalInfo) jako jego członkowie lub bez względu na to, czy deklarują je swobodnie (nie są przypisani). Uważam również, że jest to pytanie bardziej ogólne, niezwiązane wyłącznie z typem kompozycji. – user2039784