[es] - Interfaces, Interfaces...

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.eunet.rs.

+171 Profil

^{18.01.2009. u 12:25 - pre 197 meseci}

OK, naslov lici pomalo na onu predstavul Steve Ballmer-a "Developers, Developers..." ali ovo pitanje me vec odavno... hm, ne bi da kazem muci, jel je boljia rec nervira.

Elem,
Radeci na poslu, prvo sto mi je zapalo u oci jos kad sam se prvi put susreo sa projektom je definicija interfejsa za svaku klasu. Nisam nikad ovo mogao da razumem, pokusao sam da shvatim realnu upotrebu ovoga ali mi nije nikako islo u glavu zasto se to radi. OK, neko bi odamh mogao reci "unit testovi", ali prostim sistemom eliminacije se lako dolazi do zakljucka da to nije u pitanju, jer na poslu nikad ja ili neko od mojih kolega nije pravio neke mock klase koje bi nam sluzile za unit testove. Onda zasto, jel u pitanju neki best practise ili sta vec?

Evo jedan link na koji sam naleteo trazeci na google, "interface overuse"
http://stackoverflow.com/quest...-me-or-are-interfaces-overused

I sa ovim likom se 100% slazem, i dalje ne razumem primenu "definisi interfejs pa zatim klasu koja ga implementira", kada 95% tih interfejsa se nikad i ni zasta vise ne koristi osim za jednu implementaciju u klasi.

A evo i sta se kaze MS http://msdn.microsoft.com/en-us/library/dybz98h0(VS.71).aspx

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Interfaces, Interfaces...

^{18.01.2009. u 13:05 - pre 197 meseci}

overkill ako mene pitas i vise smeta nego sto pomaze. Projekti koji funkcionisu ovako tokom verzija pre ili kasnije ili napuste tu metodologiju zbog interface hell-a (dobri stari COM dani) ili jednostavno prekrse jednu od osnovnih postavki interface-a (immutability) i time zamene interface hell sa gomilom runtime typecast gresaka. Svaka klasa je sama po sebi implicit interface i samim tim je dupliranje contract-a bespotrebno a versioning ionako u .NETu kontrolises kroz asembly versioning tako da ti ni za to ne treba. Bas me interesuje koja je racionalizacija ovog pristupa kod tebe u firmi?

Sloba je za 12 godina promenio antropološki kod srpskog naroda. On je od jednog
naroda koji je bio veseo, pomalo površan, od jednog naroda koji je bio znatiželjan, koji
je voleo da vidi, da putuje, da upozna,
od naroda koji je bio kosmopolitski napravio narod koji je namršten, mrzovoljan,
sumnjicav, zaplašen, narod koji se stalno nešto žali, kome je stalno neko kriv - Z.Đinđić

Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
78.30.182.*

+171 Profil

Re: Interfaces, Interfaces...

^{18.01.2009. u 14:11 - pre 197 meseci}

Na zalost koja je svrha ovoga pojma nemam. Znam samo da i kada sam u onim retkim slucajevima dobio da namestim neku klasu kada sam zavrsio dobio sam naredbu da sve, ili bar veci deo funkcionalnosti klase, napisem isto to kao definiciju interfjesa, pa naknadno da implementiram taj interfejs u klasi.

Recimo

Code:

public interface IGasovod
{
   bool ImaGasa { get; }
   void PustiGas();
   void ZavrniGas();
}

public class Gasovod : IGasovod
{
     bool _imaGassa;
     public bool ImaGasa
     {
         return _imaGasa;
     }

      public void PustiGas()
      {
          _imaGasa = true;
      }

      public void ZavrniGas()
      {
          _imaGasa = false;
      }
}

iako se IGasovod nece nigde vise implementirati, nigde vise ni koristiti, ovo mora da se uradi. U kodu se posle svuda koristi interfejs, recimo u metodama se prosledjuje IGasovod, sto jos u neku ruku deluje i logicno, posle moze da se zameni lako sa nekom drugom implementacijom, ali problem koji ja ovde vidim je - sto u 95% slucajeva to je jedna klasa i nikad se vise nece koristiti taj interfejs da bi se pravila nova implementacija, jednostavno mislim da neko ovde previse planira, valjda se ide u fazonu "Mozda ce trebati neka druga implementacija" a kazem da ja nisam nikad video realnu potrebu za ovim vise sam za pristup YAGNI metoda nego za ovo unapred planiranje koje u 95% slucajeva se pokazuje kao netacno. I da, mislim da je veoma bitno za napomenuti u pitanju je closed API, sto ovu pricu cini jos besmislenijom.

Mislim, neka se neko javi sa argumentima sto je ovo potrebno, jer ja licno vidim samo problem u radu, aj' kada je mali projekat pa da progutam ali sa velikim projektima ovo dupliranje i debugiranje ubija.

Odgovor na temu

PetarSrdanovic
Beograd

Član broj: 106322
Poruke: 16
*.adsl.verat.net.

+5 Profil

Re: Interfaces, Interfaces...

^{18.01.2009. u 22:01 - pre 197 meseci}

Ja bih u dosadasnjoj karijeri (12 godina) bez interfejsa poginuo :)
Evo objasnicu ti na primeru koji trenutno koristimo. Aplikacija na kojoj radim moze da podrzava razlicite baze. Trenutno su u igri SQL Server, Postgree i Oracle. Sve one 'pricaju' pomocu SQL-a, ali to nije dovoljno. Mnoge akcije u tim bazama su specificne, na primer unos velikih kolicina podataka, takozvani 'Bulk Insert'. On je na svakoj bazi drugacije implementiran (kao i stosta drugo, backup, replikacija....). Jedan pristup je da imas ovako

Code:

private vodi BulkInsert()
{
            switch (tipBaze)
            {
                case "Oracle":
                    ....
                case "SQL":
                    ....
                case "Postgree":
                    ....
            }
}

Ali sta se desava, sutradan korisnik hoce mySQL. Ti sad trebas da prodjes svuda kod i dodas stavku. Veruj mi na rec - smrt u diskoteci. NEMOJ TAKO DA RADIS.

Drugo resenje je interface. Definises interface koji nabroji sve metode koje tvoj database manager (nazovimo ga tako) treba da ispuni. Zatim napravis konkretnu implementaciju managera za Oracle, SQL.... Svaka je u svom dll-u. Korisniku isporucujes samo njegov dll. U glavnoj aplikaciji ucitavas taj dll i izvuces managera i dalje radis sa njim.

Prvi dll sadrzi interface

Code:

    public interface IDatabaseManager
    {
        void BulkInsert();
    }

Zatim imas dll sa konkretnom implementacijom

Code:

    public class OracleDatabaseManager : IDatabaseManager
    {
        public void BulkInsert()
        {
            //neki kod
        }
    }

I na kraju u glavnoj aplikaciji imas upotrebu NEPOZNATOG database managera, pomocu interface-a

Code:

        IDatabaseManager myManager = null;

        private void Init()
        {
            //Inicijalizacija ima dva nacina, losiji, jer navodimo ime objekta,
            //ali se zamena kasnije svodi na jednu liniju.
            myManager = new OracleDatabaseManager();

            //ili preko refleksije - to je ono pravo, nema nikakve izmene koda kad posaljes drugi database manager dll
            Assembly asm = Assembly.LoadFile("C:\\DatabaseProvider.dll"); //load assembly po pathu
            Type[] typeArray = asm.GetExportedTypes();
            foreach (Type type in typeArray)
            {
                try
                {
                    //list of attributes
                    //Create command via reflection
                    IDatabaseManager manager = type.Assembly.CreateInstance(type.FullName)
                                            as IDatabaseManager;         //resource data
                    if (manager != null )                    //only RTR reports
                    {
                        myManager = manager;
                        return;
                    }
                }
                catch { }
            }
        }

        //poziv iz glavne aplikacije bulk inserta
        private void ExecBulkInsert()
        {
            //samo jedna linija
            myManager.BulkInsert();
        }

Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
78.30.182.*

+171 Profil

Re: Interfaces, Interfaces...

^{18.01.2009. u 22:18 - pre 197 meseci}

Da to jeste normalna, pozeljna i dobra upotreba interfejsa ali sem imena "interfejs" tvoj odgovor nema nikakve veze sa mojim pitanjem

_{[Ovu poruku je menjao negyxo dana 19.01.2009. u 00:41 GMT+1]}

Odgovor na temu

Radovan__III
Radovan__III
Beograd

Član broj: 15669
Poruke: 1245
77.46.222.*

+26 Profil

Re: Interfaces, Interfaces...

^{18.01.2009. u 23:28 - pre 197 meseci}

Citat:

negyxo:
iako se IGasovod nece nigde vise implementirati, nigde vise ni koristiti, ovo mora da se uradi. U kodu se posle svuda koristi interfejs, recimo u metodama se prosledjuje IGasovod, sto jos u neku ruku deluje i logicno, posle moze da se zameni lako sa nekom drugom implementacijom, ali problem koji ja ovde vidim je - sto u 95% slucajeva to je jedna klasa i nikad se vise nece koristiti taj interfejs da bi se pravila nova implementacija, jednostavno mislim da neko ovde previse planira, valjda se ide u fazonu "Mozda ce trebati neka druga implementacija" a kazem da ja nisam nikad video realnu potrebu za ovim vise sam za pristup YAGNI metoda nego za ovo unapred planiranje koje u 95% slucajeva se pokazuje kao netacno. I da, mislim da je veoma bitno za napomenuti u pitanju je closed API, sto ovu pricu cini jos besmislenijom.

Donekle se slazem, interfejse ti nemas potrebe koristiti cak je i suvisno ako unapred znas sve elemente projekta i znas da kada zavrsis nikad vise nece nista menjati niti nadogradjivati.
Problem nastaje ako ti na pocetku nisi siguran sta ce sve imati projekat, da li ces ga nadogradjivati kasnije, da li ces raditi paralelno sa drugim ljudima na projektu ili ce neki drugi ljudi nastavljati tvoj posao. U svim ovim slucajevima interfejs "is a must".
Direktno na tvom primeru dolazi do greske u onih 5 posto koje ces platiti ogromnim utorskom vremena jer nisi implementirao interfejs i dalje ga koristio ( neki misle da je dovoljno samo ga implementirati ... )

Na polimorfizam se mora gledati kao na znacajno olaksavajucu okolnost i kao na sistem koji ce ti omoguciti komunikaciju i sigurnost posto definisanjem interfejsa ti definises i parametre unosa i izlaza.

Problem sa pisanjem se sigurno moze resiti sa nekim pluginom za generisanje interfejsa na osnovu klase koju prvo definises ( mislim da ima za eclips , verovatno ima i za vs )

Takodje pogledaj i design patterns i docices do zakljucka da nema ozbiljnog projekta bez interfejsa

Aj sad svi u biblioteku da nesto pojedemo i popijemo ...
--------------------------------
Knjigovodstvo

Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
78.30.182.*

+171 Profil

Re: Interfaces, Interfaces...

^{18.01.2009. u 23:50 - pre 197 meseci}

Apsolutno se ne slazem sa ovim:

Citat:

Problem nastaje ako ti na pocetku nisi siguran sta ce sve imati projekat, da li ces ga nadogradjivati kasnije, da li ces raditi paralelno sa drugim ljudima na projektu ili ce neki drugi ljudi nastavljati tvoj posao. U svim ovim slucajevima interfejs "is a must".

Da napomenem, nije problem da li u onih 5% treba da se koristite interfejsi nego je problem kao pravilo prihvatiti zato sto se ne zna nesto kakav ce projekat biti prihvatiti tu ideju da se koristi u 90% slucajeva definicija interfejsa koji ce sluziti da se implementiraju samo u jednoj klasi. Licno, mislim da bi svako trebao da batali programiranje ako misli da ce resavati probleme tako sto ce nauciti par design pattern-a i onda raditi copy-paste, umesto da pogleda konkretan problem i onda da u skladu sa problemom implementira odredjene design pattern-e.

Odgovor na temu

PetarSrdanovic
Beograd

Član broj: 106322
Poruke: 16
*.adsl.verat.net.

+5 Profil

Re: Interfaces, Interfaces...

^{18.01.2009. u 23:57 - pre 197 meseci}

Citat:

negyxo: Da to jeste normalna, pozeljna i dobra upotreba interfejsa ali sem imena "interfejs" tvoj odgovor nema nikakve veze sa mojim pitanjem ;)

A onaj deo: "Mozda ce trebati neka druga implementacija"?
Inace izvini sto sam ista pisao, necu vise....

Odgovor na temu

negyxo
Aleksandar Perkuchin

Član broj: 29751
Poruke: 898
*.eunet.rs.

+171 Profil

Re: Interfaces, Interfaces...

^{19.01.2009. u 07:19 - pre 197 meseci}

Izvini ako ti je moj odgovor deluje uvredljiv, ali ovo moram da prokomentarisem.

Napisao si odgovor, ja pogledao, brzo sam uvideo da nije to ono sto sam ja pitao i onda sam ti skrenuo paznju da to nije moje pitanje i ti se ljutis?

Sto se tice onog dela sto si citirao "Mozda ce trebati neka druga implementacija" - to se odnosi moje zapaznje kao jedno od mogucih razloga zasto bi neko uvodio interfejs za svaku klasu, ne i upotreba interfejsa u programiranju o cemu si ti pisao.

Odgovor na temu

mmix
Miljan Mitrović
Chief Software Architect
Financial Intelligence Software Ltd.
Passau, Deutschland

SuperModerator
Član broj: 17944
Poruke: 6050

+4631 Profil

Re: Interfaces, Interfaces...

^{19.01.2009. u 12:13 - pre 197 meseci}

U .NETu klasa je implicitni interface i polimorfni subclassing je ekvivalentan ispunjavanju base contracta nasledjene klase. Sto u prevodu Petre znaci da si ti taj Factory+Bridge pattern komotno mogao da implementiras kroz subclassing, primer sam po sebi ne opravdava interfejse jer nema decoupling-a. Tako npr radi .NET za data klase (SqlCommand, OleDbCommand, OdbcCommand, MySQLCommand, itd svi nasledjuju od DBCommand base klase i abstrakcija se radi kroz base klasu umesto kroz interface). Pride mozes da ustedis na kodiranju za one aspekte implementacija koje su svima zajednicke (a koje pri koriscenju interfejsa moras da ubacis u svaku implementaciju pojedinacno).

Posto je klasa implicitni interface veoma je lako u slucaju preke potrebe izvuci punokrvni interface contract iz iste koriscenjem bilo kog od refactoring alata ukljucujuci i VS Team System, tako da ni pitanje ko ce sta kad i kako da menja u projektu takodje nema veze sa interfejsima niti preventivno implementiranje istih doprinosi brzim i boljim promenama.

U .NET-u Interfejsi ti trebaju za:

- decoupling klase i njenog implicitnog interfejsa posto su oni po defaultu nerazdvojivi (gde ide definicija klase ide i njen kod). Npr kad u remotingu hoces da klijent nema implementacione detalje serverskog koda, onda se remoting radi preko interfejsa i klijent zna samo interfejs a server ima njegovu implementaciju
- kad jedna klasa treba da ispuni dva ili vise contract-a (npr List<T> implementira IList<T>, ICollection<T>, IEnumerable<T>, IList, ICollection, IEnumerable) jer subclassing alternativa ne postoji (nema multiple inheritance)
- kad jedan contract treba da bude implementiran u vise klasa a subclassing nije podoban (npr ICloneable i IDisposable)

Ova lista je u principu drugacije srocena lista sa onog MSDN linka koji je negyxo okacio. Za sve ostalo postoji bolje resenje od primene interfejsa, ako neko misli da gresim nek da primer.

Odgovor na temu