About
fv_2007
Agile innovative developer with deep insight into lots of platforms, technologies and protocols. Absolute “early adopter” in Web 2.0 technologies and more. Large professional network and eagerly talking about architecture, strategy, design patterns, restful ressources, object-oriented thinking and modeling languages such as PML. Special interest in programminglanguages constructs, knowledge on languages like Smalltalk, Erlang, Java, Clojure, Scala, Ruby... read more
Comments
Language

Design Pattern or Design Anti Pattern December 16, 2008 04:10 over 3 years ago

Indenfor software udvikling er design pattern en generel gentagelig løsning på et almindeligt forekommende problem! Et anti pattern derimod er en generel gentagelig løsning til et almindeligt forekommende problem men resultere i sidste ende i en dårligere løsning.

I den forgangende uge holdt jeg et indlæg om design pattern. Det var i gruppen af creational pattern hvilken betyder de høre til gruppen af mønster som skaber objekter. fx abstract factory, factory method, builder og singleton pattern. Det er alle design pattern der er mekanismer til oprettelse af objekter på en sådan måde at det passer til en aktuel situation og at man kan centralisere skabelsen.

I løbet af oplægget slog det mig at folk mentalt opfatter design pattern meget forskelligt. I nogle menneskers hoved er design pattern det de selv bygger gennem deres kode i hver eneste program mens andre opfatter design pattern som bestanddele af framework’s og biblioteker som de bare benytter for at organisere og strukturer deres løsninger.

Essensen er, at begge yderpunkter har ret!

Enhver systemudvikler men respekt for sig selv byggede snesevis af design pattern for 10 år siden. Faktisk var det så vildt af mange applikationer indenholdt så mange modsat rettede mønstre at de skabte “newtons første lov” helt af dem selv. Hvis man bruger mange frameworks skal man passe på ikke at bygge proprietærer framework eller design pattern ud over andre design pattern som allerede er indbygget.

To design pattern der hver for sig giver en god løsning kan bliver til noget rod hvis de sættes sammen. Derfor er det vigtigt at kende og kunne beskrive de egenskaber som hver enkelt mønster indenholder. Hvis den primære egenskab i en applikation er hastighed skal man finde præcis de mønster hvor hastighed er nøglebegreb. Konteksten hvori et design pattern bliver brugt er altså med til at bestemme om brugen bliver en succes.

Under dette indlæg diskuterede vi variationer af skabene design pattern som fx factory pattern og et builder pattern. De fleste har meget svært ved at se nogen forskel overhoved og ty derved til forklaringer og nuancere som er langt ud over dagligdagens realitet.

Factory Design Pattern

“skabe objekter uden angivelse af den nøjagtige klasse instans”

Builder Design Pattern

“abstrahere de enkelte skridt i konstruktionen af forskellige repræsentationer af objekter”

Singleton Design Pattern

“begrænse instantiation af en klasse til at kunne kontroller antal af skabte objekter”

# usage
factory = Singleton Factory Coffee
waiter = factory create server 
coffee = waiter create coffee (LATTE)

For år tilbage var selv fortaler for brug af mange design pattern’s! DET har jeg sagt undskyld for ved flere lejligheder, fx det berømte IKEA Design Pattern. Desværre er der stadig mange programmører som mener at denne tankegang er HOT mens nogle få udviklere har opdaget at software udvikling ikke handler om logiske lag men om forretning.


By Frank Vilhelmsen - 2 tags: architecture patterns - Add comment