Anonymous user
Talk:Aspect oriented programming: Difference between revisions
Talk:Aspect oriented programming (view source)
Revision as of 00:03, 21 November 2011
, 12 years agoconsidering goals before refining the task
(response: when good/bad practice?) |
(considering goals before refining the task) |
||
Line 86:
:: Interesting! I have been working on the assumption that we ''do not'' want to alter the original! It would be helpful to work out under which situations this is good or bad practice...
::: I think in the case of logging it is obvious that separating this concern is useful. Other positive examples
::: When it is not useful: If it impacts the ability to debug an application, because you are looking at the code but you can't see that in fact some code defined elsewhere is being triggered. (We could argue that this problem already exists when reading Java, if you think you have problems with class X, but actually at runtime you were given buggy class Y child of X! Runtime debugging helps to unwrap these problems.)
Line 92:
::: In different frameworks the relationships with external code can be more or less obvious. For example when using plugins, a number of hooks may exist in the original code, to call any plugins which are loaded; in this case the path of execution is clear. (However the hooks might make this a less-pure example of AOP-or-whatever-we-are-calling-this.) Event driven frameworks are an alternative view, where the code triggering the event has no idea which handlers have been registered; the developer is unsure what will be executed.
::: Other than clarity when reading the code, what other issues can make this bad practice?
:: Can we conclude that the main objectives here are modularity and clarity? We want to break stuff up as much as possible, so we can separate concerns and deal with each part independently, and also remove or replace parts.▼
▲::
:: Whilst I am not seeking bad examples, I think this paradigm is useful enough that having a working method for all languages is desirable, even when sub-optimal. You may wish your application to have features that can be enabled or disabled at compile time, even if it does mean adding a lot of messy #ifdefs throughout the code! Thank you all for your feedback. --[[Special:Contributions/82.32.31.166|82.32.31.166]] 23:20, 20 November 2011 (UTC)▼
▲:: Whilst I am not seeking bad examples, I think this paradigm is useful enough that having a working method for all languages is desirable, even when sub-optimal. You may wish your application to have features that can be enabled or disabled at compile time, even if it does mean adding a lot of messy #ifdefs throughout the code!
:: Thank you all for your feedback. --[[Special:Contributions/82.32.31.166|82.32.31.166]] 23:20, 20 November 2011 (UTC)
== Updated task? ==
What should be logged, in the updated task? --[[User:Rdm|Rdm]] 10:08, 24 October 2011 (UTC)
: It would be good to refine the task. Logging may be too trivial an example to make the paradigm stand out. I like the idea of (optionally) adding a mutex around certain parts of code. Is this a rich enough example to demonstrate all the requirements we have? Other possible examples were mentioned earlier.
: Before considering the task, I will try to present all the requirements I would like to satisfy (use-cases for this paradigm):
:: Adding features to a program which can be enabled or disabled at runtime. (Ideally not polluting the original code, but sometimes unavoidable.)
:: Keeping code related to different features in a separate file/module (e.g. inheritance), or at the very least relate all the feature code using some unique identifier (e.g. #ifdefs).
:: Reducing the size of the code. Often by generalizing a common concept we can encapsulate repeated patterns in the code and reduce the overall footprint. For example, AspectJ can manipulate methods across many classes, with a few lines of code.
: Do you think we need to separate these goals, given that the first two can conflict? Perhaps clarity/modularity should be one goal, and enabling/disabling features another. --[[Special:Contributions/82.32.31.166|82.32.31.166]] 00:03, 21 November 2011 (UTC)
| |||