OCP — principer, öppenhet för utökning och stängdhet för modifiering

Vad är OCP (Open/Closed Principle)?

OCP (Open/Closed Principle) — principen om öppenhet för utökning och stängdhet för modifiering. Klasser, moduler och funktioner bör utformas så att nytt beteende läggs till utan att ändra deras källkod. Utökning uppnås genom arv, komposition eller substitution av gränssnittsimplementeringar.

Bertrand Meyer beskrev OCP för första gången i boken Object-Oriented Software Construction (1988) genom arv: basklassen förblir oförändrad och underklasser utökar dess beteende. Den moderna tolkningen av OCP, föreslagen av Robert C. Martin, bygger på polymorfism och gränssnitt: istället för arv används abstrakta kontrakt.

Skillnaden mellan tillvägagångssätten är betydande. Arv skapar en stel koppling mellan bas- och härledd klass. Gränssnitt och komposition ger flexibilitet: implementeringen byts ut utan att klientkoden ändras. Modern OCP — handlar om abstraktion, inte om arv.

Polymorfism som grund för OCP

Polymorf OCP använder abstrakta klasser eller gränssnitt för att definiera ett kontrakt. Klientkod arbetar med abstraktionen utan att känna till den konkreta implementeringen. Ny funktionalitet läggs till genom att skapa en ny klass som implementerar samma gränssnitt — utan någon ändring av befintlig kod. Detta gör systemet motståndskraftigt mot förändringar och förutsägbart för utökning.

Inom mobilutveckling är detta tillvägagångssätt allestädes närvarande: Strategy-mönstret gör det möjligt att byta ut algoritmer (bildkomprimering, cachning, autentisering) genom ett gemensamt gränssnitt. Att lägga till en ny strategi kräver inte ändring av koden som använder den.

Hur man implementerar principen om öppenhet och stängdhet

Implementering av OCP börjar med att separera variabelt beteende i en abstraktion. Om det i koden finns en switch-konstruktion eller en if-else-kedja som kontrollerar objektets typ — är detta en signal att tillämpa OCP. Varje villkorsgren kräver potentiellt tillägg av en ny gren vid utökning.

Refaktoreringsprocessen enligt OCP omfattar tre steg: identifiera den variabla aspekten (vad som kan utökas), separera den till ett gränssnitt eller en abstrakt klass, skriv om klientkoden för att arbeta med abstraktionen istället för den konkreta klassen. Därefter läggs ny funktionalitet till utan att ändra klienten.

Viktig anmärkning: stängdhet för modifiering är inte absolut. Om ändringskravet gäller själva abstraktionen eller kontraktet — är förändring oundviklig. OCP skyddar mot ändringar i implementeringar, inte i kontrakt. En bra design förutsätter att kontrakt är stabila och implementeringar variabla.

Vid utvärdering av arkitekturens kompatibilitet med OCP är det användbart att titta på utökningspunkter. Varje punkt där utvecklaren lägger till if-else eller switch för en ny typ — kandidat för abstraktion. Ett system utformat enligt OCP har förutsägbara utökningspunkter: gränssnitt med dokumentation “implementera detta gränssnitt för att lägga till en ny typ”. I Android är ett sådant exempel Factory-mönstret tillsammans med ViewModelProvider.Factory — att lägga till en ny ViewModel-typ kräver inte ändring av befintliga fabriker.

Strategier och mönster för OCP

De mest effektiva mönstren för att följa OCP inom mobilutveckling inkluderar Strategy, Template Method, Decorator och Factory. Var och en löser problemet med att utöka beteende utan att ändra befintlig kod genom olika mekanismer för objektorienterad design.

Strategy gör det möjligt att byta ut algoritmer i farten genom ett gemensamt gränssnitt. Inom iOS-utveckling används strategier för animationer och formulärvalidering. Template Method definierar algoritmens skelett i basklassen och underklasser åsidosätter stegen — lämpligt för skärmar med gemensam struktur men olika innehåll.

Decorator lägger dynamiskt till beteende till ett objekt utan att ändra dess klass. I Android tillämpas Decorator för att omsluta Repository med ett cache- eller loggningsskikt. Factory Method skapar objekt genom ett gränssnitt, vilket gör att underklasser kan bestämma vilken klass som ska instansieras — grunden för OCP-kompatibel beroendeskapande.

Val av strategi för ett mobilt projekt

Valet av mönster beror på stabiliteten hos beteendet som utökas. Strategy är optimal när algoritmer byts ut helt. Template Method — när strukturen är fast men stegen är variabla. Decorator — när utökningen måste vara transparent för klienten. För de flesta scenarier i Android och iOS räcker Strategy + beroendeinjektion.

Att tillämpa dessa mönster utan OCP är tekniskt möjligt men förlorar sin mening. Det är just OCP som motiverar varför vi introducerar en extra abstraktionsnivå: så att systemet kan växa utan att skriva om befintlig kod.

Exempel på OCP i mobila appar

Låt oss titta på Android-exemplet med betalningshantering. Utan OCP kräver varje nytt betalningssystem ändring av bearbetningsklassen. Med OCP läggs en ny gränssnittsimplementering till utan att redigera befintlig kod.

// Brott mot OCP: switch kräver ändring för ett nytt system
class BadPaymentProcessor {
    fun process(type: String) {
        when (type) {
            "card" -> // kortbearbetning
            "paypal" -> // PayPal-bearbetning
        }
    }
}

// OCP-kompatibel design
interface PaymentMethod {
    fun pay(amount: Double)
}

class CardPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

class PayPalPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

// Nytt system — ny klass, utan att ändra befintlig kod
class ApplePayPayment : PaymentMethod {
    override fun pay(amount: Double) { }
}

iOS-exemplet med textfältsvalidering demonstrerar samma logik genom Swift-protokoll:

// OCP-kompatibel validering
protocol ValidationRule {
    func validate(_ input: String) -> Bool
}

struct EmailRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.contains("@")
    }
}

struct PhoneRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count == 11
    }
}

// Att lägga till en ny regel kräver inte ändring av validatorns kod
struct PasswordRule: ValidationRule {
    func validate(_ input: String) -> Bool {
        return input.count >= 8
    }
}

Den viktigaste fördelen med OCP i dessa exempel: att lägga till ApplePay eller PasswordRule kräver inte ändring av befintliga klasser. Kod utökas horisontellt — genom nya filer, inte genom att ändra gamla filer. Detta minskar risken för regression och påskyndar implementeringen av ny funktionalitet.

Typiska misstag vid brott mot OCP

Det vanligaste brottet — switch- eller when-konstruktion baserat på objektets typ. Varje gång en ny typ läggs till måste alla sådana switchar i koden hittas och en ny gren läggas till. En missad switch — ett runtime-fel som är svårt att upptäcka i kompileringsfasen.

Inom mobilutveckling bryts OCP vid användning av jättelika enum-klasser med metoder som är beroende av enum-värdet. Att lägga till ett nytt enum-element kräver ändring av varje switch i hela projektet. Alternativet — polymorfism genom ett gränssnitt, där varje typ implementerar sitt eget beteende.

Ett annat typiskt brott — God Adapter: RecyclerView.Adapter (Android) eller UITableViewDataSource (iOS) som genom if-else bearbetar olika celltyper. Varje ny celltyp kräver utökning av adaptern. Lösningen — en polymorf ViewHolder med en gemensam bind-metod, där varje celltyp ansvarar för sin egen visning.

Hur man undviker brott mot OCP

Förebyggande åtgärder inkluderar: att avstå från switch baserat på typ till förmån för polymorfism, beroendeinjektion genom gränssnitt och tillämpning av Factory-mönstret för att skapa objekt baserat på konfiguration. Analys av kod för “typomkopplare” — obligatorisk del av kodgranskning i OCP-orienterade team.

Refaktorering av befintligt OCP-brott utförs genom Replace Conditional with Polymorphism: varje villkorsgren blir en separat klass med implementering av ett gemensamt gränssnitt. Klientkoden skrivs om för att arbeta med gränssnittet och den konkreta implementeringen tillhandahålls genom en fabrik eller DI-behållare.

Det är viktigt att förstå att OCP och polymorfism inte löser alla utökningsproblem. Om arkitekturen har valts felaktigt kommer tillägg av ny funktionalitet att kräva ändring inte bara av implementeringar utan även av kontrakt. En bra arkitektur förutsäger utökningsriktningar och placerar abstraktioner precis vid dessa punkter. Investeringen i OCP lönar sig ju längre projektet lever och ju oftare kraven för specifika moduler ändras.