Hej.. Några särskilda rekommendationer och resonemang kring val av bok / andra källor som behandlar interfaces mer djuplodande? Den bok jag använder (och många bloggar/artiklar på nätet) senare lider de flesta av att vara lite för tunna. Dvs man förstår inte riktigt poängen med att "krångla till det" när det är så tunna exempel..

Med hälsning
Jonas

Detta blev inget vidare gott intryck av mitt allra första inlägg i detta forum.. :-p

Jag har inte läst någon bok, men.. Kortfattat så:

Låt oss säga att du vill skapa ett api som någon kommer använda. Om du exponerar publikt som just interface, och låter själva klasserna vara privata, så ger du dig fritt spelrum att göra vad du vill bakom kulisserna sålänge du inte rör interfacen. Du skulle rent av kunna hiva hela ditt api, sånär som på interfacen, och ingen som använder ditt api skulle märka att du använder helt andra klasser.

En annan sak som är bra med interface: en funktion/api/någonting annat förväntar sig att få ett objekt av en viss datatyp. Istället för att säga att den endast accepterar objekt som ärvt ifrån en viss basklass så kan den förvänta sig objekt som implementerar ett visst interface. Det gör att vilken klass som helst, som implementerar det aktuella interfacet, är giltigt att skicka in. Det gör i sin tur att man kan ha en helt annan basklass och ändå uppfylla kraven för funktionen/api:t.

Ett exempel på smart användning av interface hittar du i ramverket:

System.IComparable

Det är ett bra exempel på användning i det senare fallet. Säg att du vill jämföra två stycken strängar. Du behöver inte veta hur man jämför just strängar, det räcker med att du vet att de implementerar interfacet IComparable då det interfacet har en funktion för att just jämföra sig själv med ett annat objekt. Du behöver med andra ord inte veta att det ens är strängar du jämför! :)

Tja

Tack för hjälpen. Jag har någorlunda bra koll på syftet och ändamålet med interfaces. Det är lite värre med ett antal exempel och förekomster där man borde ha använt det samt på vilket sätt det skulle ha sats upp ifrån början. När man inte känner sig säker blir det lätt att det byggs på "sedvanligt sätt" sedan tänker man i nya banorna å då är ju jobbet i princip klart och man har inte tid eller lust att göra om på nytt sätt.. osv.. :).

Praktiska användningsområden..
Ja.. hur skulle en interface se ut som bakar in en smptklients alla anrop? hur skulle en interface se ut som bygger upp en sendmail? Hur skulle ett interface se ut för att lägga ihop en samlingsplats med data för en användare, men från olika håll och enkelt att byta ut källorna beroende på situationerna.,

Det är möjligt att man kan komma en bit på en sådan här diskussion..

Tja, det behöver ju inte vara mer komplicerat än att interfacet borde innehålla de metoder man anropar i klassen. Och metoderna borde inte returnera något annat än vanliga framework-datatyper eller andra interface.

Här är tre bra böcker som jag har läst, som åtminstone delvis handlar om bra principer att tänka på vid användning av interface:

* Agile Priniciples, Patterns and Practices in C#
www.objectmentor.com/resources/books.html
www.ddj.com/joltawards/year_02.htm
(första upplagan, med C++, prisbelönades)
I synnerhet kapitlen om LSP, ISP och DIP är relevanta om man vill lära sig bra sätt att använda interface.
Här finns kapitlen i äldre C++ version som PDF-filer:
www.objectmentor.com/omSolutions/oops_what.html
Här finns också några länkar till SOLID-principerna:
mmiika.wordpress.com/oo-design-principles/


* Effective Java Second Edition
java.sun.com/docs/books/effective/toc.html
Flera "items" (avsnitt) i kapitel 4 handlar om användning av interface.
Item 16 som heter "Favor composition over inheritance" handlar f.ö. om "den andra principen i objektorienterad design" från nästa boktips längre ner (dvs boken om Design Patterns).
www.ddj.com/joltawards/year_01.htm
(första upplagan prisbelönades)
Även om bokens titel indikerar att den specifikt handlar om java så är ändå mycket av principerna applicerbara för andra språk som stöder objektorienterad programmering.


* Design Patterns - Elements of Reusable Object-Oriented Software
hillside.net/patterns/DPBook/DPBook.html
Den första principen om objektorienterad design heter "Program to an interface, not an implementation".
www.ddj.com/joltawards/year_94.htm


/ Tomas Johansson

njaaa men komplicerat.. det hänger ju mer på att få lite koll på där interfaces har en viktig innebörd och gör en väsentlig skillnad.. att bygga interface för minsta lilla småsak är ju inte effektivare än att lösa på plats.. (nu skriver jag bara ned hur jag tänker.. on the fly)



Thomas,
Intressant.. som du säger spelar det i princip (så länge samma idé är applicerbar) ingen roll vilket språk som berörs. Det är ju designen och funktionaliteten för och i olika sammanhang jag är ute efter.. ska titta närmare på dina förslag.. Allra trevligast egentligen vore att hitta ett gäng uppritade diagram för hur man löst interface/klasser i olika sammanhang.. Typ istället för 1 bok som oftast kanske behandlar 1 diagram för 1 kapitel..