Re: Aspect questions?
On 02/24/2012 09:47 PM, Novice wrote:
Lew<noone@lewscanon.com> wrote in news:ji8u23$f6m$1@news.albasani.net:
Novice wrote:
Is this a reasonable place to ask questions about AspectJ?
Isn't that one right there?
Does it seem reasonable to you?
I'm just getting started with it and it's not going really well so
far. I'm imitating simple examples from the manual and they just
don't work. I'm not sure what I'm messing up....
I don't recall ever seeing anyone ask aspect-oriented questions but I
certainly don't read every thread or even every subject line so I
could have missed some....
Since this is a newsgroup devoted to the Java programmer and AspectJ
is a Java programming tool, yes, of course this is the right forum.
Aspect programming is an advanced, hairy and special-purpose
discipline. Are you just learning it for the sake of learning it, or
are you contemplating a project use for it?
Hey, I'm just making sure this is an appropriate place to ask before I
take the time to lay out my problem. This seems like a reasonable place
to ask but the rest of the group may not agree....
"Doctor, I have a problem," is a very limited request. We aren't sure
what you're messing up either.
Obviously. I haven't asked a specific question yet. I wanted to be sure
there was no major objection before laying out the issue.
There are some areas of Java programming that are almost never needed
at the application level, but are quite useful for framework
development. They include advance JavaBeans stuff like BeanInfo
properties descriptors, reflection beyond 'instanceof' and
'Class.newInstance()', class loader magic and aspect programming.
Given your handle in this group, you might want to learn other things
in Java first before tacking aspect programming.
There are dozens of things I'd like to learn about Java and I probably
need to learn several of them first.
What is your use case for aspect programming?
Based on other answers to my question, maybe I _don't_ want to learn
AspectJ!
I wouldn't advise against learning it.
I do advise laying a good foundation. Certain advanced topics are
foundational, and you don't need to be linear and do nothing interesting.
For example, every Java programmer should understand serialization and have a
basic grasp of non-trivial reflection. More importantly, understand where the
various topics apply so you don't deploy them where they don't serve well.
I saw a seminar about aspects a couple of years back and thought it
sounded quite intriguing. It struck me that aspects might be a very good
They are and would be.
way to handle what I am currently trying to do. But maybe there are
better ways. So let me lay out what I'm trying to accomplish and maybe
you can suggest a better approach.
Very wise and balanced approach, that.
I'd like to make both localization and logging a part of every class that
I write. The localization would allow each class to display text in any
(supported) language that the user requests and I'm also thinking of
localizing the messages in exceptions that get displayed or written to
logs. It seems like logging is the standard way to go for writing and/or
displaying messages to the user and to logs.
The widespread practice for l10n (because you omit ten characters from
"localization") are
<http://docs.oracle.com/javase/7/docs/api/java/util/ResourceBundle.html>
<http://docs.oracle.com/javase/7/docs/api/java/util/Properties.html>
[snip]
By the way, I found another place to ask AspectJ questions and the issues
I had when I first posted here are now resolved. But the bigger issue
remains: are aspects a good approach for what I want to do? If not, what
would be a better strategy?
You ask great questions.
I18n ("i[nternationalizatio]n") and l10n are most likely best handled with
resource bundles and properties. There is a lot of lore around that approach,
and it's just as flexible as aspects.
Logging is a great use case for aspects. However, there are alternatives to
lessening logging's overhead, too. You have to weigh costs and benefits.
It's not just in the code you weigh. Frameworks have a deployment cost. It's
harder to deploy than to write code. Framework bloat is a major problem in the
real world. Aspects also reduce visibility into areas, sometimes a good thing
and others not.
Locale management is best done in plain sight, IMO. You still have single code
points that translate automagically, so that's OK.
Aspects are to hide things from the code. Great, if you don't mind hunting for
them when you need them. XML configuration files can suffer this problem, too.
Too much externalization is bad just like too little.
I use code templates to handle logging. My editor autoinserts logging stuff
into new source files. That's enough for my laziness. Besides, the logging
statements help document the code, done right.
So where /should/ you use aspects? Hmm.
Like I say, you ask great questions.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg