Single Responsibility Principle

Doorheen de jaren Waarin Ontwikkeling een opmars heeft gekend, merkte men ook snel dat er bepaalde manieren zijn om iets op een goede manier te kunnen doen zodanig dat ze niet of weinig gevoelig zijn voor verandering in de Code.

In een paper uit de jaren 2000 bracht Robert C. Martin een aantal principes naar boven, 5 om precies te zijn, die helpen om op een goede manier te programmeren en rekening toe houden met verandering en Clean Code. Een tijd later kregen deze 5 principes een gezamenlijke naam. SOLID. Dit is een acroniem dat voor de 5 principes staat.

• Single Responsibility Principle
• Open-Closed Principle
• Liskov Substitution principle
• Interface segregation principle
• Dependency Inversion Principle

Vanaf nu gaan we ook richting deze clean practices en Design Principles gaan werken. Hierbij gaan we nu focussen op het Single Responsibility Principle. Dit principe zegt dat een systeem / klasse / methode, maar verantwoordelijk mag zijn voor één en enkel één onderdeel. Een kerndoel hebben dus.

Om dit te kunnen verwezenlijken, moeten we onze code dus gaan opsplitsen in verschillende onderdelen die elk een bepaald doel hebben naar een algemener doel toe.

Op deze manier kunnen veranderingen makkelijker gebeuren. Zeker wanneer men dit koppelt aan lose coupling, waarin we enkel nog interfaces ter beschikking plaatsen en de implementaties makkelijk kunnen veranderen.

Dit gaan we nu doen met ons project. We gaan onze code opsplitsen en gebruik maken van een losgekoppelder systeem.

Om dit te kunnen verwezenlijken zullen we ook een helpende hand nodig hebben om de dubbele code, die momenteel nodig is, te bundelen op 1 plaats en deze herhalingen zo minimaal mogelijk te maken.

We starten met het meest simpele. Op dit moment geven we telkens opnieuw onze gegevens in voor de databank. Als dit dus ooit veranderd door een andere databank, nieuw wachtwoord of andere gebruiker. Dan moeten we dit op alle plaatsen gaan aanpassen. Dit willen we vermijden, dus kunnen we een .properties bestand aanmaken in de resources map, waar we deze 1 malig neerschrijven. En op alle andere plaatsen hier connectie mee maken.

Dit bestand gaan we voor deze oefening mainInfo.properties noemen en bevat de volgende lijnen.

jdbc.url=jdbc:mariadb://javadev-training.be/javadevt_Lf001
jdbc.user=javadevt_StudLf
jdbc.psw=STUDENTlf2020

De namen hierin zijn vrij gekozen, maar voor de duidelijkheid hebben we een standaard aangenomen. Namelijk eerst het framework of bibliotheek waarvoor de gegevens dienen, dan een punt en dan hun key naam. Na het gelijkheidsteken komt dan de value die met deze variabelen gekoppeld gaat.

Door dit te doen kunnen we deze gegevens op een simpele plaats terug vinden en aanpassen, en zo zal dit ook onmiddellijk overal waar deze code gebruikt wordt, aangepast zijn.

Natuurlijk moeten we deze gegevens ook nog kunnen inlezen. Dit kan via een Input stream zoals hieronder beschreven.

        try (FileInputStream in = new FileInputStream("src/main/resources/mainInfo.properties")) {

            Properties props = new Properties();
            props.load(in);
            props.getProperty("jdbc.url");

        } catch (IOException ioe) {
            ioe.printStackTrace();
        }

Doorheen onze code gaan we stap voor stap meer van deze stappen doorlopen zodat we onze code testbaar kunnen maken. Hierbij zullen we DAO (Data Acces Objects) schrijven die we zullen gebruiken om de connectie met de Databank te beheren, Data Klassen die de gegevens gaan representeren en Services die bepaalde diensten gaan bundelen om de aanvraag van een klant te verwerken.

Op deze manier werken we met interfaces die afhangen van een implementatie. Maar wanneer we de implementatie en dus het implementeren gedrag, veranderen zal de basis van de code deze verandering nauwelijks tot niet merken.

Dit doen we later in deze cursus.

De derde en voorlopig laatste stap in deze les, is het schrijven van een helpende hand. Een JdbcFacade die ons zal helpen met de connectie met JDBC.