2012-02-09 17 views
5

Moim pracodawcą jest to, że stosujemy listy inicjacyjne w konstruktorze, ponieważ jest to bardziej efektywne.Wada dużej listy inicjalizacji?

Jednak rozwijam klasę, która ma 45 elementów danych wymagających inicjalizacji. Zgodnie z polityką, należy to zrobić na liście inicjalizacyjnej w konstruktorze.

Czy oprócz czytelności, jaka byłaby wada dużej listy inicjalizacyjnej?

+1

Inne niż czytelność? Nie mogę myśleć o niczym, poza potencjałem błędu. –

+7

Wskazówka: Jeśli masz 45 atrybutów członków, możesz nie dzielić obowiązków odpowiednio. –

Odpowiedz

8

Można sformatować listę inicjatora elementu na wielu fizycznych liniach źródłowych, więc nie musi występować problem z czytelnością.

Większym problemem jest oczywiście fakt, że masz zajęcia z 45 członkami danych. Nic nie ułatwi pracy z takimi klasami.


AClass::AClass(type1 val1 
       , type2 val2 
       // ... 
       , type45 val45) 
: mem1(val1) 
, mem2(val2) 
// ... 
, mem45(val45) 
{ 
} 

Uważam ma mniej czytelny niż:

AClass::AClass(type1 val1 
       , type2 val2 
       // ... 
       , type45 val45) 
{ 
    mem1 = val1; 
    mem2 = val2; 
    // ... 
    mem45 = val45; 
} 
8

myślę, że może warto byłoby zrobienie kroku wstecz, aby zrozumieć, dlaczego klasa liczy 45 członków danych. Zazwyczaj jest to znak, że twoja klasa robi zbyt wiele rzeczy i ma zbyt wiele oddzielnych obowiązków, które z czasem sprawią, że ta klasa będzie bardzo trudna do utrzymania.

Wygląda na to, że może zajść potrzeba podzielenia klasy na osobne elementy funkcjonalne i delegowania klasy "kontroler" do podklas. To dramatycznie zmniejszy złożoność twojego kodu.

-1

Niektóre optymalizacje zawiodą, podejrzewam, że wbudowanie takiego konstruktora nie zadziała.

Tak czy inaczej: 45 Członkowie danych brzmią bardzo często. Czy możesz je pogrupować w tak zagregowane obiekty?

+1

dlaczego nie zawiodą z listą inicjalizacyjną, a nie bez listy inicjalizacyjnej (gdzie skopiowałbyś te inicjalizacje do treści)? – KillianDS

3

Wygląda na to, że znany jest anty-wzór Obiekt Boga. Wiki cytat:

In object-oriented programming, a God object is an object that knows too much or does too much.

Proszę znaleźć sposób, aby ponownie rozważyć swój projekt do członków grupy obiektu Boga w mniejszych struktur i obiektów z ich własnymi procedurami inicjalizacji.

Więc odpowiedź na pytanie „co byłoby niekorzystne dla dużej listy inicjalizacji? (Porównując do małego jednego)” może być „Jest duży, więc być może jest to zły styl.

Odpowiedź na pytanie "jaka byłaby wada dużej listy inicjującej (w porównaniu z dużym ciałem konstruktora)" mogłaby być "żadna", ponieważ inicjalizacja lepiej wykonać na liście, a nie w treści, ale czytelność i koszt utrzymania to samo (jak dla mnie).

+1

Która część odpowiedzi na pytanie o wady dużych list inicjujących? –

+0

Część, która mówi: "jeśli masz duże listy inicjalizacyjne, wtedy * to * jest problemem." –

Powiązane problemy