[ DarkMan @ 22.06.2009. 21:28 ] @
Da li se za IServiceProvider interfejs moze reci da je design pattern?
Ili se moze ubrajati u neki postojeci design pattern? Na primer sa ovog spiska http://en.wikipedia.org/wiki/Software_design_pattern
[ mmix @ 23.06.2009. 09:45 ] @
Interfejs sam po sebi ne moze biti patern, interfejs desinise samo STA, pattern daje i STA i KAKO (sto interfejs ne moze ).

Medjutim, implementacija IServiceProvider interfejsa moze da se odradi kroz jedan ili vise kreacionih paterna, sta vise po definiciji interfejsa deluje mi da se uglavnom odradjuje kroz object pool patern.

[ DarkMan @ 23.06.2009. 10:50 ] @
Da, u pravi su. Nisam bas mislio samo na interfejs vec nacin na koji se on implementira i zasta bi posluzio.
IServiceProvider implementacija u form editoru visual studia jeste napravljen kao object pool pattern (koliko sam video kreiran je ServiceProvider objekat u kojeg se mogu dodavati servisi).
U mom slucaju nisam koristio ovu shemu vec sam cisto implementirao IServiceProvider kroz hijerarhiju parent objekta do njegovih child objekata jer mi je bilo potrebno da child objekat dobije neke informacije iz baznog parent objekta.

Code:

public class BaseParent: IServiceProvider, ISomeService
{
    private ItemCollection items;
    public BaseParent()
    {
        items = new ItemCollection(this);
    }
    public string[] Names { get { ...; } }
    public object GetService(Type serviceType)
    {
        if(serviceType != null && serviceType.IsInstanceOfType(this)) return this;
        return (m_Parent != null ? m_Parent.GetService(serviceType) : null);
    }
}

public interface ISomeService
{
    string[] Names { get; }
}

public class ItemCollection: IServiceProvider
{
    private IServiceProvider m_Parent;
    public IServiceProvider Parent { get { return m_Parent; } set { m_Parent = value; }

    public ItemCollection(IServiceProvider parent)
    {
        m_Parent = parent;
    }
    public void Add(Item item) { ... }

    public object GetService(Type serviceType)
    {
        if(serviceType != null && serviceType.IsInstanceOfType(this)) return this;
        return (m_Parent != null ? m_Parent.GetService(serviceType) : null);
    }
}

public class Item
{
    private IServiceProvider m_Parent;
    public IServiceProvider Parent { get { return m_Parent; } set { m_Parent = value; }
      
      public void ItemMethod()
      {
            ISomeService service = m_Parent.GetService(typeof(ISomeService)) as ISomeService;
            if(service != null) {
                  string[] names = service.Names;
                  ....
            }
      }
}

Gore opisan pristup koristim dosta (u pitanju je dizanjer i ovo mi je jedini nacin da doturim informacije krajnjim objektima koji su potrebni za prikaz dodatnih informacija u PropertyGrid-u).

U ovoj implementaciji, tj. nacinu koriscenja ovog interfejsa, nema object poola. Ovo sam koristio kao nacin za dostavljanje informacija kroz hijerarhiju objekata.
Da li se za ovakav nacin koriscenja IServiceProvider-a moze reci da je u pitanju neki pattern?

Citat:
In software engineering, a design pattern is a general reusable solution to a commonly occurring problem in software design.

Jedan moj problem je bio, na primer, prikazati listu mogucih vrednosti jednog svojstva u property grid-u. IServiceProvider interfejs mi je savrseno odgovarao za resavanje ovog problema.
[ mmix @ 23.06.2009. 11:30 ] @
Nisam siguran da postoji naziv za ovo. U principu sve sto napravis a mozes da iskoristis konceptualno vise od jedanput jeste patern, samo sto nisu svi paterni vredni javnog mnjenja, neki su trivijalni, neki usko specificni, dok su neki siroko primenljivi i efikasni i dospeli su u opstu literaturu i ono sto smatramo "opstom kulturom" jednog programera. Inace, paterna ima sad na stotine i stotine ako ne i hiljade (cak je i deklarisanje varijable sa pocetnom vrednosti neki patern), sreca nasa pa ne mogu da se patentiraju paterni inace bi programiranje ubrzo postalo veoma nerentabilno od silnih trolova