Open Closed Principle

Open Closed Principle

Du kender det måske – en nødvendig ændring trigger andre ændringer og før du har set dig om har et hav af klasser ændret sig og du er nødt til at genteste og re-deploye store dele af din applikation. Sådanne ændringer koster dyrt og indebærer en større risiko end hvis du kunne nøjes med at tilføje en enkelt eller to klasser med tilhørende unit tests.

Så derfor, Open Closed Principle er vigtigt at forstå, når man skal udvikle systemer, som er bæredygtige ud over de første få måneder.

Princippet siger i al sin enkelhed at [1]:

Enhver komponent bør være åben for udvidelse, men lukket for ændringer

Problem

Antag du har programmeret en løsning til håndteringen af biblioteksbøger. Den hurtigt sammenkastede løsning ser simplificeret ud som:

Uden anvendelse af OCP

Problemet er at Library klassen i sin implementation af f.eks. ListContents hænger direkte på Book klassen og derfor ikke kan siges at være åben for udvidelser uden samtidig også at skulle ændres.

Løsning

Vi kan reparere på situationen ved at indføre et ILibraryContent interface så Library refererer denne istedet og lade Book implementere interfacet. På den måde kan vi indføre nye former for ILibraryContent, f.eks. DVD’s og Games uden at skulle ændre i Library klassens eksisterende metoder.

OCP via Strategy anvendelse

Dette er basalt set en anvendelse af Strategy design pattern’et.

Der er også andre måder at opnå denne form for modularitet, f.eks. via Dependency Injection (se fx [2]) eller via anvendelsen af Template (dofactory).

Referencer

[1] “Agile, Principles, Patterns and Practices in C#”, Martin/Martin

[2] http://en.wikipedia.org/wiki/Dependency_injection