[G_PRO] Basis Programmeren en OO Programmeren
DigitAP
  • Welkom
  • Inleiding
    • Benodigdheden
    • Afspraken code
    • Afspraken oefeningen
    • Nuttige extras
    • Dankwoord
    • Mee helpen?
  • Semester 1: Programming Principles
    • H1: Werken met Visual Studio
      • Introductie tot C#
      • Visual Studio en .NET Core installeren
      • Een C# project maken in Visual Studio
      • Fouten in je code
      • Je eerste stappen in C#
      • Input/Output: ReadLine/WriteLine
      • Kleuren in Console
      • Oefeningen
    • H2: Variabelen en datatypes
      • De syntaxis van C#
      • Datatypes
      • Variabelen
      • Expressies en operators
      • Oefeningen
    • H3: Strings en hun methoden
      • Strings
      • Strings samenvoegen
      • Omzetten van en naar strings
      • Functionaliteit van strings
      • Oefeningen
    • H4: Beslissingen
      • Beslissingen intro
      • Enkelvoudige booleaanse expressies
      • If, else, else if
      • Samengestelde booleaanse expressies
      • Scope van variabelen
      • Switch
      • Oefeningen
    • H5: Loops
      • Loops intro
      • While en Do While
      • For
      • Debuggen
      • Oefeningen
    • H6: Arrays
      • Array principes
      • Alternatieve syntax
      • Werken met arrays
      • Defaultwaarden
      • List<T>
      • Oefeningen
    • H7: Methoden
      • Methoden intro
      • Parameters
      • Return waarden
      • Geavanceerde methoden
      • Oefeningen
    • Intermezzo: TextCell
    • H8: Numerieke data
      • De Math klasse
      • Random
      • Casting en conversie
      • Oefeningen
    • H9: Meerdimensionaal werken
      • N-dimensionale arrays
      • Geneste iteratie
      • Oefeningen
    • H10: Gevorderde tekstverwerking
      • Voorstelling van tekst
      • Interpolatie met formattering
      • Werken met arrays van strings
      • Input en output van tekstbestanden
      • Oefeningen
    • Afsluiter: TextCell2D
  • Semester 2 : OOP
    • H10: Klassen en objecten
      • OOP Intro
      • Klassen en objecten aanmaken
      • DateTime: leren werken met objecten
      • Enumeraties: nog een eigen datatype
      • Klassen en objecten weergeven deel 1
      • Attributen
      • Methoden
      • Access modifiers
      • Properties
      • Oefeningen
    • H11: Objecten (al dan niet) aanmaken
      • Constructors
      • Spelen met strings
      • Oefeningen
    • H12: Geheugenmanagement bij klassen
      • value en reference met eigen objecten
      • nullable value types
      • NullReference exception
      • Oefeningen
    • H13: Datastructuren
      • Foreach en var
      • List
      • Dictionary
      • Immutable datastructuren
      • Verdere datastructuren
      • Oefeningen
    • H14: Overerving
      • Overerving intro
      • Virtual en override
      • Abstract
      • Constructors bij overerving
      • Oefeningen
    • H15: Geavanceerde overerving
      • protected access modifier
      • Base keyword
      • System.Object
      • Oefeningen
    • H16: Exception handling
      • Werken met exceptions
      • Zelf uitzonderingen maken
      • Wanneer exceptions en handling gebruiken
      • Oefeningen
    • H17: Polymorfisme en interfaces
      • Polymorfisme
      • Polymorfisme in de praktijk
      • Interfaces
      • Losse koppeling
      • Oefeningen
    • H18: Testing
      • Intro Testing
      • Wat is Unit Testing
      • Waarom Unit Testing?
      • Wanneer Unit Testing?
      • Schrijven van een unit test: AAA methode
      • Eerste voorbeeld: Sum
      • Assert
      • Oefening even of oneven getal
      • TestInitialize en DataRows
      • Oefening BMI
      • Exception testing
      • Oefening BMI exception
      • Oefening SchoolAdmin test null-waarden en TestCleanup
      • Oefening SchoolAdmin test equals
      • Oefening SchoolAdmin test cursus zoeken met id
      • Dependencies bij Unit Testing
      • Mocking
      • Oefeningen Mocking
      • Test Driven Development
      • Class Library
      • Oefeningen TDD
    • H19: SOLID
      • Single Responsibility Principle (SRP)
      • Open/Closed Principle (OCP)
      • Liskov Substitution Principle (LSP)
      • Interface Segregation Principle (ISP)
      • Dependency Inversion Principle (DIP)
  • Appendix
    • Visual Studio Tips & Tricks
    • Ea-ict coding guidelines
    • Oefeningen kerkhof
  • Semester 1 appendix
    • Nice to know stuff
      • Out en Ref parameters
      • Jagged arrays
    • All-In-Projecten
      • Overzicht
      • Console Matrix
      • Ascii filmpjes maken met loops
      • Ascii filmpjes maken met methoden
      • Fun with methods: een verhaalgenerator
      • Tekst-gebaseerd Maze game
      • Conway game of life
  • Semester 2 appendix
    • Operator overloading
    • Object Initializer Syntax
    • Compositie en aggregatie
    • Nice to know stuff
      • Klassen herbruiken
      • Expression bodied members
    • All-In-Projecten
      • Overzicht
      • OO Textbased Game
      • War Simulator
      • Map Maker
      • Magic The Gathering API
      • SchoolAdmin
  • Pro (geen leerstof en/of in opbouw)
    • Bitwise operators
    • Generics en collections
      • Generics methoden en types
      • Generic classes en constraints
      • Collections
      • Labo-oefeningen
    • Events
      • Events
      • Chat server
    • Software engineering
      • SOLID
Powered by GitBook
On this page
Export as PDF
  1. Semester 2 : OOP
  2. H19: SOLID

Interface Segregation Principle (ISP)

Het Interface Segregation Principle (ISP) benadrukt dat afgeleide klassen niet gedwongen moeten worden afhankelijk te zijn van interfaces die ze niet gebruiken. Met andere woorden, het stelt dat interfaces specifiek en gespecialiseerd moeten zijn voor de behoeften van de klassen die ze implementeren, om overbodige en ongebruikte methoden te vermijden.

Dit principe is vooral relevant bij het ontwerpen van interfaces in situaties waarin klassen verschillende sets functionaliteit nodig hebben. Door het ISP toe te passen, creëer je meer cohesie en losse koppeling in je code, waardoor het gemakkelijker wordt om code te begrijpen, aan te passen en te onderhouden.

Laten we dit principe verder toelichten aan de hand van een voorbeeld in C#.

Stel dat je een interface hebt genaamd IWorker die enkele methoden definieert die verband houden met werknemers:

public interface IWorker
{
	void Work();
	void Eat();
	void Sleep();
}

Nu heb je twee klassen, OfficeWorker en FactoryWorker, die werknemers vertegenwoordigen:

public class OfficeWorker : IWorker
{
	public void Work()
	{
    		// Implementatie van werken in een kantooromgeving
	}

	public void Eat()
	{
    		// Implementatie van eten in een kantooromgeving
	}

	public void Sleep()
	{
    		// Implementatie van slapen in een kantooromgeving
	}
}

public class FactoryWorker : IWorker
{
	public void Work()
	{
    		// Implementatie van werken in een fabrieksomgeving
	}

	public void Eat()
	{
    		// Implementatie van eten in een fabrieksomgeving
	}

	public void Sleep()
	{
    		// Implementatie van slapen in een fabrieksomgeving
	}
}

In dit geval worden alle methoden van het IWorker-interface geïmplementeerd in zowel OfficeWorker als FactoryWorker. Maar wat als we later een nieuwe klasse introduceren, bijvoorbeeld Driver, die alleen de Work-methode nodig heeft? Dan zou deze klasse gedwongen worden om lege implementaties te hebben voor Eat en Sleep, wat onnodig is en tegen het ISP ingaat.

Om het Interface Segregation Principle toe te passen, kunnen we de interface opsplitsen in meerdere interfaces die specifiek zijn voor de verschillende rollen van de werknemers:

public interface IWorkable
{
	void Work();
}

public interface IEatable
{
	void Eat();
}

public interface ISleepable
{
	void Sleep();
}

Nu kunnen we de interfaces afzonderlijk implementeren in de respectievelijke klassen:

public class OfficeWorker : IWorkable, IEatable, ISleepable
{
	// Implementaties van de specifieke methoden
}

public class FactoryWorker : IWorkable, IEatable, ISleepable
{
	// Implementaties van de specifieke methoden
}

public class Driver : IWorkable
{
	// Implementatie van de enige vereiste methode
}

Door het toepassen van het ISP hebben we interfaces gemaakt die specifiek zijn voor de behoeften van elke klasse. Hierdoor hoeven klassen geen ongebruikte methoden te implementeren en wordt de codebase meer modulair en onderhoudbaar. Het ISP moedigt aan om interfaces op te splitsen in kleinere, gerichte interfaces die beter aansluiten bij de behoeften van individuele klassen.

PreviousLiskov Substitution Principle (LSP)NextDependency Inversion Principle (DIP)

Last updated 1 year ago