Kiedy używać dziedziczenia a kiedy obiektu jako pole klasy?

Przy pisaniu wczytywania danych z pliku konfiguracyjnego w Pythonie natrafiłem na problem walidacji danych w pliku konfiguracyjnym i przypisywania do nich odpowiedniego typu.

Plik jest w formacie json jak nie ma jsona wiadaomo co robić.

Miałem trzy koncepcje na implementację:
-statyczny konstruktor
To rozwiązanie chyba nie ma sensu
-dodatkowe pola w klasie korzystające z pliku konfiguracyjnego
w obecnej architekturze tylko jedna klasa korzysta z pliku konfiguracyjnego jest to model pipe and filters
chciałbym jednak nie zamykać tego i później dodać możliwość konfiguracji z interfejsu przeglądarki
Czy lepiej zrobić interfejs w przeglądarce, który zmienia plik json czy nadpisywać klasę?
-klasa z samymi statycznymi polami z getterami i setterami z logiką - w tym przypadku wydaj się to sensowne
Taką klasę mogę wykorzystać jako taką, po której się dziedziczy i można odwołać się do pól tej klasy lub w klasie, która wykorzystuje konfiguracje zrobić pole z obiektem klasy

Czy można jakieś wzorcowe rozwiązanie w Pythonie jak powinno się takie rzeczy robić?

Marcin Marcin napisał(a):

Czy lepiej zrobić interfejs w przeglądarce, który zmienia plik json czy nadpisywać klasę?

Tego zadania nie rozumiem

Czy można jakieś wzorcowe rozwiązanie w Pythonie jak powinno się takie rzeczy robić?

Pytasz tylko dla Pythona czy dla wszystkich języków programowania?

Moje zdanie nie zmieniło się od przedczoraj. Wczytywałbym konfigurację na początku maina i przekazywał w konstruktorach lub metodach/funkcjach w zależności od potrzeb i języka

Źródłem konfiguracji może być plik json lub inna metoda np. dane od użytkownika przeglądarki W tym przypadku pytam tylko dla Python lecz ciekawi mnie jak powinno to wyglądać w Javie/C/C++

Jak konfiguracja nie jest globalna tylko za każdym razem przychodzi z innej metody czy wręcz z requestu przeglądarki tym bardziej nie ma co kombinować i konfiguracja powinna być przekazywana jak zwykły parametr

Czy powinienem wczytywanie konfiguracji schować za abstrakcją np. odczytu z pliku i mieć oddzielnie odczyt z pliku, oddzielnie odczyt z GUI
(jak jeszcze nie ma) i dopiero klasę która przechowuje konfiguracje?

Dziedziczenie po konfiguracji zeby mieć do niej dostęp to jakiś srogi WTF.

1. Zrób obiekt Configuration który wczyta konfiguracje i pozwala pobrać z niej pola
2. Przekaż ten obiekt tam gdzie jest ci potrzebny
3. Jeśli to za bardzo cię boli, to zrób ten obiekt dostępny w jakimś service locatorze albo jako singleton i wtedy każda inna klasa będzie miała do niego dostęp

Builder do tworzenia instancji configu

Result<Config> configResult = new ConfigBuilder()
					.FromPNG("config.png")
					.TryBuild();

a później przekazujesz to dalej właściwie w jaki sposób chcesz - constructor injection, method injection, whatever.

Marcin Marcin napisał(a):

Czy powinienem wczytywanie konfiguracji schować za abstrakcją np. odczytu z pliku i mieć oddzielnie odczyt z pliku, oddzielnie odczyt z GUI

(jak jeszcze nie ma) i dopiero klasę która przechowuje konfiguracje?

No mniej więcej. Przy czym nie robiłbym jednej wielkiej klasy na konfigurację wszystkiego, tylko też to podzielił na jakieś części w zależności od tego, do czego dana część konfiguracji służy.

Trochę myli mnie w tym przypadku słowo konfiguracja. Jeżeli chodzi ci o strukturę danych określającą jak działa aplikacja / usługa to masz następujące odpowiedzialności:

• struktura czyli zwykła klasa z danymi, ewentualnie zbiór klas, żeby nie mieć płaskiej struktury na 1000 linii
• tworzenie powyższego obiektu - factory, abstract factory, ta część musi być elastycznie napisana
• przechowywanie danych - tutaj wylądujesz w jakimś singletonie, nie ważne jak bardzo ta statyczność będzie zamaskowana
• udostępnianie tych danych wszystkiemu co ich w aplikacji potrzebuje i będzie potrzebować - IoC i ładowanie konfiguracji przez konstruktor do klas gdzie jest potrzebna

Takie podejście pozwoli ci na:

• dostęp do potrzebnych parametrów konfiguracyjnych tam gdzie będziesz ich potrzebować (lista takich miejsc rośnie wraz z rozwojem aplikacji
• prostą możliwość zmiany sposobu przechowywania tych danych: pliki w rożnych formatach, podpięcie się do jakiegoś zewnętrznego serwisu, wstrzyknięcie z łapy całej konfiguracji w testach integracyjnych, odczyt z bazy danych

Rzecz o której trzeba pamiętać to IoC, czyli klasa, która potrzebuje konfiguracji nie może wiedzieć skąd ją brać. Musi dostawać ją z zewnątrz w całości lub potrzebnej części.

@Marcin Marcin:

Kiedy używać dziedziczenia a kiedy obiektu jako pole klasy?

Krótko mówiąc -- to drugie, jeśli stawiasz sobie takie pytanie.

Kiedy używać dziedziczenia a kiedy obiektu jako pole klasy?

Kiedy wpadasz na pomysł, by klasa X spełniała swoją odpowiedzialność, ale jednocześnie dziedziczyła po XConfiguration tylko po to, aby mieć dostęp do konfiguracji i konfigurować samą siebie. Wtedy na bank.

Jeśli masz wątpliwości, wyobraź sobie butelkę wina, która jest jednocześnie korkociągiem i kieliszkiem - i teraz weź ten butelko-kieliszko-korkociąg, otwórz go nim samym i nalej sobie wina do jego samego, żeby się napić. Brzmi dziwnie? No to tak samo będzie przy dziedziczeniu po konfiguracji przez klasę, która potrzebuje konfiguracji :)