KoopiaKoopiaKoopia ei ole ilus

Kui anekdooti rääkida esimest korda, siis arvatavasti on see naljakas, teisel korral juba on pool võlu kadunud, kolmandat korda kuuldes ei pruugi isegi muie enam näole tulla. Samamoodi on ka tarkavara arenduses – kui kolmandat korda ühte ja sama koodilõiku kirjutada, siis kaob muie näolt ja tuleb mõtlema hakata, kuidas struktuuri parandada. Seda eirates läheb kood hapuks ja anekdoodivestjast koomikut ei saa.

IT juht läheb ülemuse jutule ja ütleb: “Meil oleks vaja uut serverit.” Ülemus seepeale uudishimulikult küsib: “Millist?” IT juht teeb suured silmad ette ja vastab: “Kahe millist.”

Martin Fowler annab hea vihje enda raamatus “Refactoring: Improving the design of existing code”, et kolmas kord kopeerimisel on see hetk, kus tuleks ette võtta ümber struktureerimine (refactoring).

Dubleerimise vältimine on tuntud ka järgneva printsiibina: Don’t Repeat Yourself (DRY).

Enne kui kaotada igasugune koopia ära, tuleb mõelda, et kas see on tõesti vajalik. Mõnikord peabki olema struktuur dubleeritud (peamiselt siis kui sellega midagi öelda tahad). Data Transfer Object‘ite (DTO) korral oleks vale luua ühine baasklass äriobjektiga. Sellisel juhtumil on see äärmiselt väär vähemalt mu jaoks. DTO-del võivad olla jadaks teisendamisega (serialize) seotud atribuute ja äriobjektidel näiteks Object-Relational Mapper (ORM) atribuute (kuigi see ei ole kõige parem variant seoseid andmebaasi ja ärimudeli vahel luua) ning need võiksid olla eraldi. Tihtipeale on DTO objektidel ainult võtmise (getter) meetodid.

IT juht läheb ülemuse jutule ja ütleb: “Meil oleks vaja uut serverit.” Ülemus seepeale uudishimulikult küsib: “Millist?” IT juht teeb suured silmad ette ja vastab: “Kahe millist.”

Teine olukord, mis võib juhtuda dubleeringu eemaldamisel, on ideeliselt sama, mis teemanti probleem (tegelikult võibki taandada sellele). Järgnevalt jooniselt võimegi näha, et ei ole võimalik kaotada dubleeringut täielikult. Me ei saa pärida nii Type kui ka TimePeriod klassist. Siin juhtumil peame ilmselt valima ühe neist, kusjuures arvestada tuleks pigem sellega, et kas State on pigem TimePeriod või Type, mitte vaatama, kus on rohkem võimalik dubleeringut kaotada.

Siiski need probleemid ei tule ette pidevalt, pigem tuleb ette vähene abstraktsus ja dubleering. Sellegi poolest tuleb teadlik olla, millised probleemid võivad ette tulla.

IT juht läheb ülemuse jutule ja ütleb: “Meil oleks vaja uut serverit.” Ülemus seepeale uudishimulikult küsib: “Millist?” IT juht teeb suured silmad ette ja vastab: “Kahe millist.”

Selle printsiibi head küljed avalduvad peamiselt programmi käitumise muutmise korral. Lihtsam on muuta ühes kohas kui mitmes, juhul kui dubleering on eemaldatud loogiliselt. Dubleeringute otsingul Java ja .NET platvormil on abiks Simian, mis teinekord üllatab enda tulemustega. Head dubleeringu otsimist ja eemaldamist!