2010-10-08 14 views
10

Używam interfejsów/abstrakcyjnych klas podstawowych dla większości moich typów i nieczęsto dziedziczę z klas konkretnych, ale ostatnio natknąłem się na sytuację, w której pożądane jest dziedziczenie lub kompozycja. Byłem świadom programu "powiedzenie" interfejsowi, a nie jego implementacja, ale ostatnio postanowiłem głębiej się zagłębić.Czy dziedziczenie konkretnych klas jest złe?

Widziałem argumentów againstinheritance, i widziałem licznik arguments ale jestem ciekaw, co inni opiekunowie dużych baz kodu faktycznie w prawdziwym życiu. Czy strach jest przesadzony? Czy odziedziczysz po konkretnych klasach, czy też sceptycy dziedziczenia mają rację? Jestem szczególnie zainteresowany kontaktem z osobami pracującymi w C++.

+1

Więcej informacji mogłoby pomóc. To granica nie jest prawdziwym pytaniem. – Potatoswatter

+0

Nie, to nie jest złe. Po prostu często nie jest to właściwe. Bez większej ilości szczegółów trudno jest ocenić twoją sprawę. – jcoder

+0

Dziedziczenie jest narzędziem, nie jest z natury dobre ani złe - zależy od tego, w jaki sposób jest używany. –

Odpowiedz

11

nie facet C++ (doświadczenie zawodowe z dużych systemów korporacyjnych w języku C#, Java, Ruby), ale tutaj jest moje 2 centy jakikolwiek

To nie jest czarno-biały sprawa.

Problem z dziedziczeniem polega na tym, że wprowadza ścisłe sprzężenie. Co gorsza, to sprzężenie zwykle znajduje się w stanie zamkniętym. Zmiany w super-klasach mogą powodować falowanie w dół hierarchii dziedziczenia, tworząc subtelne i trudne do przewidzenia błędy.

Segregacja interfejsu całkowicie omija te problemy, ponieważ nie narusza hermetyzacji w ten sam sposób.

Dobrą rzeczą w dziedziczeniu jest to, że czasami masz model obiektowy, który naprawdę jest tym samym, z bardzo małą zmianą lub dodatkiem. Dopóki zmiana ta jest bardzo wyraźna, nie ma szerszego zakresu i nie jest dodatkowym ograniczeniem (patrz problem circle-ellipse), ponowne użycie kodu spowoduje przejęcie ciasnego sprzężenia.

Trzymam się składu na zasadzie dziedziczenia jako reguły kciuka, a nie prawa.

+0

Oh hej. Po prostu heads-up, twój awatar jest taki sam jak Mike Stone'a. Właściwie to go o to zapytałem, a on powiedział mi, że sam zrobił awatara, krok po klatce przechodząc przez konkretny epizod i ręcznie edytując tło. Nie sądzę, żeby docenił ludzi, którzy zgrywają jego awatara. :-( –

+0

@Chris: Oh crap.Naprawdę wyrwałem go z awatara MSN dla kumpli (który nie jest kamieniem od mike'a i, jak na ironię, nie miał problemu ze mną, używając go), doszedł do wniosku, że dostał go z wyszukiwarki Google. Zmienię to jak najszybciej. –

+1

@Chris: dostał narybku, który wyrzuciłby swojego skutera z jakiejś przypadkowej strony z awatarem, powinien zmienić się, gdy SO wygaśnie ich pamięć podręczną. Jakie są szanse, że coś, co dostaniesz za pomocą usługi MSN, okaże się miłością spreparowanym produktem prawdziwego aktywnego użytkownika forum, na którym działasz? –

4

Możesz prywatnie czerpać z konkretnych klas. Prywatne dziedziczenie nie wymaga zastępowalności Liskov; jest to po prostu wygodny sposób na "mieszanie" funkcjonalności klasy.

Z kolei dziedziczenie publiczne wymaga substytucyjności Liskov. Zwykle publiczne dziedziczenie z konkretnych klas jest złe, o ile taka klasa nie jest zaprojektowana do użycia jako klasa podstawowa (wiele z nich nie jest).

+0

Wiele z tych, które nie zostały zaprojektowane, może być również trochę przeprojektowane/udoskonalone, aby je wspierać. – Potatoswatter

2

Dobry projekt zakłada, że ​​konkretne klasy powinny wykonywać jedną, względnie małą rzecz dobrze i sprawnie. Zwłaszcza w C++ klasy betonu podkreślają ich podobieństwo do typów betonu takich jak int i char, często przez przeciążanie operatora i posiadające tylko funkcje inne niż wirtualne. Ponieważ konkretne klasy nie mają na celu zachowania polimorficznego, nie powinny być dziedziczone. Więcej informacji na temat prawidłowego stosowania konkretnych typów w tym języku można znaleźć w sekcji 25.2 pod numerem The C++ Programming Language.

Powiązane problemy