Interface och Factory - Varför så mycket?

Interface är inte arv utan ett kontrakt som implementeras av en klass.
Om du kodar mot Interface istället för en konkret typ kan du enkelt byta ut implementationen utan att övrig kod märker det, d.v.s. loose coupling istället för tight coupling (vilket är oönskat).

Eftersom att du kan implementera flera Interface men endast ärva en enda klass möjliggör detta även skapandet av s.k. kompositklasser (se Composition over inheritance).

Factory används också för att hålla koden löst kopplad genom att du inte behöver binda upp en klass till att använda en viss konkret typ. Din klass Vehicle kan istället säga att den har en Motor, men låta Factory returnera den konkreta typen, t.ex. ElectricMotor eller GasolineMotor. Jag tycker att det förklaras ganska bra på den engelska wikin.

I många språk hjälper också interfaces en när man behöver mocka implementationer vid enhetstestning. Factories är väldigt vanligt både vid composition eller abstrakta klasser.

Just det där grejerna börjar man fundera på när man börjar mogna som programmerare. Om man inte har mentorer som kan hjälpa en bena ut det är det dags att börja plöja lite böcker

Själva Design Patterns boken för ganska bra argument för både Interface segregation (i inledningen) och sen för både Abstract Factories och Factory Methods. Den boken finns att ladda ner från Github i olika format.

Ponera att du vill ha ett program som öppnar en ruta på skärmen, fyller den med grafiska element och gör något. Om du överallt i din kod refererat till interfaces som uppfyller kontrakten för rutor och grafiska element istället för klasser som implementerar det och att du har ett factory för att instansiera dessa objekt så kan du göra det lätt för dig själv att byta vilka klasser som faktiskt implementerar detta beteende.

Tänk dig att du vill att denna koden ska fungera på mac och windows, två olika miljöer. Din kod beror inte på vilka klasser som egentligen utför grafiken, men dessa klasser borde ha olika implementation beroende på operativsystemet. Om du använt ett Abstract Factory så kan det räcka att enbart ändra vilket factory-objekt som skickas till koden beroende på operativsystem. Så din generella kod tar emot ett GraphicsFactory, vilket kan vara ett WindowsFactory eller MacFactory. Vilket då skulle behöva vara den enda skillnaden. Det finns många tillfällen då det kan vara skönt att byta ut hela familjer med relaterade klasser, vilket man kan göra om de alla har ett gemensamt interface (behöver inte strikt vara ett interface, men det kan vara svårt att få en bra arvshierarki annars).

Interfaces används för att skapa abstrakta kontrakt där användaren känner till minimalt med funktion.

Du kan ha ett interface som heter ICar, allt detta interface har är en metod som heter Drive().
Du har ett garage som pekar på en ICar.
Du går ut till ditt garage, det står en Volvo där, det vet inte du. Allt du gör är att gå till Volvon och säga Drive().
Nästa dag står det en Mercedes där, det vet inte du, du vet bara om Drive().

På samma sätt vill du ha alla dina implementationer så abstrakta som möjligt, så att dels personen som använder dina implementationer inte känner till hur det är implementerat. Sen dels för att man ska kunna byta ut en implementaton av något abstrakt kontrakt, utan att hela applikationen crashar.

Sen underlättar interfaces enormt för testning, då allt du behöver mocka är Drive().
Hade du istället behövt skicka in en konkret Volvo så är det väldigt mycket du behöver skapa upp och mocka bort för att kunna testa ditt garage. Då du egentligen skiter i vilken bil som står där. Du kanske bara vill testa att din port går att stänga.

Factory används för att centrera ett ställe för att skapa upp ett objekt. Det kan vara för att det krävs mycket logik eller andra beroenden att skapa upp detta objekt, men att man kanske behöver objektet på olika ställen i koden.
Då gör man en factory där man kan be om det objektet och få det.
Ofta kan detta då göras i samband med ett interface, att metoden ger tillbaka en ICar men beroende på någon inställning i config eller parameter på metoden kan du välja om du vill ha en Volvo eller en Mercedes.

Jag ska bygga en grej som kopplar med bluetooth på jobbet, eftersom produkter från olika märken beter sig lite olika även om de har samma ändamål så tänker jag bygga ett interface mellan min kod och aparaterna, kanske kalla den Connectable.

Då behöver jag inte koppla min egen kod till specifika implementationer utan jag kan bara skriva en kodsnutt på sidan som tar reda på vilket märke prylen är, gör en Connectable av den och min kod är glad.

Många bra förklaringar redan. Det bästa exemplet på interfaces i Java är nog List. Om du definerar en List kan du sedan sätta den till en klass som fullföljer kontraktet, t ex en ArrayList. Sen kanske du behöver en LinkedList istället och då även den fullföljer samma kontrakt räcker det att du ändrar vid tilldelningen på List. På samma sätt kan du definera en egen list klass och tilldela den om du vill.

Angående factories är det sällan jag skriver några men ibland använder man de omedvetet när man använder diverse bibliotek. Används främst när man bygger komplexa objekt. Finns bra exempel här: https://stackoverflow.com/questions/69849/factory-pattern-whe...