The Artima Developer Community
Sponsored Link

Weblogs Forum
Refactoring To Aspects

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
Carlos Perez

Posts: 153
Nickname: ceperez
Registered: Jan, 2003

Refactoring To Aspects (View in Weblogs)
Posted: May 19, 2003 6:29 AM
Reply to this message Reply
The weakness of Design Patterns is that the mainline of code may be obscured. "Refactoring to Aspects" may prove to be a better alternative.

Joshua Kerievsky has put together an interesting compilation titled "Refactoring To Patterns". At first glance, I had thought that this piece was more buzzword compliant than of practical value. However, after reading his "Stop Over-Engineering" article, I was prompted to take a more indepth look. Joshua writes:

Once my design skills had improved, I found myself using patterns in a different way: I began refactoring to patterns, instead of using them for up-front design or introducing them too early into my code. My new way of working with patterns emerged from my adoption of Extreme Programming design practices, which helped me avoid both over- and under-engineering.

Therefore, Design Patterns shouldn't be introduced upfront, but rather at a later stage in development. However, this practice points out a serious weakness of Design Patterns, that is the main line of code may be obscured. It's similar to the problems when you optimize your code for performance, it's one of the reasons why you should delay such optimizations.

A long time ago, Jiri Soukup wrote a book entitled "Taming C++". It was an extremely intriguing book. It had several claims about designs that went against conventional wisdom. One claim was that design patterns created too many cyclic dependencies and he proposed an alternative structure that was more manageable. The strategy was to introduce a new class called a "pattern class" that would in essence encapsulate the essence of the Design Pattern.

Fast forward to the 21st century, Jan Hannemann and Gregor Kiczales have put together a compilation of "GoF Design Patterns in Java and AspectJ". For the 23 GoF patterns, using AspectJ, they managed to remove the code-level dependecies from the participants in 17 cases. Aspects reduced the dependencies between its participants, as a side-effect it was not as intrusive as employing Design Patterns.

Although this is still an emerging area of study, refactoring your design to use "pattern classes" or "aspects" may be the appropriate approach to illuminate the main line of code and ultimately may lead to better manageability of complexity.

Topic: Half Sisters Previous Topic   Next Topic Topic: Notes from PyCon DC

Sponsored Links


Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use