Design Pattern: Facade

Een Facade is een Design Pattern. Om deze dus te kunnen begrijpen moeten we eerst even kijken naar Design Patterns.

Design Patterns zijn patronen die bewezen hebben dat ze werken in de programmeer wereld.

Denk aan naaien. Wanneer we iets willen naaien, brijen, haken, … gaan we altijd een patroon volgen. Deze patronen zijn ontworpen door mensen met veel ervaring, en geven de makkelijkste manier terug waarop we een t-shirt, broek, trui, deken, … kunnen maken. Het is uit de ervaring van anderen, dat deze patronen zijn ontwikkeld. Als je deze volgt, krijg je een mooi afgewerkt resultaat.

In het programmeren is dit niet anders. Hierbij hebben wij design patterns, patronen die ontworpen zijn door vele verschillende ontwikkelaars, afgaande op werkende constructen. Op deze manier hoefde het heet water niet telkens heruitgezonden te worden en konden ontwikkelaars die kennis hadden van deze patronen snel en efficiënt de SOOLId principes volbrengen.

De basis patronen voor software ontwikkeling zijn het eerst neergeschreven in het boek Design Patterns : Elements of Reusablee Objet-Oriented Software – GO4. Deze 4 hebben deze patronen niet uitgevonden, maar zij hebben de beste wel gebundeld in een boek en deze beschreven.

Elk patroon heeft een bepaald nut en behoord tot een bepaalde category. De drie basis categorieen zijn Creationele, structurele en Gedragsbeschrijvende patronen.

Hier gaan we nu gebruik van maken. We willen namelijk de verschillende klassen van JDBC gaan samenvoegen in 1 systeem die heet ons mogelijk maakt om enkel deze zelfgeschreven klasse op te roepen en daar alles mee te doen die ik van JDBC verwacht.

Hierdoor hoef ik minder rekening te houden met de onderliggende systemen en kan ik mij focussen op mijn code. Eveneens, mocht JDBC veranderen van werking, blijft onze klasse op dezelfde manier aangesproken worden. Wij moeten dan enkel de implementatie van onze helpende hand veranderen om terug te voldoen aan onze eisen voor onze app. Hierdoor zit de verandering opnieuw maar in 1 klasse, en niet in de verschillende klassen.

Het design pattern dat hiervoor geschikt is, heet een Facade.

Provide a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
Design Patterns – GO4 (p 185)

Een zeer gekend voorbeeld van zo een façade is de Scanner klasse. Die verschillende moeilijke concepten van I/O samenvoegt om een simpele taak uit te voeren.

Dit Principe gaan wij nu gebruiken om onze JDBC connectie te versoepelen. Eveneens gaan we hierin rekening houden met het properties bestand zodat we dit simpel kunnen configureren.

We bouwen deze façade nu samen op.