Szukam wariata z #programowanie #programista15k z #cpp C++. Zastanawiam się nad wyborem designowym architektury mojej aplikacji:
Obiekt dźwięku potrzebuje kilku referencji do obiektów które zostały rozproszone po aplikacji i wymagają oddzielnej inicjalizacji. Poza tym sam obiekt dźwięku nie powinien podczas konstrukcji wymagać podawania mu stale tych obiektów.
Z początku pomyślałem o stworzeniu fabryki ale nie chcę wprowadzać zamieszania i w ramach minimalistycznego podejścia, nie widzę uzasadnionej potrzeby (fabrykę wykorzystałbym gdyby ten obiekt po czymś dziedziczył i tworzyłbym inne polimorfizmy obiektu bazowego, a te same obiekty trzeba podać podczas jej konstrukcji) by to robić.
Moim aktualnym rozwiązaniem (na które wpadłem ( ͡°͜ʖ͡°)) jest zrobienie statycznych wskaźników do tych potrzebnych obiektów, statycznego boola mówiącego o tym czy te wskaźniki są już zainicjalizowane oraz statycznej metody, która je inicjalizuje stałymi referencjami tych obiektów. Konstruktor sprawdzałby czy obiekt został już zainicjalizowany i w przypadku gdyby jakiś pajac (na przykład ja ( ͡º͜ʖ͡º)) wywołał konstrukcje obiektu bez uprzedniego ustawienia tych pointerów, rzuciłbym wyjątkiem i stworzyłbym core dumpa (standardowa procedura).
Jest jakiś argument przeciw mojemu podejściu? Lepsze rozwiązanie? Jakiś pattern który przychodzi na myśl po przeczytaniu mojego opisu? Będę wdzięczny za każdą wypowiedź (｡◕‿‿◕｡)
@AnonimoweLwiatko: Najlepiej zrób wszystko statyczne, to nie będziesz mieć więcej takich problemów. A na poważnie, to pierwsze co mi przyszło do głowy, to to że coś jest nie tak z architekturą twojej aplikacji, skoro obiekty są po niej tak rozproszone. Co do fabryki, to nie musisz implementować od razu abstract factory. Wystarczy zwykła klasa pomagająca w tworzeniu obiektów i nie jest to żadne zamieszanie. Jak już musisz zaimplementować taki rejestr
@SpinOff: Obiekty po niej są starannie i odpowiednio ustrukturyzowane.
"In class-based programming, the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method—either specified in an interface and implemented by child classes, or implemented in
@AnonimoweLwiatko: imo masz coś źle z designem, ale w jednym poście nie opiszesz tego jak działa twoja aplikacja. Niezależnie od tego jaką masz aplikację to drzewo zależności powinno być proste: w jaki sposób te obiekty są rozproszone i dlaczego nie mogą być zainicializowane na start aplikacji?
Co do twojego problemu: imo dzwięk powinień być fabryką, która z tych potrzebnych obiektów przekazanych np. do metody fabrycznej i tego co zawiera teraz
@Brother_of_Steel: Chyba ci się z destruktorami pomyliło. @SpinOff: Po prostu kolega jeszcze żyje w starym C++ bez smart pointerów i scope guardów, albo nie przywykł jeszcze do wyjątków. @AnonimoweLwiatko: Ała ten const cast... bez komentarza. Czy ty po prostu nie potrzebujesz klasy kontekstu lub menażera? Niema nic złego, aby taki dźwięk miał wskaźnik na swój manager, któremu możesz też powierzyć tworzenie takich obiektów metodzie fabrykującej. Jeżeli
@Brother_of_Steel: abstrahując od tego co OP pisze, dlaczego wyjątek w konstruktorze to zły pomysł? Jak masz immutable obiekt i tworzysz go z zestawem parametrów które nie sa ok, to jak ograć taka sytuacje?
@sz__po: tak się nie robi. Bo jak p----------z jakiś wyjątek w ctor, to potem nie działa dtor. Albo masz niepełne obiekty zależne. Albo nullpointery. Chociażby. I niby pamiętasz o tym, ale twój kolega z projektu już nie i potem u klienta wali memory leak i myślicie co tu poszło nie tak. Są pewne pryncypia których warto się uczyć już na starcie, bo potem dziwne rzeczy się dzieją, szczególnie jak "szybko,
@Strus: no to sobie rób, u mnie byś code review nie przeszedł. Teoretycznie wolność jest i można wszystko. Praktycznie, robi się tak, żeby nie być mendą dla kolegów, którzy po tobie muszą robić bugfixing i pracować z klientem. Ja tam umiem pisać bez takich fikołków, ale zawsze przyjedzie jakaś mądrala i będzie pieprzyć, więc już dawno przestałam się na wykopie udzielać na takie tematy. Jak dla mnie możesz sobie nawet
@Strus: spoko, typku, w realu byś nie był taki wyszczekany. Wiadomo internet triggeruje hejterów, także ten. Kwiii, kwiii. Rozumiem, brak miłości, inni mają lepiej, ja ten typ tutaj widuje na okrągło. Nie będę kopać leżącego, bo co to za przyjemność? Żaden w tym honor wygrać ze słabszym.
tak się nie robi. Bo jak p----------z jakiś wyjątek w ctor, to potem nie działa dtor.
@Brother_of_Steel: destruktory odpalają się w sposób logiczny i nigdy nie miałem z tym problemu. Jeżeli masz jakieś dziwne zależności to masz problem w kodzie, który można rozwiązać zamykając poszczególne elementy do osobnych klas
Druga sprawa, niejako podstawowa to jak cokolwiek, gdziekolwiek przekazujesz i to "coś" może być puste, to jako programista masz obowiązek sprawdzić
@Saly: o rany, przestańcie mnie wołać. Zapomnij, że coś napisałem w ogóle. Ja chcę mieć wolne popołudnie, a nie teraz każdy mądry. Żałuję, że dałem się sprowokować, powinienem trzymać ryj na kłódkę. Programuj sobie jak chcesz, bo zaraz znowu się dowiem, że jestem jakimś dzbanem, albo innym chujem. Przestał mnie temat interesować po tych wycieczkach personalnych. Podsumuje to krótko i ostatecznie. Teoria sobie, praktyka sobie.
Obiekt dźwięku potrzebuje kilku referencji do obiektów które zostały rozproszone po aplikacji i wymagają oddzielnej inicjalizacji. Poza tym sam obiekt dźwięku nie powinien podczas konstrukcji wymagać podawania mu stale tych obiektów.
Z początku pomyślałem o stworzeniu fabryki ale nie chcę wprowadzać zamieszania i w ramach minimalistycznego podejścia, nie widzę uzasadnionej potrzeby (fabrykę wykorzystałbym gdyby ten obiekt po czymś dziedziczył i tworzyłbym inne polimorfizmy obiektu bazowego, a te same obiekty trzeba podać podczas jej konstrukcji) by to robić.
Moim aktualnym rozwiązaniem (na które wpadłem ( ͡° ͜ʖ ͡°)) jest zrobienie statycznych wskaźników do tych potrzebnych obiektów, statycznego boola mówiącego o tym czy te wskaźniki są już zainicjalizowane oraz statycznej metody, która je inicjalizuje stałymi referencjami tych obiektów. Konstruktor sprawdzałby czy obiekt został już zainicjalizowany i w przypadku gdyby jakiś pajac (na przykład ja ( ͡º ͜ʖ͡º)) wywołał konstrukcje obiektu bez uprzedniego ustawienia tych pointerów, rzuciłbym wyjątkiem i stworzyłbym core dumpa (standardowa procedura).
Jest jakiś argument przeciw mojemu podejściu? Lepsze rozwiązanie? Jakiś pattern który przychodzi na myśl po przeczytaniu mojego opisu? Będę wdzięczny za każdą wypowiedź (｡◕‿‿◕｡)
#chcepogadac
Co do fabryki, to nie musisz implementować od razu abstract factory. Wystarczy zwykła klasa pomagająca w tworzeniu obiektów i nie jest to żadne zamieszanie. Jak już musisz zaimplementować taki rejestr
"In class-based programming, the factory method pattern is a creational pattern that uses factory methods to deal with the problem of creating objects without having to specify the exact class of the object that will be created. This is done by creating objects by calling a factory method—either specified in an interface and implemented by child classes, or implemented in
Co do twojego problemu: imo dzwięk powinień być fabryką, która z tych potrzebnych obiektów przekazanych np. do metody fabrycznej i tego co zawiera teraz
@SpinOff: Po prostu kolega jeszcze żyje w starym C++ bez smart pointerów i scope guardów, albo nie przywykł jeszcze do wyjątków.
@AnonimoweLwiatko: Ała ten const cast... bez komentarza. Czy ty po prostu nie potrzebujesz klasy kontekstu lub menażera? Niema nic złego, aby taki dźwięk miał wskaźnik na swój manager, któremu możesz też powierzyć tworzenie takich obiektów metodzie fabrykującej. Jeżeli
Są pewne pryncypia których warto się uczyć już na starcie, bo potem dziwne rzeczy się dzieją, szczególnie jak "szybko,
@sz__po @Brother_of_Steel: Robi się, rzucenie wyjątkiem z konstruktora jest jedynym sensownym w C++ sposobem na zasyngalizowanie, że konstrukcja obiektu się nie udała. Nawet Bjorne jest tego zdania:
https://www.stroustrup.com/bs_faq2.html#ctor-exceptions
Teoretycznie wolność jest i można wszystko.
Praktycznie, robi się tak, żeby nie być mendą dla kolegów, którzy po tobie muszą robić bugfixing i pracować z klientem.
Ja tam umiem pisać bez takich fikołków, ale zawsze przyjedzie jakaś mądrala i będzie pieprzyć, więc już dawno przestałam się na wykopie udzielać na takie tematy. Jak dla mnie możesz sobie nawet
@Brother_of_Steel: XDDDDDDDDDDDDDDD
No, ja nie, Bjorne nie, i Herb Sutter też nie.
https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-throw
Na szczęście ogarnięci ludzie rzadko kiedy pracują z dzbanami, więc raczej się nie spotkamy ( ͡° ͜ʖ ͡°)
@Brother_of_Steel: destruktory odpalają się w sposób logiczny i nigdy nie miałem z tym problemu. Jeżeli masz jakieś dziwne zależności to masz problem w kodzie, który można rozwiązać zamykając poszczególne elementy do osobnych klas
Żałuję, że dałem się sprowokować, powinienem trzymać ryj na kłódkę.
Programuj sobie jak chcesz, bo zaraz znowu się dowiem, że jestem jakimś dzbanem, albo innym chujem.
Przestał mnie temat interesować po tych wycieczkach personalnych.
Podsumuje to krótko i ostatecznie. Teoria sobie, praktyka sobie.