Rickard Oberg and Sam Pullara are having a nice "blog chat" regarding AOP, pointcuts, and attributes. It started with Rickard's entry discussing attribute based programming versus AOP. Sam then jumped in with his own thoughts, and the conversation started.

Read:

Rickard in Attribute oriented programming and aspect oriented programming

Sam's response in Rickard doesn't understand why people want to use attributes for AOP

Rickard's reply in Re: Rickard doesn't understand why people want to use attributes for AOP

If you can read Chinese , you may look http://douleimi.vicp.net//space/2004-02-07 .

I have to agree with Sam here on this issue of using regular expressions to do matches on methods. Whether the settle() case scenario is little contrived or not, is beyond the point. It's just that the regular expression approach strikes me as a brute force technique to solving this problem. Which is not in my opinion very interesting, or powerful enough. There has got to be a more semantic based approach for doing this kind of things.

Getter/Setter are the problem. Why can't these methods be generated by the compiler behind the scenes? Have a new construct in the language that will flag your member variables as needing getter and setter. Additionally, have constructs in the language that deal with the very pattern matching tricks that coders have to resort to: universality, and existentiality

What you are asking for sounds like C# properties to me.

I don't just want to be say "generate a get and set" as that doesn't give me much. We need encapsulation, and a chance to do something OTHER than just return the value.

However, maybe we use get/set too much anyway, and we should start doing more OO design, and having methods that represent behaviour :)

Dion

> However, maybe we use get/set too much anyway, and we should start doing more OO design, and having methods that represent behaviour :)
>
> Dion

Yes, objects aka "beans" are just data structures ( analogy for "struct" in C ).
But I see it is very common and not so bad design :
 stateles services ( set of functions ) and beans ( trivial data structures for parameters ).
I use this way too and I use OO design more for infrastructure code than for "bussiness" code.


C# style properties are more useful for components as metadata, It is used for ActiveX controls, VCL components to "publish" properties. It is nice to have special keywords for metadata, but anotations in 1.5 do the same.

Method generation for "virtual field" exists in some C++ compilers too, it is nice but I do not think it is very useful feature and I see no ways how it is useful for AOP. It is more cool than useful, is not it ?

Hi all,

> I don't just want to be say "generate a get and set" as that doesn't give me much. We need encapsulation, and a chance to do something OTHER than just return the value.
> However, maybe we use get/set too much anyway, and we should start doing more OO design, and having methods that represent behaviour :)

I completely agree...
The company I recently joined is astonishing... They've been working in Java for 3-4 years and I tought them what lazy initialization is ! Enough to shock an ex-Smalltalker :-)

My opinion :
Beans lead to structs programming.
Stateless stuff (WS or EJB) lead to procedural programming.
There's no benefit in using an OO language when doing data driven programming !

And they wonder why they see no benefit in using Java...
They think they're using patterns (because of J2EE patterns, Struts framework, etc...) when they ignore what lazy initialisation is...

OO Design is here to solve problems, not code.
Software architecture is here to allow good OO design.
Stucts and static methods (or stateless services) never solved a problem, imho, except maybe the lack of experienced architects/OO gurus/good developers.

Chris

> Software architecture is here to allow good OO design.
> Stucts and static methods (or stateless services) never solved a problem, imho, except maybe the lack of experienced architects/OO gurus/good developers.
>

"good developers" can use any design to solve problem.
Software architecture is here to allow good solutions not good OO design.
OO Design is one of ways and I do not think it is the best way to solve all problems.

> Chris

Hi,

> "good developers" can use any design to solve problem.
Good *programmers* can use any design to solve problems.
Good developers choose the *right* design to solve problems.
Just because you have one solution does not mean it's the best one.
Good programmers making wrong design choices are called *hackers* in my language...

The best hacker's bubble sort will not be better than an average developer's quick sort. Still, both will solve the problem...

> Software architecture is here to allow good solutions not good OO design.
I'm not talking about choosing cool new products (which is sometimes assimilated to architecture...), but about putting cool new products at work.
Where do solutions come from ? imho, they come from good decisions, which lead to good design, then good code, which lead to high quality and satisfaction. Good architects make decisions that last long and prove right.

My current employer made good software choices : J2EE, struts, iBatis, etc... however, the system is a piece of crap... Why ? because nobody cared about making ideas work, because they took many (very) wrong decisions, because they did not design anything...
The dev process here is : create tables, create beans, create stateless EJB, create Struts action, create JSP, code until it seems to do what the requirements ask for.

Have you ever seen LOCs in the 7000 ? We have EJBs with more than 7000 LOC, methods with more than 2000 LOC...
They should have sticked to PHP, since they get no benefit for using Java...

> OO Design is one of ways and I do not think it is the best way to solve all problems.
OK, it may be better to prototype in PHP... if you're OK to throw the prototype away... which I've never seen :-)

We're clearly not looking for a silver bullet.
But you'll get most of Java's benefits if you work the OO way, because benefits (better modularization, better maintainability, cleaner design, cleaner code, better performance, better portability, name your preferred OO benefit...) must exceed drawbacks (verbosity, compiled language, tougher deployment, name your preferred java drawback...)

Choose MS Access to manage your DVDs at home, choose Java/J2EE/RDBMS to manage a library... But this choice is not enough. And JavaBeans and stateless EJBs are not going to help you much more...

My 2 cts
Chris

PS: yes, I'm a supporter of OO design, but I'm no Rose/UML addict :-) I just remember the Smalltalk days: 10 methods, 10 lines each...

quick sort is good for "random", but it is not nesesary "faster" than
any algorithm if you have preasumtions about data.
PHP is not so bad too, I found it better than JAVA for trivial web applications(hosting, productivity, easy to learn).
The same is about OOP or AOP it is not nesesary the best solution for all applications.

> any algorithm if you have preasumtions about data.

Ok... you know what I meant :-)

> PHP is not so bad too, I found it better than JAVA for trivial web applications(hosting, productivity, easy to learn).

I used Dreamweaver MX and PHP (under the hood) at home and found these quite effective ! No code written at all ! I do see real benefits in using the right technology at the right time, but Java does not seem very appropriate to me if you're not doing OO with it.

> The same is about OOP or AOP it is not nesesary the best solution for all applications.

You're right... and I believe using AspectJ without AOP (can you do this ? like C with a C++ compiler ? lol) or using Java without OOP (you CAN definitely do this) does not prove a very satisfying choice...

I said some should stick to PHP (ASP, VB, perl, name your favorite "NO WAY" language), and it was not humorous. Actually, they should, if they can't have the benefits of OO.

But the thread was about properties, beans, stateless WS/EJB, and the benefits you can expect from it...

My point is:
* if you can be satisfied with PHP/VB/ASP/perl, don't bother with Java. Using java beans and stateless ejbs would give you little more, if any
* if you need an OO language, since Smalltalk is dead, use Java :-)
* if you come from outerspace, try C++ (which I easily admit is way to complex for *me*)

Bye
Chris