„Jeśli naprawdę chcesz cukru OO - idź użyć C ++” - to była natychmiastowa odpowiedź, którą otrzymałem od jednego z moich znajomych, kiedy o to zapytałem. Wiem, że dwie rzeczy są tutaj zupełnie nie tak. Pierwszy OO NIE jest „cukrem”, a po drugie C ++ NIE wchłonął C.
Musimy napisać serwer w C (front-end, do którego będzie w Pythonie), dlatego badam lepsze sposoby zarządzania dużymi programami C.
Modelowanie dużego systemu pod kątem obiektów i interakcji między obiektami sprawia, że jest on łatwiejszy w zarządzaniu, utrzymywaniu i rozszerzaniu. Ale kiedy próbujesz przetłumaczyć ten model na C, który nie zawiera obiektów (i wszystkiego innego), musisz podjąć ważne decyzje.
Czy tworzysz niestandardową bibliotekę, aby zapewnić abstrakcje OO, których potrzebuje Twój system? Rzeczy takie jak obiekty, enkapsulacja, dziedziczenie, polimorfizm, wyjątki, pub / sub (zdarzenia / sygnały), przestrzenie nazw, introspekcja itp. (Na przykład GObject lub COS ).
Lub po prostu używasz podstawowych konstrukcji C ( struct
i funkcji) do aproksymacji wszystkich swoich klas obiektów (i innych abstrakcji). (na przykład niektóre odpowiedzi na to pytanie w SO )
Pierwsze podejście zapewnia ustrukturyzowany sposób implementacji całego modelu w C. Ale dodaje również warstwę złożoności, którą musisz zachować. (Pamiętaj, że złożoność była tym, co chcieliśmy zmniejszyć, używając obiektów w pierwszej kolejności).
Nie wiem o drugim podejściu i jego skuteczności w przybliżeniu wszystkich abstrakcji, których możesz potrzebować.
Tak więc moje proste pytania brzmią: jakie są najlepsze praktyki w realizacji projektowania obiektowego w C. Pamiętaj, że nie pytam JAK to zrobić. To i te pytania mówią o tym, a jest nawet książka na ten temat. Bardziej mnie interesują realistyczne porady / przykłady, które odnoszą się do prawdziwych problemów, które pojawiają się, gdy się to dzieje.
Uwaga: nie rób, dlaczego C nie powinien być używany na rzecz C ++. Minęliśmy już ten etap.
extern "C"
i mógł być używany z Pythona. Możesz to zrobić ręcznie lub możesz poprosić SWIG o pomoc. Zatem pragnienie interfejsu użytkownika w Pythonie nie jest powodem, aby nie używać C ++. Nie znaczy to, że nie ma uzasadnionych powodów, aby chcieć zostać z C.