Zdravím, Já bych považoval variantu d) za nejlepší a ani mi nepřijde tak strašná. Sice se pak jeden kód používá k dvěma věcem, ale to je IMHO docela slabá námitka - pokud jsou tyto dvě věci poměrně silně svázány (pokud to dobře chápu, jsou ta společná data a společný algoritmus výběru dat) a jejich rozdělení by zhoršilo výkon, tak bych to vůbec neřešil.
Kamil Podlešák 2010/7/19 Oto Buchta <ta...@buchtovi.cz>: > Zdravím, > dostal jsem se do poměrně zapeklité situace a rád bych znal váš názor. > Mám poměrně hodněvrstvou aplikaci (kvůli čitelnosti a spravovatelnosti > a rozšiřitelnosti). > Mám implementovanou poměrně hodně složitou logiku vyhledávání, která > funguje poměrně dobře, > přijímá parametry, které má, vrací struktury, které má, prostě paráda. > Jenomže zničehož nic potřebuji nemlich stejnou funkcionalitu ale s > přidáním drobných statistik. Hodně uvnitř ve střevech potřebuji přidat > count(*), min(*),max (*), avg(*) jako další sloupce SQL selectu za > přidání několika podmínek. Ony hodnoty pro původní nasazení nemají > žádný význam. > Otázka zní: jak z toho ven? > c) rozšířit stávající návratové struktury a přidat parametry a > rozšířit implementaci onoho vyhledávání - pak ale zneužívám kód k > něčemu jinému, předávání více dat, než je nezbytně nutné a hlavně > statistické výpočty jsou volané i tehdy, kdy je volat netřeba - > tisíckrát za sekundu místo 1 x za pět minut. > d) pro omezení zbytečného výpočtu statistik v c) přidat do volání API > boolean (nebo raději int pro více možných stavů) parametr udávající, > zda výpočty volat či nikoli (rozhodování může to být řešeno dědičností > konkrétní datové struktury, ale to je pořád onen boolean či int a s > ním někde svázaný switch či kupa ifů). > Ani jedno se mi nelíbí, ale pěkné řešení mne nenapadá. Jak toto řešíte vy? > -- > Oto 'tapik' Buchta, ta...@buchtovi.cz, http://tapikuv.blogspot.com >
