Just What I Needed
Giving your objects the functionality they need
I was a little hesitant to reuse our "Aspect-Oriented Programming" series tile on today's Feature Article, because while its approaches are in the spirit of providing "advice" to address cross-cutting concerns throughout a program, author Eric Batzdorff found AOP an unneccessaily invasive mechanism for his needs. Still, though, the motivation is similar to that of AOP developers, and the approach of developing runtime proxy objects is an interesting alternative that should be considered by anyone inclined to go down the AOP road.
The gist of his article, though, is that what works for one object in sample code may not be a suitable approach for many objects in your business logic. In the conclusion to Separating Concerns and Advising Domain Objects, he writes:
Advising objects to separate concerns is an extremely powerful pattern. Spring-like approaches to AOP are fantastic choices if few instances of the advised class need to be created. However, many domain objects do not fall in this category. AspectJ is a full-featured AOP implementation that is designed to advise both singletons and domain objects. However, AspectJ is not a trivial technology to bring into a development environment, so knowing alternatives is a good thing. For advising domain objects, we explored object pooling, class extension, and using the Decorator pattern, and there are undoubtedly others. Depending on the scenario, each approach enables a separation of concerns that object-oriented programming and aspect-oriented programming advocate.
Take a look at the approaches and see what you think -- do the AOP alternatives suit your needs to decouple your objects, and are they maintainable?
In Java Today,
the PORTIONS project, short for PORTlet actIONS, is a framework that can be used to create JSR-168 portlets in a manner similar to the development of Web applications with Struts. PORTIONS tries to offer, combining the JSR-168 specification and the JSP Model 2 Architecture, a development framework that allows to create complex portlets.
Need to go native? The NetBeans page continues its tutorial with Beginning JNI with NetBeans C/C++ Pack 5.5, Part II. "The tutorial will take you through the creation of a sample application which uses JNI to execute some native code written in the C programming language. For the Java part of the application you will use NetBeans IDE 5.5; for the C part - NetBeans C/C++ Pack 5.5.
You will start off by creating a simple Java project, adding a native method to it and then implementing this method in C using NetBeans C/C++ Pack 5.5"
Author Elliotte Rusty Harold has joined the properties debate with his explanation of What Properties in Java Should Have Looked Like: "All the proposals are vastly too complex for what little benefit they offer. They need new keywords, operators, rules, and best practices. Could we have done better? Yes. Can we still do better? Maybe. Let's find out. The proper design of properties was invented in Eiffel over a decade ago, (or possibly some other language, but Eiffel is where I first saw it) and it's really simple and obvious. All you need are public fields."