Czy jeśli w swoim programie chcę mieć pracowników, którzy będą przechowywani w liście, to trzeba zrobić klasę ListaPracowników oraz klasę ListaDwukierunkowa, czy tylko ListaPracowników? Albo jeśli chcę mieć słownik zaimplementowany na drzewie, to lepiej zrobić dwie klasy Słownik i Drzewo (drzewo jako składowa, wywoływanie metod drzewa i podobnych metodach słownika, czyli np. drzewo->dodajWęzeł wywoływane w metodzie Słownika dodajSłowo) czy tylko Słownik?
0
0
Nie rob klas lista i slownik, zrob klase pracownik i korzystaj z stdliba.
0
Ale mi chodzi o samą ideę...
0
Nie robi sie klas ListaPracownikow, ListaUczniow, ListaDozorcow, ListaMalp, bo nie ma absolutnie zadnej potrzeby. Po to ktos wymyslil typy generyczne, zeby mozna bylo stworzyc jedna klase Lista<T> i jej uzywac do kazdego rodzaju obiektow. Tak samo z kazda inna kolekcja. Robi sie tylko klasy, ktore faktycznie cos reprezentuja, typu Czlowiek
0
A jak ze słownikiem? No bo jednak słownik coś reprezentuje, czy się mylę?
0
Co niby reprezentuje? Pewna klase D, z tablica typu V, indeksowana kluczami K. Widzisz tu gdzies cos konkretnego?
1
Akurat bardzo często tworzenie konkretnych klas kolekcji ma sens, bo niosą one ze sobą znaczenie biznesowe. Np. lepiej mieć klasę Magazyn niż List<Produkt> albo Dziennik niż Dictionary<int, List<int>>.
0
Zgadzam się tu z @somekind. Co prawda jeśli taka klasa ma w sobie tylko tą listę i interfejs listy i jedyne co robi to deleguje wywołania, to trzeba się zastanowić. Ale jeśli ma własny interfejs biznesowy to wtedy warto. Zresztą w ogóle należy unikać prymitywów i standardowych klas w kodzie jak ognia.
Bo dużo wygodniej miec gdzieś Map<Adres, Magazyn> niż Map<String, Map<String, Pair<String, Integer>>> ;)
1
Ja tam czasami robie
typedef std::list<Uczen> ListaUczniow;
Przekazywanie ListaUczniow zamiast std::list<Uczen> pozwala też na bezbolesną zmianę kontenera w miejscach gdzie są one tylko przekazywane. A dzięki "wielkiej unifikacji" w STL część operacji nie musi być zmienianych przy zmianie kontenera.
Chociaż najlepiej to kontenery ukrywać jeśli można, dzięki czemu nie ma bólu jak trzeba je zmienić ze względu na nowe wymagania.
Np.
class Szkola {
public:
void dodajUcznia(const Uczen &uczen) {
m_uczniowie.push_back(uczen);
}
private:
std::list<Uczen> m_uczniowie;
}
0
Magazyn niż List<Produkt>
Jesli Magazyn nie wprowadza zadnych dodatkowych metod, to nie, tworzenie klasy jest bezsensowne.
0
n0name_l napisał(a):
Jesli Magazyn nie wprowadza zadnych dodatkowych metod, to nie, tworzenie klasy jest bezsensowne.
Generalnie powinien mieć dodatkowe metody, w końcu jest jakąś encją biznesową, więc powinno być np. Magazyn.DodajProdukt zamiast operowania na metodach kolekcji.
Ale nawet jeśli dodatkowych metod ma nie być, to i tak nieraz warto mieć klasę, choćby dlatego, że możemy zenkapsulować kolekcję i łatwo ją zmienić w razie potrzeby, tak jak wspomniał @vpiotr wyżej.