Cześć
znalazłem w internetach takie coś
http://www.bfilipek.com/2018/02/factory-selfregister.html (bardzo ciekawy wpis)
ale tak zastanawiam się jak by to można było wykorzystać w praktyce poza podanym przykladzie
przecież rejestracja (dodanie do mapy metody tworzącej) odbywa się w przypadku tworzenia obiektu
po co takie coś?
gdzie tego można użyć w praktyce - self registering - skoro można dodać do mapy statyczne metody kreatory
Automatyczna rejestracja odbywa się dzięki użyciu s_bRegistered, a nie dzięki utworzeniu obiektu (chyba, że mówisz o s_bRegistered)
no ale tworząc obiekt dzięki statycznej zmiennej jest od rejestrowany
czemu obiekt dziedziczy po klasie rejestratora?
jaki to ma sens i cel
skoro można to i bez tego osiągnąć
Dzięki temu wystarczy jedna deklaracja osiągnąć cel. Nie musisz się powtarzać i ręcznie rejestrować w każdym miejscu.
Równie dobrze można zapytać po co komu RAII, skoro można ręcznie wszystkie wyjścia z zakresu opatrzyć wywołaniami destruktorów. No można, tylko po co?
taka mała różnica RAII rozumiem i potrafię podać praktyczne wykorzystanie np lock guard
inne też +/- rozumiem jak np pimpl
a tego nie
nie mówię, że to ne ma sensu
ale nie mam skila/wiedzy żeby powiedzieć do czego w praktyce może się przydać
stąd moje pytanie - jak można to w praktyce wykorzystać
Tak samo jak każdą fabrykę. Jedyną różnicą jest to, że nie musisz ręcznie dodawać funkcji do fabryki, bo to dzieje się automatycznie.
Nie znaczy że nie można inaczej. Oczywiście że można. Warto jednak oprócz śrubokrętów które masz już w skrzynce mieć i inne narzędzia. Każde ma zady/walety :-)
Mokrowski napisał(a):
- Pugin'owa struktura dodawania nowych strategii obliczeń w aplikacji symulacyjnej. Choćby dla porównywania wyników różnych algorytmów/strategii.
- Dynamicznie budowana struktura dostępnych zasobów w zależności od czynników zewnętrznych dla fabryki w grze. Np. w zależności od czasu gry, doświadczenia gracza, tego co ma w zasobniku.
- Do łatwego dodawania nowych paneli/ekranów GUI definiowanych przez użytkownika (oczywiście wymaga backendu dla jakiegoś języka skryptowego lub zasobów do definiowania takowych).
- ...
Dalej ? :-)Nie znaczy że nie można inaczej. Oczywiście że można. Warto jednak oprócz śrubokrętów które masz już w skrzynce mieć i inne narzędzia. Każde ma zady/walety :-)
dziękuję za odpowiedź
ale tu tworząc obiekt rejestrujemy metodę do jego tworzenia (jesli nie był stworzony wcześniej)
ok
o ile rozumiem dodawanie do mapy nazwy i metody kreacji
o tyle tego dziedziczenia nie
class ZipCompression : public ICompressionMethod,
public RegisteredInFactory<ZipCompression>
tworzę obiekt i go rejestruje
no spoko
ale po co skoro zarejestrować mogę bez tworzenia
ale po co skoro zarejestrować mogę bez tworzenia
Słowa klucze: łatwość utrzymania, elastyczność, czas dodawania nowej właściwości oprogramowania...
Paradygmaty programowania (z "komunizmem obiektowości") zwyciężają nie z powodu tego że są szybsze, a dlatego że rozwiązują rzeczywiste problemy także poza algorytmiczne. Podobnie z idiomami językowymi lub pomysłami na automatyzacje pewnych czynności.
Nie zrozum mnie źle. Także znalazł bym pewnie zastosowanie gdzie to co Bartek proponuje jest mocno na wyrost. Często piękno i użyteczność rozwiązań tkwi w ich prostocie :-) Jest jednak pewna kategoria rozwiązań w których będziesz w ten sposób myślał i podobnie to implementował. I tyle :-)