[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [aspectj-users] [OT] development style
|
Thanks Matt for commenting on this. Unfortunately, I don't think I am following you.
Let me reformulate it, so that I can check if I get it correctly:
/**
* Normal class. Everybody is working with this one.
*/
public class NormalClass {
}
/**
* An interface describing some new functionality.
*/
public interface SomeAdditionalFunctionality {
}
aspect ApplySomeAdditionalToNormalClass{
declare parents: NormalClass implements SomeAdditionalFunctionality;
// implementation of SomeAdditionalFunctionality
}
Your suggestion is saying: if somebody is gonna need the functionality added by
SomeAdditionalFunctionality (somebody else than the aspect itself), than change NormalClass to
implement the interface and only provide the default implementation through aspect.
Indeed this makes a lot of sense to me, but would make the NormalClass source unworkable in any
other IDE than Eclipse, or will be showed with error if not using AJDT editor.
This is the problem I am trying to solve. I would like to ask you if this would make things better:
package foo;
public class NormalClass {}
package bar;
public interface SomeAdditionalFunctionality {}
package foo;
public aspect NormalClassImplementsSomeAdditionalFunctionality {
// only the declare parents here
}
package bar;
public aspect DefaultSomeAdditionalFunctionalityImplementation {
// default implementation of SomeAdditionalFunctionality;
}
At least this will allow the developers to work with whatever IDE and editors they like with normal
classes, and also may provide enough information to them to understand how the
SomeAdditionalFunctionality applies to NormalClass.
Please let me know what do you think?
./alex
--
.w( the_mindstorm )p.
#: Matthew Webster changed the world a bit at a time by saying on 11/30/2005 4:50 PM :#
Alex,
You need to avoid this 3-way problem: target class, aspect, client. Either
the fact you have added the interface should be known only to the target
class and aspect or be transparent to others. In the situation you
describe the concern has "leaked" out and is no longer properly
modularized. Others need to know the interface is supported so changing
the source to reflect that makes sense. You can still use the aspect to
provide default method implementations.
Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester, SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/
Please respond to aspectj-users@xxxxxxxxxxx
Sent by: aspectj-users-bounces@xxxxxxxxxxx
To: userAJ <aspectj-users@xxxxxxxxxxx>
cc:
Subject: [aspectj-users] [OT] development style
Hi!
The last few hours I have been spent some time thinking how the
development inside a team should
work in the following scenario. Here is the short story:
1/ I have a few `core´ aspects that I would like to implement and use
2/ These are mainly meant to add `features´ to the domain model (f.e. make
the domain model
implement IReferenceable and provide the default implementation. This
falls very close to the
example in Eclipse AspectJ book with listeners).
3/ The exposed public API can be used in some of the application layers
(f.e. inside services).
Now my worries/questions are:
1/ how are the other team members gonna see the `additional´ API
one approach would be to create a packaged jar with the
weaved version, and the others to work with
it; but this will not work if the development happens on the same sources
(same project), but
different packages;
2/ the AJ java editor is able to handle quite well the references to ITDs,
but unfortunately is not
(yet) as good as the Java editor; moreover Java editor is the default one,
so they will think the
project has errors, even if it is compilable.
[I will not bring into discussion the extreme situation where the team is
using different tools :-) ]
3/ I have thought that using the @AJ will solve this and allow the other
developers to use the Java
default editor, but unfortunately with ITD the problem is the same.
4/ navigation: it is not yet possible to navigate to an ITD (or I just
missed it). Considering the
following example, the rest of the team may start to be dizzy about what
is happening to the project:
[code]
public class Foo {
}
public aspect ReferenceableEntityAspect {
declare parent: Foo implements IReferenceable;
public void IReferenceable.setReference(Long id) {
[...]
}
public Long IReferenceable.getReference() {
[...]
}
}
public class Bar {
public void someMethod(Foo foo) {
Long refId = foo.getReference(); // <=
here the Java editor is reporting an error; the AJ editor
is unable to navigate
}
}
[/code]
Is it something that I am missing? I would really like to find out how
other advanced AJ users are
handling the development while using AJ.
thanks in advance for any hints and suggestions that will allow me to go
this way or the correct
way. I have the feeling that it would be a really mistake to dismiss AJ in
this project, but I don't
want to have bad/mixed feelings inside the team.
./alex
--
.w( the_mindstorm )p.
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
!DSPAM:438dbcbb8231383254889!
------------------------------------------------------------------------
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users
!DSPAM:438dbcbb8231383254889!