Hej Dette spørgsmål kunne vel ligeså godt stilles i c++ c# eller andre kategorier, men fordi java er 100% objekt orienteret og fordi der er så mange der bruger det stiller jeg spørgsmålet her.
Jeg har af og til siddet med små stumper source code, eller skulle ændre/rette i et eksisterende program. I mange tilfælde støder jeg på interface erklæringer. Som jeg forstår det er et interface en "tom skal" der definere hvordan en klasse skal se ud, hvilke metoder den skal indeholde og osv. Når man så skriver sin klasse som implementere dette interface vil man blive tvunget til at skrive de metoder og egenskaber man har erklæret i sit interface. Men hvorfor ? Hvad er fordelen ved at anvende interface Er der tilfælde hvor man SKAL anvende dem Hvad gør de godt for Giver det mening når man designer sit program at starte med at definere alle sine interfaces Man behøver vel i grunden ikke disse interfaces, men jeg formoder det er "best practice" at anvende dem.
Håber der er et par stykker herinde der vil give mig et par linier med på vejen i min forståelse af oop. Det er meget anderledes for en gammel scripter og jeg ville faktisk gerne anvende de fordele oop giver, men jeg synes tit det ender op med noget spaghetti mix af struktureret kode og klasser blandt sammen. Og det er nok min egen skyld i bund og grund jo :-)
Du får dekoblet afhængigheder mellem klasser og du kan gøre dette i højere grad med interfaces end med nedarvning (i sprog der ikke tillader multipel nedarvning).
Der kan skrives langt langt mere om emnet, men ovenstående er i mine øjne essensen.
Du skal se interfaces som en kontrakt. En klasse bør ikke vide hvordan andre klasser udfører en funktion, kun at de kan det - og hvordan de skal bede dem om det.
Interfaces er bl.a. gode, når du får behov for at udskifte en klasse på et senere tidspunkt. Eksempel: du har en webshop, og du har en indkøbskurv-klasse og en betalingsklasse. Denne betalingsklasse benytter DIBS. og har en pay() metode, der tager kortnummer, udløbsdato og CSC i den rækkefølge. Senere får du et bedre tilbud fra ePay, og vil gerne skifte til dem, så du laver en ny betalingsklasse. Hvis du har et interface, som definerer betalingsklasser, så er du nødt til at lave den nye med samme metode og samme parametre, og den er derfor en drop-in replacement af den forrige. Du peger bare på den nye klasse, og så virker alting med det samme.
Naturligvis kan du kalde dine metoder det samme uden et interface, men interfacet tvinger dig til det, og minimerer dermed risikoen for bugs i fremtiden, fordi du lige havde glemt en metode eller lignende. Samtidig kan det være utrolig hjælpsomt, hvis der er flere kodere på samme projekt. De fremtidige er ikke i tvivl om, hvordan de skal kode fremtidige klasser, hvis de er bundet af et interface - og hvis flere arbejder samtidig, f.eks. en front-ender og en back-ender, kan man beslutte sig for sine interfaces før man skriver en linje anden kode, og dermed kunne færdiggøre og teste sin kode, uden den anden person er færdig med sin - fordi man ved hvordan de skal "tale sammen", når de er færdige.
Men hvis du ved du er alene, din kode ikke er stor og du ikke kommer til at ændre koden ret meget i fremtiden, så er interfaces ofte unødvendige.
Et godt lag vil vaere karakteriseret ved kun at have foelgende med public visibility: - rene data klasser - nogle faa interfaces - en enkelt factory class (kan evt. erstattes med eksternt DI library)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
