Zgodnie z zasadą nr 4 Object Calisthenics autorstwa Jeffa Baya (RTF) w The ThoughtWorks Anthology zaleca się, aby „ używać kolekcji pierwszej klasy ”.
Zasada 4: Kolekcje pierwszej klasy
Stosowanie tej reguły jest proste: każda klasa zawierająca kolekcję nie powinna zawierać innych zmiennych składowych. Każda kolekcja jest pakowana we własną klasę, więc teraz zachowania związane z kolekcją mają swój dom. Może się okazać, że filtry staną się częścią tej nowej klasy. Twoja nowa klasa może również obsługiwać działania, takie jak łączenie dwóch grup razem lub stosowanie reguły do każdego elementu grupy.
Zrozumiałem z tego, że powinniśmy użyć osobnej klasy, która podsumowuje kolekcję i metodami dodawania, usuwania modyfikowania danych tej kolekcji.
i potrzebujemy tego, abyśmy byli pewni, jaki typ danych trafi do kolekcji i co wyjdzie.
Czy w przypadku korzystania z kolekcji ogólnej (w językach, w których ma to zastosowanie), musimy przestrzegać tej zasady?
Jeśli brakuje mi istotnego znaczenia, proszę wyjaśnić.
źródło
Odpowiedzi:
Bezpieczeństwo typu to bardzo niewielki powód do korzystania z kolekcji pierwszej klasy. Z Twojego linku:
Chodzi o to, że jeśli szukasz, filtrujesz, sprawdzasz poprawność lub cokolwiek poza dodawaniem / usuwaniem / iterowaniem semantyki w kolekcji, kod prosi o umieszczenie jej w swojej klasie. Jeśli musisz zaktualizować tylko jedną wartość (po wyszukiwaniu), prawdopodobnie trafia ona do klasy kolekcji.
Przyczyna tego jest dość prosta, kolekcje są zwykle przekazywane. Wkrótce 4 różne klasy mają własne
SearchByID()metody. Lub otrzymujesz zwracane wartości, takie jakMap<Integer, String>w przypadku kontekstu zawartości przechowywanej na tej mapie. Kolekcja pierwszej klasy to proste rozwiązanie, które kosztuje pojedynczy plik źródłowy. W praktyce, gdy już zostaną wprowadzone (bardzo łatwo jest też napisać testy jednostkowe), każda zmiana dotycząca kolekcji jest łatwa do opanowania, na przykład kiedySearchByIDtrzeba wziąć GUID zamiast int.źródło
To nie tylko gwarantuje typ obiektów przechowywanych w kolekcjach, ale także gwarantuje niezmienniki kolekcji.
Drzewa (czerwono-czarne, AVL itp.) Są wrażliwe na porządkowanie, a ich zachowanie zależy od ponownego zrównoważenia, gdy jest to właściwe. Wydajność tabeli mieszania będzie również zależeć od odpowiedniego ponownego mieszania. Czy chcesz pamiętać, aby sprawdzać współczynnik obciążenia za każdym razem, gdy wstawiasz mapę haszowania?
FWIW, tekst jest dość jasny na ten temat (i przeredaguję wszystko do twojego pytania, więc nikt inny nie musi pobierać tego RTF):
Nie ma nic wspólnego z typami (a więc i rodzajami), wszystko, co wiąże się z powiązaniem zachowania kolekcji z jej danymi.
źródło
Prosta odpowiedź brzmi „Nie”, jeśli używasz języka, który obsługuje Generics. Ponieważ nie ma potrzeby sprawdzania typu, ponieważ sama funkcja języka robi w tym całkiem niezłą robotę (z mojego doświadczenia w języku Java).
Ale jeśli masz dowolną sytuację, w której chcesz dostosować strukturę danych podaną z języka, możesz utworzyć klasę opakowania wokół oryginalnej struktury danych i ujawnić własne interfejsy API i nadal korzystać z podstawowej implementacji oryginalnej struktury danych.
źródło