[Java] Design Patterns detection programma

[Verwijderd]

Er zou een programma bestaan dat design patterns uit Java-code kan halen. Heeft iemand al van iets soortgelijks gehoord?

[WhizzCat]

Design patterns? Heb je het nu over PSD's ofzo...?

edit: ff gegoogled. Het vertoond idd overeenkomsten met psd's en ik denk niet dat je design patterns uit een programma structuur kunt halen.

[ Voor 60% gewijzigd door WhizzCat op 05-01-2003 11:40 ]

[Sanjuro]

Nee, ze bedoelt zoiets.

Ik weet niet waar je zo'n programmatje moeten vinden. Maar waarom zou je zo iets willen? Meestal wil je Design Patterns in je code stoppen, niet eruit halen.

Maar ik denk dat je betere reacties krijgt als je dit in Programming & Webscripting post. Misschien een mod vragen om dit topic even te veplaatsen.

[Verwijderd]

Als je kan zien welke design patterns gebruikt worden, kan je op een heel gemakkelijke manier moeilijke codewijzigingen doorvoeren en zo heel veel werk besparen.

[SH007]

Software Algemeen -> Programming & Webscripting

[SWfreak]

Ik heb nog nooit van zo'n programma gehoord en het lijkt me ook redelijk moeilijk. Soms gebruik je een variant van een design pattern, of is de manier van coden heel anders. Knap programma dat dat soort dingen eruit haalt.

mm, ff googlen op "detecting design patterns" geeft toch wat papers waar dit in geprobeerd wordt, o.a.:
http://courses.ncsu.edu/classes-a/tasug/kbrown/thesis2.htm
http://www.cs.umd.edu/pro...G/papers/OODP_VAL.DOC.pdf
Lijkt voorlopig echter nog niet veel verder dan research gekomen te zijn, want tools kan ik nog niet echt vinden....

[ Voor 47% gewijzigd door SWfreak op 05-01-2003 14:09 ]

[whoami]

Design Patterns as in 'Visitor', 'Abstract FActory', .... ?

Ik denk niet dat het echt mogelijk is om automatisch bepaalde design patterns uit een stuk code te halen. Misschien kun je wel een programma schrijven die die code analyseert en dan gaat gaan weergeven hoe groot de kans is dat er een bepaald pattern gebruikt werd, maar ik denk niet dat je automatisch kunt laten stellen van: 'dit stuk code bevat het strategy design pattern' bv.....

[mcB]

Ik denk niet dat het er veel gemakkelijker van wordt om codewijzigingen door te voeren wanneer je weet welk pattern er gebruikt wordt.
Design patterns zijn gewoon afspraken omtrent netjes programmeren.
Elk design pattern is met gemak in minder mooie en slecht leesbare code uit te werken.

Het design pattern en het gemak om code aan te passen staan dus volledig los van elkaar.

Wanneer je echt meer wil weten over design patterns in java kun je een boek aanschaffen.
Ik geloof dat deze ook "Design Patterns in Java" heet. Kun je ff zoeken op amazon.

[whoami]

mcB schreef op 05 januari 2003 @ 14:18:
Ik denk niet dat het er veel gemakkelijker van wordt om codewijzigingen door te voeren wanneer je weet welk pattern er gebruikt wordt.

Bwa, toch wel denk ik.
Als je op voorhand weet hoe bepaalde dingen geimplementeerd zijn, mbhv welke patterns etc, denk ik dat je toch wel wat minder uitzoekwerk zult hebben als je aanpassingen moet doorvoeren.
Maar die dingen zouden toch wel in de documentatie (al dan niet commentaar) moeten staan van de code.

Design patterns zijn gewoon afspraken omtrent netjes programmeren.

Niet helemaal correct imho. Een design pattern is een 'patroon' dat kan (her)gebruikt worden bij het oplossen van een bepaald probleem. IMHO heeft het niet zozeer met 'netjes coden' te maken. (Al wordt jouw code door het toepassen van DP's wel generieker oid).

Wanneer je echt meer wil weten over design patterns in java kun je een boek aanschaffen.
Ik geloof dat deze ook "Design Patterns in Java" heet. Kun je ff zoeken op amazon.

Of dit hier:

Design Patterns : Elements of Reusable Object-Oriented Software
Uitgever Addison Wesley Publishing Company
ISBN 0201634988
Auteur Erich Gamma

_{toch wel 'het' DP - boek}
Maar goed, dit is een andere discussie/topic.

[ari3]

Geautomatiseerd designpatterns uit code halen is best lastig. Een patroon suggereert wel dat het mogelijk moet zijn een patroon te herkennen in een brei code. Echter, een ontwerp patroon kan op heel veel subtiele manieren geïmplementeerd worden, waardoor het praktisch zeer lastig is dit geautomatiseerd te doen.

Gelukkig hebben veel (goede) Java-programmeurs de gewoonte om classes en interfaces zodanig te noemen dat je kan weten welk patroon er gebruikt is. Zegt ook meteen iets over hoe je zo'n type kan gebruiken.

bijvoorbeeld:

code:

AbstractDocumentFactory

code:

ConnectionPoolSingleton

Overigens kunnen profi pakketten als Rational Rose wel code reverse (en round-trip) engineeren naar UML modellen. Wellicht kun je patronen makkelijker herleiden uit diagrammen dan uit code?

[MisterData]

* MisterData pokes Alarmnummer en mbravenboer

Kijk anders eens op www.javahova.net, dat is de site waar die twee ook regelmatig rondhangen, en er is een aparte Design-Patterns hoek

[Alarmnummer]

Verwijderd schreef op 05 January 2003 @ 12:53:
Als je kan zien welke design patterns gebruikt worden, kan je op een heel gemakkelijke manier moeilijke codewijzigingen doorvoeren en zo heel veel werk besparen.

Door de naamgeving van bepaalde objecten kan ik meestal wel zien welk design pattern is gebruikt. En anders zie je het wel in de commentaar staan.

Ik zie daarom het nut, voor mezelf in ieder geval, niet in om zo`n analyse tool te gebruiken.

[ACM]

mcB schreef op 05 januari 2003 @ 14:18:
Ik denk niet dat het er veel gemakkelijker van wordt om codewijzigingen door te voeren wanneer je weet welk pattern er gebruikt wordt.

Er zijn natuurlijk verschillende ideeen achter de patterns, sommige om de logica uit de dataobjecten te houden (visitor bijvoorbeeld) andere om meer abstractie te krijgen (composite, factory) etc.

Als je dan niet weet dat dat het gebruikte pattern is en je propt domweg je logica op een plek ergens binnen de dataobjecten (in geval van een visitor) ben je toch best wel fout bezig
Als je dat wel van te voren wist, dan is het dus een stuk makkelijker

Wat opzich het beste is, is natuurlijk in de documentatie (en naamgeving, zoals alarmnummer al zegt) van de code te kijken, lijkt me dat daar toch wel in zou moeten staan wat voor patterns gebruikt worden voor belangrijke stukken functionaliteit.

[ Voor 3% gewijzigd door ACM op 05-01-2003 20:46 ]

[Glimi]

Automatisch is sowieso niet makkelijk te doen. Je gaat een patroon vaak niet volledig implementeren als je niet _alles_ nodig hebt, maar pakt alleen het hoog nodige.

Verder zit je natuurlijk ook met losse types. Stel je stopt in je detection-programma zo'n 10 designpatterns.
Dan heb je voor elke member in je class zo'n 10 checks nodig om te kijken of hij überhaupt in een pattern zou passen, waarna je ook nog elke class moet gaan combineren ( soms combinaties van [1...n] classes) , wat een enorme hoop controles komt te staan. Zeker als je een hoop classes in de code hebt, zal dat onwerkbaar traag zijn.

Natuurlijk zijn optimalisaties mogelijk (pattronen zijn vaak gebaseerd op polymorphisme en interfaces) maar ik denk dat het zelf maken een hels werk wordt

[Verwijderd]

Ik heb dit al gevonden:

http://prog.vub.ac.be/research/DMP/soul/soul2.html

It is thus possible to query Smalltalk code and derive relations between static elements. This allows to express, extract and enforce the link between design and implementation. For example, we have queries to look for composite patterns, type instance variables (although Smalltalk is dynamically typed!), and extract UML class diagrams from code.

Maar dat is niet voor Java en nog in experimentele fase...

In de documentatie zoeken, heeft in mijn concrete geval geen nut, want er is amper documentatie bij de code.

[Soultaker]

Ik denk niet dat er op dit moment iets is dat dusdanig goed werkt dat je er concreet iets aan hebt. Ik weet niet wat je plannen ermee zijn (kan me er weinig bij voorstellen, in ieder geval) maar waarschijnlijk heb je niets aan experimentele programma's of onderzoeksresultaten, als je specifiek voor Java op zoek bent. 'Met de hand' zoeken en herkennen is waarschijnlijk een stuk makkelijker en nauwkeuriger.

[ Voor 10% gewijzigd door Soultaker op 06-01-2003 12:16 ]

[Verwijderd]

Een groot probleem van Design Patterns is juist dat je ze later niet meer duidelijk terug kunt zien. Daarom maak je dus een klassediagram waarin de structuur veel duidelijker is. Darbij komt dat er ook patterns zijn die in structuur erg veel op elkaar lijken maar die in gebruik van elkaar verschillen (denk aan State/Strategy: welke klassen mogen de implementatie veranderen, wie mag er bij welke membervariabelen; dat zijn meer afspraken en worden niet altijd door de code gelimiteerd).

[bluewarlord]

Op dit moment is dat een van de speerpunten van onderzoek (waar ik me ondermeer mee bezig hou). Het is een bekend probleem dat design patterns "oplossen" in de implementatie en daardoor later niet meer terug te vinden zijn. Additionele documentatie zou dit moeten oplossen, maar in de praktijk gebeurd dit niet vaak. Een van de onderzoeksrichtingen is om te kijken of er nieuwe programmeertalen kunnen worden ontwikkeld die design patterns ook echt als een taal constructie ondersteunen.

Maar daar heb je nu niks aan. Wat je moet doen is puur handmatig werk, maak een UML diagram van de code, hier zijn wel tools voor te vinden. Probeer aan de hand van het UML diagram de gebruikte patterns
te destilleren, bedenk wel dat een klasse in meerdere patterns kan participeren met verschillende rollen. Check "code" documentatie om je ideeen te bevestigen.

[ Voor 8% gewijzigd door bluewarlord op 06-01-2003 12:29 ]

[matthijsln]

Niet echt precies voor design patterns, maar je zou eens naar RevJava kunnen kijken:
http://www.serc.nl/content/producten/revjava.shtml.

En in Dr Dobbs staan ook allemaal wondertools in de advertenties.

[mbravenboer]

Beetje laat . Ik ben er tegenwoordig niet meer mee bezig, maar hier kan je een paar linkjes vinden naar papers over design pattern extractie (sommige werken niet meer): Design Pattern Recovery

Hier vind je een overzicht van meer onderwerpen die te maken hebben met reverse engineering: Category reverse egineering.