...
S tim vsim souhlasim, moc pekne napsano...
...
Chtel bych ale k tomuto poznamenat, ze osobne mam opacny nazor. Samozrejme neni vhodne vsechno dogmaticky odmitat, nebo prijimat a jsou ruzne situace, kdy se hodi i jine reseni(napriklad kvuli rychlosti), nicmene:
(Pozn: Toto je muj nazor, neminim vam ho tady nutit.)
Ve vetsine pripadu, pokud jsi se rozhodl pouzivat v programu vyjimky, je vhodne je vyhazovat hned pri konstrukci, pokud zjistis, ze vstupni data jsou nekonzistentni, nebo proste neodpovidaji pravidlum(pokud neni konstruktor privatni, tak idealne v nem, pripadne v nejake factory metode). Nadrazene funkce maji pak moznost rychle a precizne reagovat na vzniklou chybu. Do budoucna je toto mnohem lepe udrzovatelne(Vsechny API by mely byt co nejprimocarejsi a nejintuitivneji pouzitelne - pokud musis po konstrukci objektu explicitne validovat stav uz zkonstruovaneho objektu, tak to neni intuitivni. Mnohem lepsi je vubec nedovolit zkonstruovat nevalidni objekt.)
Co je ovsem dulezite je, ze validace i vypocty se musi vztahovat opravdu k dane tride. V konstruktoru samozrejme nevolat(nekde to lze, byvaji z toho logicky velke problemy, kdyz potomek jeste neni inicializovany) virtualni metody. Tj. je treba si uvedomit co vlastne konstruujete a validovat/pocitat presne pouze to, co dana trida predstavuje. Validovat/dopocitavat prvky, ktere jsou az kontrakt potomka, je treba delat az v nem a hlavne je treba nepredpokladat, co bude potomek potrebovat validovat/dopocitavat, protoze zasadne vzdy neco opomenete anebo naopak nastavite prilis striktni podminky. Silne dodrzovani tohoto (tak nejak za rucicku) prirozene vede i k lepsimu navrhu - muze to byt takova pomocna berlicka, ze ktere vypadne lepsi hierarchie trid, vcetne abstraktnich trid, atd...