Anonymous
Unregistered
|
|
What about Struts and JFC paradigms?
As a generalization, I like the idea that objects are self continued little universes of completeness. But this doesn?t always work easily or well in a typically tiered system where the business logical is separated from the presentation logic and the persistence logic is separated from both. It could with judicious use of interfaces (which is how I would do this) but such an approach is certainly not common practice. Perhaps it should be, but there is a lot of traction behind frameworks like Struts which decidedly don?t follow this approach.
Discussing how not using Getters and Setters within frameworks like Struts and the
emerging Java Server Faces standard would have improved this article. The getter / setter paradigm (which if used correctly does provide a data abstraction and therefore is perfectly in synch with OO methodologies and design principles) is heavily entrenched within these frameworks ? especially Struts. Is the author saying that Struts is inherently a bad design?
Also, I don?t agree with the claim the AWT or Swing is an abstraction. If an object draws it self using the packages available from Swing that?s pretty specific even if the drawing is encapsulated.
|
Allen Holub
Unregistered
|
|
There are certainly things about Struts that make me uncomfortable. People seem to forget that Struts started out as one programmer's personal attempt at solving a problem. Struts is not a model of perfect architecture, and was never intented to be. Because Struts contains a *lot* of code that you don't have to write, and is "good enough," there is a compelling case for using it in spite of its flaws. On the other hand, saying (as you seem to---I may be misinterpreting your comments) that fundamental concepts of OO aren't reasonable because a library like Struts doesn't embody them, is I think backwards thinking.
Though I'm risking opening myself up to yet another line of attack, I'm uncomfortable with model-view-controller when used as a system-level architecture. It's been almost 30 years since MVC was concieved, and we've learned a lot since then. The main problem is what I think of as the visual-basic problem, where you have a controller (typically a frame of some sort) fielding messages from the view, and performing business logic that impacts the model. The problem is that, if the model changes, you must change all the controllers as well. Since 50 controllers might use some class in the model, modifying that class could break 50 controllers. VB is the worst case because the changes have to be made manually, without the benefit of automated tools.
Java Server Faces (and Struts to a lesser extent) is also hideously complicated, and I'm always wary of too much complexity. I really don't buy Sun's arguement that the complexity doesn't matter because the code will be machine generated. There's just too much potential for failure.
Maintenance problems like the VB problem are all too comon in Struts applications, which is not to say that you shouldn't use it. As I said earlier, it's a *lot* of code that you don't have to write. When you *do* use it though, you should be aware of its architectural shortcomings so you can program around them.
In any event, there are better architectures (such as the presentation-abstraction-control architecture described in Bushman et al's "A System of Patterns: Pattern Oriented Software Architecture") that might be worth considering if maintainablity is an important consideration.
-AIH
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
