Codesmells for AspectJ
Upcoming SlideShare
Loading in...5
×
 

Codesmells for AspectJ

on

  • 3,925 views

AOP brings many good things to the table. However, this presentation focuses on recognizing anti-patterns in aspect oriented programming. It was created as part of a seminar on AOP at Utrecht ...

AOP brings many good things to the table. However, this presentation focuses on recognizing anti-patterns in aspect oriented programming. It was created as part of a seminar on AOP at Utrecht University.

Statistics

Views

Total Views
3,925
Views on SlideShare
3,915
Embed Views
10

Actions

Likes
0
Downloads
78
Comments
0

3 Embeds 10

http://www.slideshare.net 7
http://www.linkedin.com 2
https://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Codesmells for AspectJ Codesmells for AspectJ Presentation Transcript

    • AOP refactoring and code smells Towards a Catalogue of Refactorings and Code Smells for AspectJ AOP Seminar - Session 15 Sander Mak Center for Software Technology, Universiteit Utrecht Januari 15, 2007 Center for Software Technology Sander Mak
    • AOP refactoring and code smells Outline Introduction 1 AOP and refactoring 2 The paper 3 Other approaches 4 Conclusion 5 Questions 6 Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Introduction In the beginning Influential book by Martin Fowler (1999) Preceded by PhD work of William Opdyke (1992) Many papers on OO refactoring followed Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Introduction Define refactoring What is refactoring? Subtitle of Fowler’s book: improving design of existing code Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure. Martin Fowler Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Introduction Define refactoring What is refactoring? Subtitle of Fowler’s book: improving design of existing code Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure. Martin Fowler Behavior preserving Structure changing Improving design Refactorings are small transformation steps for code Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Introduction Why refactor? Maintainable code More understandable code Compliance to standard practices Speeds up development Reusable code, separate structure from app. logic Pinpointing bugs becomes easier Essential ingredient of agile processes Source code is the main communication medium Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Introduction Why refactor? Maintainable code More understandable code Compliance to standard practices Speeds up development Reusable code, separate structure from app. logic Pinpointing bugs becomes easier Essential ingredient of agile processes Source code is the main communication medium XP Rule ”Refactor Mercilessly” Summarizing: to increase both quality and productivity of a developer Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Introduction When to refactor? Rule of Three If you do something similar 3 times in a row... refactor it! When adding new functionality fit it in elegantly by refactoring otherwise risk spaghetti-code... During code review Everytime you find a code smell Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Introduction Code smells A code smell is a heuristic that might indicate the need for refactoring. Examples: Feature envy a class is more concerned with other classes’ data than with its own Long parameter list pass enough parameters to let a method find what it needs, but nothing more Temporary field class member is used where local local scope would have been appropriate These have been published along with refactorings to cure the smells Center for Software Technology Sander Mak
    • AOP refactoring and code smells > AOP and refactoring AOP and refactoring Observation: AOP and refactoring share a common high-level goal: Creating systems that are easier to understand and maintain Center for Software Technology Sander Mak
    • AOP refactoring and code smells > AOP and refactoring AOP and refactoring Observation: AOP and refactoring share a common high-level goal: Creating systems that are easier to understand and maintain Simplicity - less errors Clarity - communicate intentions Brevity - conciseness over verbosity The cardinal rule of writing unmaintainable code is to specify each fact in as many places as possible and in as many ways as possible. - Roedy Green in: How to write unmaintainable code Center for Software Technology Sander Mak
    • AOP refactoring and code smells > AOP and refactoring Refactoring extended AOP can take over where OO refactoring ends: Center for Software Technology Sander Mak
    • AOP refactoring and code smells > AOP and refactoring Good style When there are several ways to solve a problem, how do we pick the right wayTM ? Follow intentions of language Languages dictate composition mechanisms Ideally: each concern separated, but you cannot separate what you cannot compose later Experience Follow good style rules E.g. as documented in catalogue Avoiding code smells Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper The paper Towards a catalogue of refactorings and code smells for AspectJ Based on PhD work of M. Monteiro, written with his supervisor J. Fernandes Premises of the paper: There is no notion of good AOP style yet 1 This can be improved by providing a catalogue of refactorings and 2 smells Toolsupport for integrating AOP with refactoring is lacking 3 Preservation of intention over preservation of behavior Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper The paper Three categories of refactorings: OO → AspectJ (10) 1 AspectJ internal refactorings (6) 2 part of OO refactorings can be ported to aspects other refactorings handle new concepts, e.g. pointcuts Inter-aspect refactorings (11) 3 Idea is to sequentially compose these refactorings. Fragile pointcut problem is not addressed explicitly Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper The paper What is not in the paper: Formalism for AOP refactoring Authors follow format introduced by Fowler: Typical situation, Recommended action, Motivation, Mechanics, Examples Tool support Neither for application .. .. nor detection Metrics Mentions related work for AOP complexity metrics though Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper Approach Empirical: take existing, appropriate codebases and experiment. Attempt 1 A workflow program was decomposed into use cases. Use cases were captured in AOP style. Four AOP refactorings could be described Invaluable experience was gained Monolithic aspect Aspect was not exemplary for AspectJ usage Conclusion: good OO style pre-condition for extracting aspects Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper Approach Empirical: take existing, appropriate codebases and experiment. Attempt 2 AOP design pattern implementations of Hanneman & Kiczales were studied. Goal: try to describe transformation of OO → AOP in terms of refactorings Great variety of different aspects No domain knowledge necessary Some refactorings were too case specific (this needs to be recognized) Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper Approach Considerations regarding this empirical approach: Result: realworld solutions to realworld problems It worked for OO, so why not for AOP Result may be skewed because of case selection E.g. exception handling was not considered Generality of findings is debatable Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper OO to AOP refactoring Replace implements with declare parents Problem: interface adds secondary role to a class Usually combined with inline interface with aspect Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP internal refactoring Introduce aspect protection Problem: restrict usage of inter-type field to aspect and its sub-aspects Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP internal refactoring Minor criticism: A bit of a hack Very specific to AspectJ Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP internal refactoring Minor criticism: A bit of a hack Very specific to AspectJ In comparison, a refactoring like replace inter-type field with aspect map is much more general . Also, OO refactorings can be used in aspects (extract method, intra-method refactorings) Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP internal refactoring Minor criticism: A bit of a hack Very specific to AspectJ In Remark by Wouter comparison, a refactoring like replace inter-type field with aspect map the ”Introducegeneral .Protection” section, you might want to have In is much more Aspect some modifier that takes care of the protection? Also, OO refactorings canthis used in aspects (extract method, Sure, that would make be refactoring unnecessary intra-method refactorings) Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP internal refactoring Minor criticism: A bit of a hack Remarkspecific to AspectJ Very by Elmar Some of the refactorings like ”Introduce Aspect Protection” seem to thank their existance to (unclear, incomplete, faulty) semantics of In comparison, a refactoring like replace inter-type field with aspect AspectJ. Take for example the ”Introduce Aspect Protection” Can’t map is much more general . we argue that some of these semantics for AspectJ should change, instead of making a work around using refactoring? Also, OO refactorings can be used in aspects (extract method, Indeed. Still the existance of this refactoring in the catalogue intra-method refactorings) makes a programmer aware of the issues. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP internal refactoring Replace inter-type field with aspect map Problem: aspect introduces additional state to a class, but it might not need it all the time, so resources are wasted Inter-type declarations affect all instances of a class Inter-type declarations last a lifetime Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP internal refactoring Replace inter-type field with aspect map Problem: aspect introduces additional state to a class, but it might not need it all the time, so resources are wasted Inter-type declarations affect all instances of a class Inter-type declarations last a lifetime Solution: Maintain mapping to additional data in aspect, re-route all field accesses to the aspect Highly similar to relationship aspects! This refactoring constitutes moving from static to dynamic relations. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP generalisation refactoring Goal of these refactorings: transform an application specific aspect into a generalized, reusable aspect. Again, much of the OO idiom can be ported to aspects, with subtle differences: There is no inheritance/overriding between advice (as opposed to methods) Therefore it sometimes necessary to push down advice Weaving behavior might be surprising Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP generalisation refactoring Pull up inter-type declaration Problem: inter-type declaration is better placed in a super aspect (not because of duplication!) Issues: Targets of inter-type declarations receive an instance of the declaration per aspect When refactoring identical inter-type fields to super aspect, only one instance is created at weaving time Compare to making a field static With more than one sub aspect most likely not behavior preserving Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP code smells Describe what code should not be like Smells can lead to specific refactorings Smells are somewhat subjective Some of Fowler’s smells hint at cross-cutting concerns Captured by ’extract feature into aspect’ refactoring This paper describes 3 smells Center for Software Technology Sander Mak
    • AOP refactoring and code smells > The paper AOP code smells Smell 1: double personality Class has multiple roles Recall superimposed roles in design patterns Secondary role might be cross-cutting Smell 2: abstract classes Abstract classes need to be extended Preventing the extending class to inherit from other classes Default implementations can be provided by inter-type declarations Smell 3: aspect laziness Overuse of inter-type declarations Real AOP smell Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Automation Catalogues are cool, but... All these smells and refactorings deal with concerns that are inherently scattered I think automation is essential to: Detect OO → AOP refactorings 1 Detect refactorings within aspects 2 Apply AOP refactorings 3 This session’s paper agrees, but does not contribute Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches AOP code smells Related work on code smells: Detecting bad smells in AspectJ Piveta et al. Describes 5 AOP smells Provides algorithm to find these A prototype implementation is available Contains a case study on three AspectJ systems Algorithms are not very sophisticated Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches AOP code smells Described smells and algorithms: Anonymous pointcut definitions 1 Large aspects 2 Lazy aspects 3 Feature envy (defined as: class containing pointcut) 4 Abstract method introduction 5 Implemented in plugin for AspectJ eclipse extension Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches AOP code smells Architecture plugin Described smells and algorithms: Anonymous pointcut definitions 1 Large aspects 2 Lazy aspects 3 Feature envy (defined as: class containing pointcut) 4 Abstract method introduction 5 Implemented in plugin for AspectJ eclipse extension Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Anonymous pointcut detection Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Anonymous pointcut detection In other words: all pointcuts containing AspectJ pointcut primitives Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Abstract method introductions Abstract methods demand implementation, creates unnecessary coupling between aspect and class Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Case study Programs analyzed: AspectJ examples Design pattern implementations Hannemann & Kiczales GlassBox inspector (J2EE monitoring app) Results: very little smells found, besides many anonymous pointcuts .. these are not necessary bad, most of them are used once Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Case study Output analysis Programs analyzed: AspectJ examples Design pattern implementations Hannemann & Kiczales GlassBox inspector (J2EE monitoring app) Results: very little smells found, besides many anonymous pointcuts .. these are not necessary bad, most of them are used once Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Smell metrics Mentioned in previous paper: Metrics based refactoring Simon et al. More formalized metrics, and graphical representation. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Smell metrics Mentioned in previous paper: Metrics based refactoring Simon et al. More formalized metrics, and graphical representation. Output analysis Not aspect oriented (yet) Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Refactoring tool AspectJ Refactoring Tool (ART), Iwamoto et al. Works on PDGs, not on ASTs: Program Dependence Graph Existing formalism Like control flow graph With additional information on data Automates application of refactorings Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Refactoring tool 24 refactorings are proposed: OO → AOP refactorings internal AOP refactorings there is ample overlap with session paper Difference: refactorings are composed with laws Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Refactoring tool Example law, move field to aspect: 24 refactorings are proposed: OO → AOP refactorings internal AOP refactorings there is ample overlap with session paper Difference: refactorings are composed with laws Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Aspect Mining So far we’ve seen tools to: Find code smells Find OO refactorings Apply refactorings In order to find OO → AOP refactorings, we need something like aspect mining. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Aspect Mining So far we’ve seen tools to: Find code smells Question: Rinse Refactoring refactorings Find OO code into aspects can become a little tedious when trying to Apply refactorings track down all classes involved in say a observer pattern. There is research being done in aspect mining techniques [1] do you think with In the proposed catalogue of refactorings and code smells for AspectJ and order to find OO → AOP refactorings, we need something like aspect mining.mining techniques we could come anything close to the these aspect current support for refactorings in IDEs for normal OO concerns? [1]: Applying and combining three different aspect Mining Techniques Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Aspect Mining Approach created at TU Delft, combines and compares three aspect mining techniques: Fan-in analysis 1 Identifier analysis 2 Dynamic analysis 3 Each of these is tested on JHotDraw, a graphics application created to showcase good usage of design patterns. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Aspect Mining Fan-in analysis Count number of locations from which control is passed into a module In OO: fan-in for method M is number of distinct bodies that can call M Idea: if a method is called from many places, it is probably cross-cutting Certain treshold needs to be in place (experimentally determined value: 10) Analysis excludes getter/setters and utility methods like toString() Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Aspect Mining Identifier analysis Lexical analysis of identifiers in code Split composed name into single words Take stem of words Group common words If a group is scattered over multiple classes/methods: it is probably a cross-cutting concern Depends on naming conventions Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Aspect Mining Dynamic analysis Analyse execution traces of (instrumented) program Run program with different scenarios (use cases) Keep track of locality in code (call stack) Analyse which methods relate to which use case and which are generic Depends on well-chosen scenarios Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Aspect Mining A framework was devised to test all analyses. Some concerns as detected: Contract enforcement (pre-condition checking) Undo Observer pattern Persistance (read/write functionality) All three techniques found the most common concerns. Fan-in was found to be suitable for larger applications, and the techniques were complementary for uncommon concerns. No production quality tool was implemented. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Other approaches Other tools/methods Rolebased Refactoring Hannemann & Kiczales Programmer maps conceptual concerns to code fragments. Tools helps with mapping, and with manipulating the code fragments. Aspect mining tool Lexical analysis and type based analysis, with stand alone visualizer. Based on modified ajc FEAT/ConcernMapper Eclipse plugin to navigate/analyze/refactor AspectJ code. Concern Manipulation Eclipse plugin (originally by IBM) to manage Environment and build concerns in code. No analysis. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Conclusion Concluding remarks The paper gives a thorough description of a catalogue Unfortunately, it does not consider much more Especially more could be said on toolsupport Moving refactoring from OO to AOP brings in a lot of subtleties (aspects vs. classes) AOP refactoring research field is fairly new and open There are many (research)tools, but Its not very clear how these all relate and how powerful they are To answer Rinse’s question: I don’t think it comes near legacy refactoring support yet Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Conclusion Concluding remarks The paper gives a thorough description of a catalogue Unfortunately, it does not consider much more Especially more could be said on toolsupport Master’s thesis Moving refactoring from OO to AOP brings in a lot of subtleties May be someone should take on this challenge and survey the (aspects vs. classes) AOP refactoring tools field and create the ultimate formalism and tool for refactoring research field is fairly new and open AOP AOP refactoring :-) ? There are many (research)tools, but Its not very clear how these all relate and how powerful they are To answer Rinse’s question: I don’t think it comes near legacy refactoring support yet Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Wouter I think that some of the problems could be solved better with some Java and/or AspectJ changes, for example: In section 4.2 ”generalize target type” refactoring is used: private interface NewTypeClass {} declare parents: SomeClass implements NewTypeClass; This makes the code better by defining a role/type that the class then ’implements’. But the Interface/implements constructs of Java aren’t really designed for modeling roles right? I think that there might be a need for some stronger or better typing system than this (maybe something like Haskell’s?). Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Wouter I think that some of the problems could be solved better with some Java and/or AspectJ changes, for example: In section 4.2 ”generalize target type” refactoring is used: private interface NewTypeClass {} declare parents: SomeClass implements NewTypeClass; This makes the code better by defining a role/type that the class then ’implements’. But the Interface/implements constructs of Java aren’t really designed for modeling roles right? I think that there might be a need for some stronger or better typing system than this (maybe something like Haskell’s?). Let’s discuss Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Wouter Can you elaborate a bit on the main items that you think could be added to Java or aspectJ that will help the refactoring? Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Wouter Can you elaborate a bit on the main items that you think could be added to Java or aspectJ that will help the refactoring? Sure. Short answer: nothing. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Wouter Can you elaborate a bit on the main items that you think could be added to Java or aspectJ that will help the refactoring? Sure. Short answer: nothing. Why? Refactorings per definition depend on a language And aim to optimize usage of a language, e.g.: goto considered harmful switch is codesmell in presence of inheritance/polymorphism Certain refactorings can hint at language improvement though Changing a language could be seen as an ’ultimate refactoring’, and it would allow new refactorings Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Gerbo The designers of Java had their reasons not to allow multiple (implementation) inheritance, but AspectJ opened some sort of back door by using (interfaces combined with) aspects for it. And the paper even recommends this usage (“Split abstract class into aspect and interface” and “change abstract class to interface”), which possibly creates the ‘diamond problem’. So, what do we think of this - the original Java design ideas versus these abstract class code smells? Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Gerbo Question: Niels The designers of Java hadsmell just seems like a allow multiple The abstract class code their reasons not to solution for multiple (implementation)looks like another AspectJdescribe it is: ”Whenever inheritance. It inheritance, but way to opened some sort of back door byextend (interfaces combined implementation you should use you using a class just for the with) aspects for it. And the paper even recommendsinter type declarations.”. Orclass intothis wrong? interfaces and this usage (“Split abstract do I see aspect and interface” and “change abstract class to interface”), which possibly creates the ‘diamond problem’. So, what do we think of this - the original Java design ideas versus these abstract class code smells? Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Gerbo Diamond problem The designers of Java had their reasons not to allow multiple (implementation) inheritance, but AspectJ opened some sort of back door by using (interfaces combined with) aspects for it. And the paper even recommends this usage (“Split abstract class into aspect and interface” and “change abstract class to interface”), which possibly creates the ‘diamond problem’. So, what do we think of this - the original Java design ideas versus these abstract class code smells? Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Gerbo Common solution for diamond problem: Fix the ordering in which superclasses are consulted Perl, Python Fully qualify calls to methods in superclasses C++ About the refactorings: Together, the pair effectively extracts a mixin from the original abstract class mixin: class that provides functionality to other classes, not created for stand-alone use Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Gerbo Now if we would want to create a diamond, we have to: have 2 interfaces each having a method in common inter-type declarations forcing these interfaces on a single class have 2 default implementations of this common method as inter-type addition Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Gerbo Now if we would want to create a diamond, we have to: have 2 interfaces each having a method in common inter-type declarations forcing these interfaces on a single class have 2 default implementations of this common method as inter-type addition This last point will be flagged by ajc Conclusion: no multiple inheritance, rather: default implementations for interfaces. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Nabil Could you please elaborate more on when to use Extend Marker Interface with Signature? Because according to the authors it is used when you need to call a method that is specific to a type implementing an interface that doesn’t declare the wanted method. However in the precondition the authors argue that this refactoring is only feasible if all types implementing the interface export the signature of the method we want to call. So if all types export the signature then the method we want to call is not specific to a certain type, thus no refactoring is required. And if the types implementing the marker interface don’t export the signature and we have to enforce them to export the signature, then I would rather stick with downcast solution. But instead of doing it as illustrated in the paper, I would define another interface extending the marker interface and make it declare the specific method and then make the specific type implement the new interface. Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Nabil public aspect AA { public class A { interface Role{} public static void doA(){} interface Role2 extends Role{ public void specificMethod(); } } public class B { declare parents: A implements Role; declare parents: B implements Role2; public static void doB(){} public void specificMethod(){} public void something(Role obj){ ((Role2) obj).specificMethod(); } } } Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Nabil public aspect AA { public class A { Solution in paper interface Role{} Inter-type static void doA(){} public method introduction: interface Role2 extends Role{ public void specificMethod(); } } public abstract void Role.doSomething(); public class B { declare parents: A implements Role; declare parents: B implements Role2; public static void doB(){} public void specificMethod(){} public void something(Role obj){ ((Role2) obj).specificMethod(); } } } Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Nabil Comparing the solutions: Specific type for downcast not necessary at compilation But Nabil’s solution solves this by inlining a second interface Drawback: all classes with marker interface must implement injected method Nabil’s solution avoids this .. paper calls its solution stopgap for a reason, they had a specific scenario in mind In short: I like your solution better, though the original one ’tidies up’ a bit more Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Niels The ”Push down” refactoring rules are better (less code duplication) if the recommended action proposes another super-aspect which extends the previous super aspect (in cases where code duplication would occur) right? Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Niels The ”Push down” refactoring rules are better (less code duplication) if the recommended action proposes another super-aspect which extends the previous super aspect (in cases where code duplication would occur) right? All I can say: Push down refactorings do not avoid code duplication, but try to get a more logical placement for concerns in the aspect hierarchy. It could even lead to code duplication! But I’m not quite sure what you mean, could you explain a bit more? Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Jinfeng Suppose we have a pointcut call (public * *(..)), and it would match every public method call. And suppose we refactor a public method to a private method. (Then we might also need to modify the pointcut. So that would be a problem.) Can we detect and solve this problem when refactoring (to preserve the behavior)? Center for Software Technology Sander Mak
    • AOP refactoring and code smells > Questions Question: Jinfeng Suppose we have a pointcut call (public * *(..)), and it would match every public method call. And suppose we refactor a public method to a private method. (Then we might also need to modify the pointcut. So that would be a problem.) Can we detect and solve this problem when refactoring (to preserve the behavior)? This is called the fragile pointcut problem, and is indeed a very important issue when refactoring OO code in the presence of AO code. Almost all ’traditional’ (Fowler) refactorings can potentially break pointcuts. Wloka et al. created a tool that explicitly synchronizes (updates) pointcuts when refactoring, using a change impact analysis. Most tools ignore the issue it seems. Center for Software Technology Sander Mak