[C++] Konwencje nazewnicze klas i design strategii
Ostatnio zmodyfikowano 2019-11-07 01:23
irdcat Temat założony przez niniejszego użytkownika |
[C++] Konwencje nazewnicze klas i design strategii » 2019-11-07 01:07:08 W tym temacie chciałbym zapytać o dwie rzeczy. Pierwsza dotyczy trendów w kwestii konwencji nazewniczych klas w Cpp. Mam już prawie roczne doświadczenie jako Java developer. Z Cpp miałem ponad półroczną przerwę. Stosowanie długich, opisowych, typowo Javowych nazw okraszonych architektonicznymi pojęciami takimi jak np. SalesChannelResolutionStrategy, bądź zawieranie w nich informacji o tym czy jest to klasa abstrakcyjna, czy nie, weszło mi już w nawyk. W community C++ czegoś takiego nie zauważyłem, istnieje jakaś ogólnie przyjęta konwencja? Druga dotyczy bardziej designu. Tworzę sobie program, który będzie "pokazówką" efektów różnych algorytmów do generowania leveli dla gier roguelike. Dla nieznających tematu w dużym skrócie są to losowo generowane lochy, które w swojej podstawowej formie zawierają pokoje połączone korytarzami. Na pierwszy rzut oka idealny dla tego celu okazał się wzorzec Strategii. Pomysł opierał się o stworzenie interfejsu z metodą generującą level i każda jego implementacja reprezentowała by konkretny algorytm, jednak każdy z nich potrzebuje innych parametrów. Pierwszy pomysł realizacji wyglądał mniej więcej tak: Interfejs byłby generyczny, gdzie parametrem szablonu była by struktura przechowująca parametry, każda implementacja określała by PODa z potrzebnymi parametrami. template < class Params >
class AbstractLevelGeneratingStrategy
{
public:
virtual Level generate( const Params & params ) = 0;
}
Jednak pod jednym kątem wypada to średnio. Obsłużenie każdej nowej implementacji wymagało by dodatkowych modyfikacji w klasie obsługującej te strategie. W praktyce pewnie byłby to jakiś switch albo blok if-else, do wybrania konkretnej. Drugi pomysł nie korzysta z szablonów. Typem wejściowym byłby wskaźnik na voida i dobieranie się do konkretnej struktury z parametrami byłoby zrealizowane za pomocą castowania. class AbstractLevelGeneratingStrategy
{
public:
virtual Level generate( void * params ) = 0;
}
Zastosowanie czegoś takiego pozwoliło by mi na umieszczenie strategii w mapie i mapowanie tego per jakieś id. Problem z modyfikacją klasy obsługującej strategie w sumie zostaje, jednak w tym przypadku mogę wyciągać konkretne w nieco przyjemniejszy sposób. Czy któryś z tych pomysłów wypada dobrze pod kątem designu? Jak wygląda sprawa castowania w górę w kontekście polimorfizmu i dobrych praktyk? |
|
pekfos |
» 2019-11-07 01:23:14 | Czy któryś z tych pomysłów wypada dobrze pod kątem designu? |
Pomysł z szablonem - zły nawet na papierze. Będziesz mieć osobną klasę bazową dla każdego typu parametrów, więc w praktyce pewnie też dla każdej implementacji algorytmu, przez co cały sens klasy bazowej wyparowuje. Wskaźnik na void* to nie jest dobra praktyka. Jaki dokładnie chcesz uzyskać efekt z tego, że będziesz mieć te 'strategie' w mapie? I tak kod wywołujący generowanie będzie musiał mieć osobne przypadki dla każdego rodzaju parametrów (algorytmów). Lepszym rozwiązaniem byłoby przechowywanie parametrów bezpośrednio w klasie i ustawianie ich setami, a nie przekazując PODa. Metoda generate() powinna przyjmować argumenty wspólne dla każdego możliwego sposobu generowania mapy, jak choćby jej rozmiar. | Jak wygląda sprawa castowania w górę w kontekście polimorfizmu i dobrych praktyk? |
Co? |
|
| « 1 » |