This project is read-only.

Base Aspect class refactoring

Developer
Jun 10, 2010 at 11:18 AM

Hi,

I discovered that the pattern I'm using with the constructor of the TraceAspect class is very useful in other cases. Namely, rather than overriding the ShouldIntercept method, I just provide a parameter of type Predicate<InterceptInfo> in the constructor. So, I'm going to move this (the constructor and the ShouldIntercept implementation) to the base Aspect class.

This can be useful if you let the aspect define the behavior, but not whether it should or should not apply this behavior (this is determined by the constructor parameter). Mainly for generic purpose aspects, like TraceAspect, Stub etc. (I do plan to add more).

As for the aspects targeted for particular classes/methods, you'll still be able to override the ShouldIntercept method, or call the base constructor with the corresponding parameter from your aspect's constructor. Like,

public class HandlerTracer: Aspect{
   HandlerTracer(): base(info=>info.TargetInstance is IHttpHandler){}
...
}
The (not so) breaking change is that if you use the parameterless constructor and not override ShouldIntercept (which is not abstract now) in your custom aspect, it's going to intercept all calls, which could be a potential performance hit.

 

Coordinator
Jun 10, 2010 at 1:00 PM
CThru is slow enough as it is. I don't want to change it's quickness. there are already users out there who use it with SilverUnit (which uses default ctors).
let's not make their tests slower, shall we? :)
How can you make the refactoring and still keep things at the same speed for the backward compatible silverunit?
it might be worth adding some speed integration tests for silverunit to see we are not breaking them in the process of refactoring. what do you think? is that something you can do?

On Thu, Jun 10, 2010 at 1:18 PM, ulu <notifications@codeplex.com> wrote:

From: ulu

Hi,

I discovered that the pattern I'm using with the constructor of the TraceAspect class is very useful in other cases. Namely, rather than overriding the ShouldIntercept method, I just provide a parameter of type Predicate<InterceptInfo> in the constructor. So, I'm going to move this (the constructor and the ShouldIntercept implementation) to the base Aspect class.

This can be useful if you let the aspect define the behavior, but not whether it should or should not apply this behavior (this is determined by the constructor parameter). Mainly for generic purpose aspects, like TraceAspect, Stub etc. (I do plan to add more).

As for the aspects targeted for particular classes/methods, you'll still be able to override the ShouldIntercept method, or call the base constructor with the corresponding parameter from your aspect's constructor. Like,

public class HandlerTracer: Aspect{
   HandlerTracer(): base(info=>info.TargetInstance is IHttpHandler){}
...
}
The (not so) breaking change is that if you use the parameterless constructor and not override ShouldIntercept (which is not abstract now) in your custom aspect, it's going to intercept all calls, which could be a potential performance hit.

 

Read the full discussion online.

To add a post to this discussion, reply to this email (CThru@discussions.codeplex.com)

To start a new discussion for this project, email CThru@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Thanks,

Roy Osherove
www.TypeMock.com - Unit Testing, Plain Smart

Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
A blog for team leaders: http://5Whys.com
my .NET blog: http://www.ISerializable.com
Twitter: http://twitter.com/RoyOsherove
+972-524-655388 (GMT+2)
Developer
Jun 10, 2010 at 7:14 PM
Well, now I see that I was thinking about something else while writing this.

Currently ShouldIntercept is abstract, meaning that the existing
aspects are overriding it anyway. This is done so that you pay
attention to this performance issue while writing your own aspect.

The proposed refactoring will not affect the existing code, since it
already implements its own version of ShouldIntercept. As for the new
Aspects, developers just have to not forget either use the
parametrized constructor or override the ShouldIntercept method.

In short, the refactoring does not affect the existing code, but
leaves more freedom to developers of new aspects, and if these new
aspects are designed poorly, it could lead to performance problems
(which can be easily cured by redesigning new aspects without touching
the core CThru code).

As for the performance tests, I'm not quite sure how to write them..
anyway, the SilverUnit tests run pretty fast on my mediocre box, each
being under 100ms.

2010/6/10 RoyOsherove <notifications@codeplex.com>:
> From: RoyOsherove
>
> CThru is slow enough as it is. I don't want to change it's quickness. there
> are already users out there who use it with SilverUnit (which uses default
> ctors).
> let's not make their tests slower, shall we? :)
> How can you make the refactoring and still keep things at the same speed for
> the backward compatible silverunit?
> it might be worth adding some speed integration tests for silverunit to see
> we are not breaking them in the process of refactoring. what do you think?
> is that something you can do?
>
> On Thu, Jun 10, 2010 at 1:18 PM, ulu <[email removed]> wrote:
>
> From: ulu
>
> Hi,
>
> I discovered that the pattern I'm using with the constructor of the
> TraceAspect class is very useful in other cases. Namely, rather than
> overriding the ShouldIntercept method, I just provide a parameter of type
> Predicate<InterceptInfo> in the constructor. So, I'm going to move this (the
> constructor and the ShouldIntercept implementation) to the base Aspect
> class.
>
> This can be useful if you let the aspect define the behavior, but not
> whether it should or should not apply this behavior (this is determined by
> the constructor parameter). Mainly for generic purpose aspects, like
> TraceAspect, Stub etc. (I do plan to add more).
>
> As for the aspects targeted for particular classes/methods, you'll still be
> able to override the ShouldIntercept method, or call the base constructor
> with the corresponding parameter from your aspect's constructor. Like,
>
> public class HandlerTracer: Aspect{
> HandlerTracer(): base(info=>info.TargetInstance is IHttpHandler){}
> ...
> }
>
> The (not so) breaking change is that if you use the parameterless
> constructor and not override ShouldIntercept (which is not abstract now) in
> your custom aspect, it's going to intercept all calls, which could be a
> potential performance hit.
>
>
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
>
>
> --
> Thanks,
>
> Roy Osherove
> www.TypeMock.com - Unit Testing, Plain Smart
>
> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
> A blog for team leaders: http://5Whys.com
> my .NET blog: http://www.ISerializable.com
> Twitter: http://twitter.com/RoyOsherove
> +972-524-655388 (GMT+2)
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
Coordinator
Jun 10, 2010 at 7:45 PM
so, can we keep it abstract? so people are forced to implement it? and not forget about it?

On Thu, Jun 10, 2010 at 9:14 PM, ulu <notifications@codeplex.com> wrote:

From: ulu

Well, now I see that I was thinking about something else while writing this.

Currently ShouldIntercept is abstract, meaning that the existing
aspects are overriding it anyway. This is done so that you pay
attention to this performance issue while writing your own aspect.

The proposed refactoring will not affect the existing code, since it
already implements its own version of ShouldIntercept. As for the new
Aspects, developers just have to not forget either use the
parametrized constructor or override the ShouldIntercept method.

In short, the refactoring does not affect the existing code, but
leaves more freedom to developers of new aspects, and if these new
aspects are designed poorly, it could lead to performance problems
(which can be easily cured by redesigning new aspects without touching
the core CThru code).

As for the performance tests, I'm not quite sure how to write them..
anyway, the SilverUnit tests run pretty fast on my mediocre box, each
being under 100ms.

2010/6/10 RoyOsherove <notifications@codeplex.com>:
> From: RoyOsherove

>
> CThru is slow enough as it is. I don't want to change it's quickness. there
> are already users out there who use it with SilverUnit (which uses default
> ctors).
> let's not make their tests slower, shall we? :)
> How can you make the refactoring and still keep things at the same speed for
> the backward compatible silverunit?
> it might be worth adding some speed integration tests for silverunit to see
> we are not breaking them in the process of refactoring. what do you think?
> is that something you can do?
>
> On Thu, Jun 10, 2010 at 1:18 PM, ulu <[email removed]> wrote:
>
> From: ulu
>
> Hi,
>
> I discovered that the pattern I'm using with the constructor of the
> TraceAspect class is very useful in other cases. Namely, rather than
> overriding the ShouldIntercept method, I just provide a parameter of type
> Predicate<InterceptInfo> in the constructor. So, I'm going to move this (the
> constructor and the ShouldIntercept implementation) to the base Aspect
> class.
>
> This can be useful if you let the aspect define the behavior, but not
> whether it should or should not apply this behavior (this is determined by
> the constructor parameter). Mainly for generic purpose aspects, like
> TraceAspect, Stub etc. (I do plan to add more).
>
> As for the aspects targeted for particular classes/methods, you'll still be
> able to override the ShouldIntercept method, or call the base constructor
> with the corresponding parameter from your aspect's constructor. Like,
>
> public class HandlerTracer: Aspect{
> HandlerTracer(): base(info=>info.TargetInstance is IHttpHandler){}
> ...
> }
>
> The (not so) breaking change is that if you use the parameterless
> constructor and not override ShouldIntercept (which is not abstract now) in
> your custom aspect, it's going to intercept all calls, which could be a
> potential performance hit.
>
>
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])

>
> To start a new discussion for this project, email
> [email removed]

>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
>
>
> --
> Thanks,
>
> Roy Osherove
> www.TypeMock.com - Unit Testing, Plain Smart
>
> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
> A blog for team leaders: http://5Whys.com
> my .NET blog: http://www.ISerializable.com
> Twitter: http://twitter.com/RoyOsherove
> +972-524-655388 (GMT+2)
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])

>
> To start a new discussion for this project, email
> [email removed]

>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com

Read the full discussion online.

To add a post to this discussion, reply to this email (CThru@discussions.codeplex.com)

To start a new discussion for this project, email CThru@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Thanks,

Roy Osherove
www.TypeMock.com - Unit Testing, Plain Smart

Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
A blog for team leaders: http://5Whys.com
my .NET blog: http://www.ISerializable.com
Twitter: http://twitter.com/RoyOsherove
+972-524-655388 (GMT+2)
Developer
Jun 14, 2010 at 11:53 AM
Roy,

It *is* abstract currently, but I was suggesting making a default
implementation..

There's another possibility. We leave the base Aspect class as it is,
and make another base class, called GenericAspect (or whatever,
"generic" as in "generic purpose", not as in ".Net 2.0 Generics"). Now
that I think of it, it looks better this way. Generic aspects are ones
that care about behavior, and not about when they are applied. The
"when" is determined at runtime via the constructor. For example, the
Stub aspect has a certain behavior: it ignores a call. But which call
to ignore is determined via the constructor parameter.

Initially I thought that introducing another class would create
confusion, but now I think it's better than changing the base Aspect
class. I'll write a blog post on that, so that it becomes (hopefully)
clear.

Artem

2010/6/10 RoyOsherove <notifications@codeplex.com>:
> From: RoyOsherove
>
> so, can we keep it abstract? so people are forced to implement it? and
> not forget about it?
>
> On Thu, Jun 10, 2010 at 9:14 PM, ulu <[email removed]> wrote:
>
> From: ulu
>
> Well, now I see that I was thinking about something else while writing this.
>
> Currently ShouldIntercept is abstract, meaning that the existing
> aspects are overriding it anyway. This is done so that you pay
> attention to this performance issue while writing your own aspect.
>
> The proposed refactoring will not affect the existing code, since it
> already implements its own version of ShouldIntercept. As for the new
> Aspects, developers just have to not forget either use the
> parametrized constructor or override the ShouldIntercept method.
>
> In short, the refactoring does not affect the existing code, but
> leaves more freedom to developers of new aspects, and if these new
> aspects are designed poorly, it could lead to performance problems
> (which can be easily cured by redesigning new aspects without touching
> the core CThru code).
>
> As for the performance tests, I'm not quite sure how to write them..
> anyway, the SilverUnit tests run pretty fast on my mediocre box, each
> being under 100ms.
>
> 2010/6/10 RoyOsherove <[email removed]>:
>> From: RoyOsherove
>>
>> CThru is slow enough as it is. I don't want to change it's quickness.
>> there
>> are already users out there who use it with SilverUnit (which uses default
>> ctors).
>> let's not make their tests slower, shall we? :)
>> How can you make the refactoring and still keep things at the same speed
>> for
>> the backward compatible silverunit?
>> it might be worth adding some speed integration tests for silverunit to
>> see
>> we are not breaking them in the process of refactoring. what do you think?
>> is that something you can do?
>>
>> On Thu, Jun 10, 2010 at 1:18 PM, ulu <[email removed]> wrote:
>>
>> From: ulu
>>
>> Hi,
>>
>> I discovered that the pattern I'm using with the constructor of the
>> TraceAspect class is very useful in other cases. Namely, rather than
>> overriding the ShouldIntercept method, I just provide a parameter of type
>> Predicate<InterceptInfo> in the constructor. So, I'm going to move this
>> (the
>> constructor and the ShouldIntercept implementation) to the base Aspect
>> class.
>>
>> This can be useful if you let the aspect define the behavior, but not
>> whether it should or should not apply this behavior (this is determined by
>> the constructor parameter). Mainly for generic purpose aspects, like
>> TraceAspect, Stub etc. (I do plan to add more).
>>
>> As for the aspects targeted for particular classes/methods, you'll still
>> be
>> able to override the ShouldIntercept method, or call the base constructor
>> with the corresponding parameter from your aspect's constructor. Like,
>>
>> public class HandlerTracer: Aspect{
>> HandlerTracer(): base(info=>info.TargetInstance is IHttpHandler){}
>> ...
>> }
>>
>> The (not so) breaking change is that if you use the parameterless
>> constructor and not override ShouldIntercept (which is not abstract now)
>> in
>> your custom aspect, it's going to intercept all calls, which could be a
>> potential performance hit.
>>
>>
>>
>> Read the full discussion online.
>>
>> To add a post to this discussion, reply to this email
>> ([email removed])
>>
>> To start a new discussion for this project, email
>> [email removed]
>>
>> You are receiving this email because you subscribed to this discussion on
>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>
>> Please note: Images and attachments will be removed from emails. Any posts
>> to this discussion will also be available online at codeplex.com
>>
>>
>> --
>> Thanks,
>>
>> Roy Osherove
>> www.TypeMock.com - Unit Testing, Plain Smart
>>
>> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
>> A blog for team leaders: http://5Whys.com
>> my .NET blog: http://www.ISerializable.com
>> Twitter: http://twitter.com/RoyOsherove
>> +972-524-655388 (GMT+2)
>>
>> Read the full discussion online.
>>
>> To add a post to this discussion, reply to this email
>> ([email removed])
>>
>> To start a new discussion for this project, email
>> [email removed]
>>
>> You are receiving this email because you subscribed to this discussion on
>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>
>> Please note: Images and attachments will be removed from emails. Any posts
>> to this discussion will also be available online at codeplex.com
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
>
>
> --
> Thanks,
>
> Roy Osherove
> www.TypeMock.com - Unit Testing, Plain Smart
>
> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
> A blog for team leaders: http://5Whys.com
> my .NET blog: http://www.ISerializable.com
> Twitter: http://twitter.com/RoyOsherove
> +972-524-655388 (GMT+2)
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
Coordinator
Jun 14, 2010 at 4:35 PM
"GlobalAspect" ?


On Mon, Jun 14, 2010 at 1:53 PM, ulu <notifications@codeplex.com> wrote:

From: ulu

Roy,

It *is* abstract currently, but I was suggesting making a default
implementation..

There's another possibility. We leave the base Aspect class as it is,
and make another base class, called GenericAspect (or whatever,
"generic" as in "generic purpose", not as in ".Net 2.0 Generics"). Now
that I think of it, it looks better this way. Generic aspects are ones
that care about behavior, and not about when they are applied. The
"when" is determined at runtime via the constructor. For example, the
Stub aspect has a certain behavior: it ignores a call. But which call
to ignore is determined via the constructor parameter.

Initially I thought that introducing another class would create
confusion, but now I think it's better than changing the base Aspect
class. I'll write a blog post on that, so that it becomes (hopefully)
clear.

Artem


2010/6/10 RoyOsherove <notifications@codeplex.com>:
> From: RoyOsherove
>
> so, can we keep it abstract? so people are forced to implement it? and
> not forget about it?
>
> On Thu, Jun 10, 2010 at 9:14 PM, ulu <[email removed]> wrote:
>
> From: ulu
>
> Well, now I see that I was thinking about something else while writing this.
>
> Currently ShouldIntercept is abstract, meaning that the existing
> aspects are overriding it anyway. This is done so that you pay
> attention to this performance issue while writing your own aspect.
>
> The proposed refactoring will not affect the existing code, since it
> already implements its own version of ShouldIntercept. As for the new
> Aspects, developers just have to not forget either use the
> parametrized constructor or override the ShouldIntercept method.
>
> In short, the refactoring does not affect the existing code, but
> leaves more freedom to developers of new aspects, and if these new
> aspects are designed poorly, it could lead to performance problems
> (which can be easily cured by redesigning new aspects without touching
> the core CThru code).
>
> As for the performance tests, I'm not quite sure how to write them..
> anyway, the SilverUnit tests run pretty fast on my mediocre box, each
> being under 100ms.
>
> 2010/6/10 RoyOsherove <[email removed]>:

>> From: RoyOsherove
>>
>> CThru is slow enough as it is. I don't want to change it's quickness.
>> there
>> are already users out there who use it with SilverUnit (which uses default
>> ctors).
>> let's not make their tests slower, shall we? :)
>> How can you make the refactoring and still keep things at the same speed
>> for
>> the backward compatible silverunit?
>> it might be worth adding some speed integration tests for silverunit to
>> see
>> we are not breaking them in the process of refactoring. what do you think?
>> is that something you can do?
>>
>> On Thu, Jun 10, 2010 at 1:18 PM, ulu <[email removed]> wrote:
>>
>> From: ulu
>>
>> Hi,
>>
>> I discovered that the pattern I'm using with the constructor of the
>> TraceAspect class is very useful in other cases. Namely, rather than
>> overriding the ShouldIntercept method, I just provide a parameter of type
>> Predicate<InterceptInfo> in the constructor. So, I'm going to move this
>> (the
>> constructor and the ShouldIntercept implementation) to the base Aspect
>> class.
>>
>> This can be useful if you let the aspect define the behavior, but not
>> whether it should or should not apply this behavior (this is determined by
>> the constructor parameter). Mainly for generic purpose aspects, like
>> TraceAspect, Stub etc. (I do plan to add more).
>>
>> As for the aspects targeted for particular classes/methods, you'll still
>> be
>> able to override the ShouldIntercept method, or call the base constructor
>> with the corresponding parameter from your aspect's constructor. Like,
>>
>> public class HandlerTracer: Aspect{
>> HandlerTracer(): base(info=>info.TargetInstance is IHttpHandler){}
>> ...
>> }
>>
>> The (not so) breaking change is that if you use the parameterless
>> constructor and not override ShouldIntercept (which is not abstract now)
>> in
>> your custom aspect, it's going to intercept all calls, which could be a
>> potential performance hit.
>>
>>
>>
>> Read the full discussion online.
>>
>> To add a post to this discussion, reply to this email
>> ([email removed])
>>
>> To start a new discussion for this project, email
>> [email removed]
>>
>> You are receiving this email because you subscribed to this discussion on
>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>
>> Please note: Images and attachments will be removed from emails. Any posts
>> to this discussion will also be available online at codeplex.com
>>
>>
>> --
>> Thanks,
>>
>> Roy Osherove
>> www.TypeMock.com - Unit Testing, Plain Smart
>>
>> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
>> A blog for team leaders: http://5Whys.com
>> my .NET blog: http://www.ISerializable.com
>> Twitter: http://twitter.com/RoyOsherove
>> +972-524-655388 (GMT+2)
>>
>> Read the full discussion online.
>>
>> To add a post to this discussion, reply to this email
>> ([email removed])
>>
>> To start a new discussion for this project, email
>> [email removed]
>>
>> You are receiving this email because you subscribed to this discussion on
>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>
>> Please note: Images and attachments will be removed from emails. Any posts
>> to this discussion will also be available online at codeplex.com
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
>
>
> --
> Thanks,
>
> Roy Osherove
> www.TypeMock.com - Unit Testing, Plain Smart
>
> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
> A blog for team leaders: http://5Whys.com
> my .NET blog: http://www.ISerializable.com
> Twitter: http://twitter.com/RoyOsherove
> +972-524-655388 (GMT+2)
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com

Read the full discussion online.

To add a post to this discussion, reply to this email (CThru@discussions.codeplex.com)

To start a new discussion for this project, email CThru@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Thanks,

Roy Osherove
www.TypeMock.com - Unit Testing, Plain Smart

Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
A blog for team leaders: http://5Whys.com
my .NET blog: http://www.ISerializable.com
Twitter: http://twitter.com/RoyOsherove
+972-524-655388 (GMT+2)
Developer
Jun 15, 2010 at 9:25 AM
Hmm.. Global? What's global about it?

I think it should be kinda opposed to "specific", so, "CommonAspect"
(if you don't like "GenericAspect")?

2010/6/14 RoyOsherove <notifications@codeplex.com>:
> From: RoyOsherove
>
> "GlobalAspect" ?
>
> On Mon, Jun 14, 2010 at 1:53 PM, ulu <[email removed]> wrote:
>
> From: ulu
>
> Roy,
>
> It *is* abstract currently, but I was suggesting making a default
> implementation..
>
> There's another possibility. We leave the base Aspect class as it is,
> and make another base class, called GenericAspect (or whatever,
> "generic" as in "generic purpose", not as in ".Net 2.0 Generics"). Now
> that I think of it, it looks better this way. Generic aspects are ones
> that care about behavior, and not about when they are applied. The
> "when" is determined at runtime via the constructor. For example, the
> Stub aspect has a certain behavior: it ignores a call. But which call
> to ignore is determined via the constructor parameter.
>
> Initially I thought that introducing another class would create
> confusion, but now I think it's better than changing the base Aspect
> class. I'll write a blog post on that, so that it becomes (hopefully)
> clear.
>
> Artem
>
> 2010/6/10 RoyOsherove <[email removed]>:
>> From: RoyOsherove
>>
>> so, can we keep it abstract? so people are forced to implement it? and
>> not forget about it?
>>
>> On Thu, Jun 10, 2010 at 9:14 PM, ulu <[email removed]> wrote:
>>
>> From: ulu
>>
>> Well, now I see that I was thinking about something else while writing
>> this.
>>
>> Currently ShouldIntercept is abstract, meaning that the existing
>> aspects are overriding it anyway. This is done so that you pay
>> attention to this performance issue while writing your own aspect.
>>
>> The proposed refactoring will not affect the existing code, since it
>> already implements its own version of ShouldIntercept. As for the new
>> Aspects, developers just have to not forget either use the
>> parametrized constructor or override the ShouldIntercept method.
>>
>> In short, the refactoring does not affect the existing code, but
>> leaves more freedom to developers of new aspects, and if these new
>> aspects are designed poorly, it could lead to performance problems
>> (which can be easily cured by redesigning new aspects without touching
>> the core CThru code).
>>
>> As for the performance tests, I'm not quite sure how to write them..
>> anyway, the SilverUnit tests run pretty fast on my mediocre box, each
>> being under 100ms.
>>
>> 2010/6/10 RoyOsherove <[email removed]>:
>>> From: RoyOsherove
>>>
>>> CThru is slow enough as it is. I don't want to change it's quickness.
>>> there
>>> are already users out there who use it with SilverUnit (which uses
>>> default
>>> ctors).
>>> let's not make their tests slower, shall we? :)
>>> How can you make the refactoring and still keep things at the same speed
>>> for
>>> the backward compatible silverunit?
>>> it might be worth adding some speed integration tests for silverunit to
>>> see
>>> we are not breaking them in the process of refactoring. what do you
>>> think?
>>> is that something you can do?
>>>
>>> On Thu, Jun 10, 2010 at 1:18 PM, ulu <[email removed]> wrote:
>>>
>>> From: ulu
>>>
>>> Hi,
>>>
>>> I discovered that the pattern I'm using with the constructor of the
>>> TraceAspect class is very useful in other cases. Namely, rather than
>>> overriding the ShouldIntercept method, I just provide a parameter of type
>>> Predicate<InterceptInfo> in the constructor. So, I'm going to move this
>>> (the
>>> constructor and the ShouldIntercept implementation) to the base Aspect
>>> class.
>>>
>>> This can be useful if you let the aspect define the behavior, but not
>>> whether it should or should not apply this behavior (this is determined
>>> by
>>> the constructor parameter). Mainly for generic purpose aspects, like
>>> TraceAspect, Stub etc. (I do plan to add more).
>>>
>>> As for the aspects targeted for particular classes/methods, you'll still
>>> be
>>> able to override the ShouldIntercept method, or call the base constructor
>>> with the corresponding parameter from your aspect's constructor. Like,
>>>
>>> public class HandlerTracer: Aspect{
>>> HandlerTracer(): base(info=>info.TargetInstance is IHttpHandler){}
>>> ...
>>> }
>>>
>>> The (not so) breaking change is that if you use the parameterless
>>> constructor and not override ShouldIntercept (which is not abstract now)
>>> in
>>> your custom aspect, it's going to intercept all calls, which could be a
>>> potential performance hit.
>>>
>>>
>>>
>>> Read the full discussion online.
>>>
>>> To add a post to this discussion, reply to this email
>>> ([email removed])
>>>
>>> To start a new discussion for this project, email
>>> [email removed]
>>>
>>> You are receiving this email because you subscribed to this discussion on
>>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>>
>>> Please note: Images and attachments will be removed from emails. Any
>>> posts
>>> to this discussion will also be available online at codeplex.com
>>>
>>>
>>> --
>>> Thanks,
>>>
>>> Roy Osherove
>>> www.TypeMock.com - Unit Testing, Plain Smart
>>>
>>> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
>>> A blog for team leaders: http://5Whys.com
>>> my .NET blog: http://www.ISerializable.com
>>> Twitter: http://twitter.com/RoyOsherove
>>> +972-524-655388 (GMT+2)
>>>
>>> Read the full discussion online.
>>>
>>> To add a post to this discussion, reply to this email
>>> ([email removed])
>>>
>>> To start a new discussion for this project, email
>>> [email removed]
>>>
>>> You are receiving this email because you subscribed to this discussion on
>>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>>
>>> Please note: Images and attachments will be removed from emails. Any
>>> posts
>>> to this discussion will also be available online at codeplex.com
>>
>> Read the full discussion online.
>>
>> To add a post to this discussion, reply to this email
>> ([email removed])
>>
>> To start a new discussion for this project, email
>> [email removed]
>>
>> You are receiving this email because you subscribed to this discussion on
>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>
>> Please note: Images and attachments will be removed from emails. Any posts
>> to this discussion will also be available online at codeplex.com
>>
>>
>> --
>> Thanks,
>>
>> Roy Osherove
>> www.TypeMock.com - Unit Testing, Plain Smart
>>
>> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
>> A blog for team leaders: http://5Whys.com
>> my .NET blog: http://www.ISerializable.com
>> Twitter: http://twitter.com/RoyOsherove
>> +972-524-655388 (GMT+2)
>>
>> Read the full discussion online.
>>
>> To add a post to this discussion, reply to this email
>> ([email removed])
>>
>> To start a new discussion for this project, email
>> [email removed]
>>
>> You are receiving this email because you subscribed to this discussion on
>> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>>
>> Please note: Images and attachments will be removed from emails. Any posts
>> to this discussion will also be available online at codeplex.com
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com
>
>
> --
> Thanks,
>
> Roy Osherove
> www.TypeMock.com - Unit Testing, Plain Smart
>
> Author of "The Art Of Unit Testing" (http://ArtOfUnitTesting.com )
> A blog for team leaders: http://5Whys.com
> my .NET blog: http://www.ISerializable.com
> Twitter: http://twitter.com/RoyOsherove
> +972-524-655388 (GMT+2)
>
> Read the full discussion online.
>
> To add a post to this discussion, reply to this email
> ([email removed])
>
> To start a new discussion for this project, email
> [email removed]
>
> You are receiving this email because you subscribed to this discussion on
> CodePlex. You can unsubscribe or change your settings on codePlex.com.
>
> Please note: Images and attachments will be removed from emails. Any posts
> to this discussion will also be available online at codeplex.com