Cross cutting concerns
-
I was wondering if there are any design patterns in object oriented programming that address cross cutting concerns, i.e. I'm looking for approaches that don't involve an aspect oriented language (or AOP features added to an existing OOP language). The closest I've come to so far is the decorator pattern. Say you have a class with a method called doIt. You want to log (a classic cross cutting concern) the results of this method, so you create a decorator class to wrap the original class. Inside its doIt method, it logs the results returned from the object it's decorating. Thoughts?
-
I was wondering if there are any design patterns in object oriented programming that address cross cutting concerns, i.e. I'm looking for approaches that don't involve an aspect oriented language (or AOP features added to an existing OOP language). The closest I've come to so far is the decorator pattern. Say you have a class with a method called doIt. You want to log (a classic cross cutting concern) the results of this method, so you create a decorator class to wrap the original class. Inside its doIt method, it logs the results returned from the object it's decorating. Thoughts?
Leslie Sanford wrote:
, so you create a decorator class to wrap the original class. Inside its doIt method, it logs the results returned from the object it's decorating.
Thoughts?Sounds like a nice academical excercise; you'd be creating an additional (and relatively complex) object for every class that you'll be using. That might amount to a lot of work. Simplest solution is a static class (would work similar to Debug.Print), solution I like most would be injection (Some ILogger), solution to be advised would be the logging component of the EntLib.
Bastard Programmer from Hell :suss:
-
Leslie Sanford wrote:
, so you create a decorator class to wrap the original class. Inside its doIt method, it logs the results returned from the object it's decorating.
Thoughts?Sounds like a nice academical excercise; you'd be creating an additional (and relatively complex) object for every class that you'll be using. That might amount to a lot of work. Simplest solution is a static class (would work similar to Debug.Print), solution I like most would be injection (Some ILogger), solution to be advised would be the logging component of the EntLib.
Bastard Programmer from Hell :suss:
-
I was wondering if there are any design patterns in object oriented programming that address cross cutting concerns, i.e. I'm looking for approaches that don't involve an aspect oriented language (or AOP features added to an existing OOP language). The closest I've come to so far is the decorator pattern. Say you have a class with a method called doIt. You want to log (a classic cross cutting concern) the results of this method, so you create a decorator class to wrap the original class. Inside its doIt method, it logs the results returned from the object it's decorating. Thoughts?
Leslie Sanford wrote:
I was wondering if there are any design patterns in object oriented programming that address cross cutting concerns,
As stated I doubt it. There might be a pattern for specific situations but I don't suppose it can be generalized for all situations.
Leslie Sanford wrote:
You want to log (a classic cross cutting concern) the results of this method, so you create a decorator class to wrap the original class
Nope. Not how I would do it at all. I have been doing logging for 20 years and originally I thought that very idea (logging on all methods) was a good approach. Spending that same 20 years creating back end servers and some with very high volumes I now realize that that sort of approach does not work. One must carefully place logging with careful consideration, otherwise one must deal with massive logs (hundreds of gigs daily) and be overwhelmed with non-essential data when trying to diagnose the very problems that logs exist to solve. I suspect that a database API layer where one wants logging might be a better example in that one might want to track the actual database calls. However for a case like that I would generate the API code anyways rather than trying to dynamically impose a solution.
-
I was wondering if there are any design patterns in object oriented programming that address cross cutting concerns, i.e. I'm looking for approaches that don't involve an aspect oriented language (or AOP features added to an existing OOP language). The closest I've come to so far is the decorator pattern. Say you have a class with a method called doIt. You want to log (a classic cross cutting concern) the results of this method, so you create a decorator class to wrap the original class. Inside its doIt method, it logs the results returned from the object it's decorating. Thoughts?
If you are using Castle you can wire up interceptors. http://docs.castleproject.org/[^]
ed ~"Watch your thoughts; they become your words. Watch your words they become your actions. Watch your actions; they become your habits. Watch your habits; they become your character. Watch your character; it becomes your destiny." -Frank Outlaw.
-
I was wondering if there are any design patterns in object oriented programming that address cross cutting concerns, i.e. I'm looking for approaches that don't involve an aspect oriented language (or AOP features added to an existing OOP language). The closest I've come to so far is the decorator pattern. Say you have a class with a method called doIt. You want to log (a classic cross cutting concern) the results of this method, so you create a decorator class to wrap the original class. Inside its doIt method, it logs the results returned from the object it's decorating. Thoughts?
Interesting topic. I agree with jschell. It is really hard to get the right data logged out from compiled software. It really requires a multidimensional matrix e.g. class x instance id x methods or something like that. Since, you will never get coders to insert handles in each and every method, the only viable solutions I can see are 1) a set of base classes with carefully placed handles, 2) AOP or 3) code generation. I think some OOP Patterns like Command, Stategy and State tries to structure computation in a uniform manner, so base classes supporting these patterns might be the place to add handles into. At work we make code generated Command implementations. If we have the logging level set to debug, we get a log entry when a command completes/aborts. In most cases this is information overload, so we instead raise the the General logging level to Info and add some logging exceptions per class. However, this is currently requiring a recompile.... Pattern-wise this should be possible to generalize e.g. into a LoggingManager with a configuration that can be changed at runtime. Log4Net can monitor when its config file is changed at runtime. Maybe it also can filter logging based on classes, but I don't think there is a concept filtering per entity id or method tags.