Modernselt tarkvara loomine II: Seotud paelad

Enne jooksmist tasub paelad kinni siduda, siiani on see hea praktika olnud. Samalaadselt peame rakenduse loomisel objektid omavahel siduma. Nagu saapapaelu saab mitut erinevat moodi siduda, saab ka objekte.

Kõige lihtsam viis on see, et üks objekt loob teise ja kutsub välja meetodi, kuid seal tekkivad tihtipeale hunnik probleeme. Meil pole võimalik testides seotud objekti võimalik välja vahetada ning see viib tavaliselt välja olukorrani, kus ühe testi käivitamiseks peame hulgaliselt seadistama.

public class MakeCustomerPreferredTask
{
    public void Execute(Customer customer)
    {
        var repository = new CustomerRepository();
        //…
        repository.Save(customer);
    }
}

Olukorra parandamiseks võime kasutada Dependency Injection/Inversion of Control printsiipi, mis soovitab kõik seotud objektid kaasa anda. Eelnev näide võiks välja nähe järgmine:

public class MakeCustomerPreferredTask
{
    private readonly CustomerRepository _repository;

    public MakeCustomerPreferredTask(CustomerRepository repository)
    {
        _repository = repository;
    }

    public void Execute(Customer customer)
    {
        //…
        _repository.Save(customer);
    }
}

Olukord on paranenud seoste osas, kuid väga tülikaks on muutunud objektide loomine, mida võib näha järgnevalt koodi lõigust:

var task = new MakeCustomerPreferredTask(new CustomerRepository(UnitOfWork.CurrentSession));

See võib palju pikem olla. Esimene võimalus lihtsustada seda oleks kasutada vaese mehe meetodit, kus luuakse parameetriteta konstruktor ning vastavad seosed määratakse seal.

public MakeCustomerPreferredTask() : this (new CustomerRepository()) { }

Hea praktika on viia seotud objektid liideste peale, kuid seosed konkreetsete objektidega jäävad alles. Võime proovida edasi minna näiteks Factory või ServiceLocator mustriga, mille puhul anname selle konstruktorisse alati kaasa ja objekt küsib tema käest vastavad vajalikud objektid.

public MakeCustomerPreferredTask(IServiceLocator serviceLocator)
{
    _repository = serviceLocator.Resolve<ICustomerRepository>();
}

Jõudsime mõnes mõttes ringiga veidi tagasi – testides peame võltsitud ServiceLocatori ette andma, et vajalikke seoseid isoleerida. Edasiminekuks on vaja teha üks samm tagasi ja üks samm edasi. Lisades ServiceLocatorile juurde ülesande täita kõik vajalikud seosed pääseme natukene kirjavaevast.

Konstruktor jääks selliseks:

public MakeCustomerPreferredTask(CustomerRepository repository)
{
    _repository = repository;
}

Nüüd jääb ülesandeks sisenemispunktile (entry point) lisada kood, mis küsib vajalikud objektid ServiceLocatori kaudu. MVC juures on võimalik Controllerite loomine ümber viia ServiceLocatorile:

public class ControllerFactory : DefaultControllerFactory
{
    protected override IController GetControllerInstance(Type controllerType)
    {
        return (IController) ServiceLocator.Resolve(controllerType);
    }
}

Nii ei pea me suure tõenäosusega rakenduses kuskil ServiceLocatori käest küsima teenuseid, sest kõik vajaminevad objektid antakse Controllerile kaasa.

Selliselt paelu siduda tundub küllaltki lihtne, eriti kui seadistamine on konventsioonide järgi – lihtsalt ütled objektile konstruktoris, mis liidestega objekte tal vaja läheb ja hakka aga kasutama neid. Seevastu tuleb meeles pidada, et see on mõeldud rakenduse teenuste jaoks ning ärimudelis ei ole hea tava seda kasutada.

Lisaks on võimalik selle abiga hallata objektide elutsüklit. Sellest tulenevalt võime unustada Singelton mustri ära.

.NET

.NET-i puhul on see kasutatav praktika ja elu on näidanud, et mingi hetk ilma selleta teha rakendust on kuidagi tülikas. Microsoft panustas ka vastava raamistiku tegemisse ja sündiski Unity. Kahjuks on see jäänud veidi vanamoeliseks ning mõnusamaid lähenemisi leidub StructureMap, Castle Windsor ja Ninject raamistikest.

Java

Kuna Java ja .NET on suhteliselt sarnased, siis kasulik on see ka seal. Praegu tundub, et seadistamist on palju, kuid soovi korral saab seda kõike lihtsustada. Sellel platvormil esindavad järgnevad raamistikud seda mõttemaailma: PicoContainer, Spring Framework

Ruby

Ruby maailmas ei peeta sellest väga lugu, sest väidetavalt ei ole seda vaja. Kuna Ruby-is on võimalik objekte manipuleerida igas suunas, siis tõesti ei pruugi see vajalik olla. Siiski on inimesi, kes arvavad, et see on väärt kasutamist ja on tehtud järgnevad raamistikud: Needle, Copland

PHP

Siingi on olemas erinevaid raamistikke: Symfony DI, Crafty