• yazilim camilasinda one cikan bazi sahislar da dahil birtakim kendini bilmezler bunun bir anti pattern oldugunu iddia eder. ota boka anti pattern demek yerine, bircok pattern gibi bunu da adam gibi anlayip, faydali ve faydasiz oldugu senaryolari ayirt etmeniz kendi yarariniza olacaktir.

    http://stackoverflow.com/…rvicelocator-anti-pattern
  • service locator bana göre de ciddi bir tasarım hatasına sahip ve bu yüzden anti pattern denmeyi hakediyor. hakkındaki çok detaylı bir problem analizi google tech talk'larda mevcut, 8:45'ten itibaren başlıyor.

    https://www.youtube.com/…flcwkxhj0&feature=youtu.be

    özet geç piç diyenler için:
    locator ile bize getirilen servis development sırasında bizler için bir kapalı kutu ve locator'ın hangi dependency'leri kullanarak bu servisi ürettiğini bilemiyoruz. geleni kullanmak zorundayız. oysa dependency injection ile yaratılmış bir servisin constructor'ında tüm dependency'ler listelenmiş oluyor. bu noktada servisin nelere coupled olduğunu biliyoruz ve büyük bir avantaj. unit testing için hayat kurtarıcı.

    ilave olarak aslında service locator'dan üretilmesi gereken bir servisi kodun bir yerlerinde tutup new ile çağırdığımızda patır kütür çöküyor. nedenini bilemiyoruz bile. dependency injection kullansaydık bu olmayacaktı çünkü constructor aşamasında bize inject edilecek interface'leri soracaktı.

    sonuç olarak service locator inversion of control için atılmış bir adım ve küçük boyutlu işlerde düzgün çalışabilir. ama projenin çapı büyüdükçe, servis sayısı arttıkça ve bu servisler birbirlerinin arayüzleri ile etkileşime geçtikçe bug ihtimalini hayvan gibi arttırdığı için yaygın olarak antipattern olarak anılıyor.
  • singleton ne kadar pattern ise bu da o kadar patterndır. bu sebepten sakin ola ki antipattern olmadığını iddia etmeyin yazılım mimari sizi klavyeyle kovalar.

    service locator kullanan bir sınıfın yeni bir instance yaratmaya çalışma perspektifinden düşünün. dependency injection yapilan bir yerde, her şey constructorda belirtilir. service locatorda ise, tüm dependencyleri bulmak için instance'ı yaratılmış tüm sınıfı okumak gerekiyor. sadece çağrılan method'un açıklamasını okumak için bile kullandığı concrete implementation'a gitmeniz hatta uyguladığı interface'e kadar gitmeniz gerekiyor.

    çok kısa ozetlemek gerekirse service locator singleton'ın arraylere dağılmış halidir.

    bu kadar yazdım bir de ornek service locator nasıl yapılıyor onu yazayım. ekşide fazladan boşluklar trim edildiği icin kodu incelerseniz gozunuz kanayabilir. benden uyarması.

    class servicelocator {
    constructor() {
    this.services = {};
    }

    register(name, service) {
    this.services[name] = service;
    }

    getservice(name) {
    return this.services[name];
    }
    }

    class loggingservice {
    log(message) {
    console.log(message);
    }
    }

    class authenticationservice {
    authenticate(username, password) {
    // ...
    }
    }

    const locator = new servicelocator();

    locator.register('logging', new loggingservice());
    locator.register('authentication', new authenticationservice());

    const loggingservice = locator.getservice('logging');
    const authservice = locator.getservice('authentication');

    loggingservice.log('this is a log message');
    authservice.authenticate('username', 'password');
hesabın var mı? giriş yap