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.
codetopics@digisolutions.com
|
Anonymous
Unregistered
|
|
There are two questions that you are asking here. The first is about Struts. Keep in mind that popularity does not necessarily translate into good design at all -- consider Visual Basic for example.
Personally, I do not think Struts has much OO in its concept for a simple reason: you have to design the UI of an entire page, and you cannot separate that into logical pieces. Consider AH's example: if you display a person (employee, user, etc) as a the person's name today, but need to change that to the person's name + identification number tomorrow, you have to go through ALL Struts pages that display a person to make that change. And if that changes to name, number, and picture, you have to do it yet again. This is an excellent example as to why MVC may not be OO at all if not implemented properly.
JSF is a step in the right direction, but it goes the other Away -- components (the equivalent of visual classes) are extremely hard to build if you are not an expert and there is no clear separation between the java code and what needs to be rendered. As a result, you get lots of HTML embedded in the java code. I would suggest using something like Tapestry (http://jakarta.apache.org/tapestry/) for Web UI, since it avoids all of the pitfalls described.
With respect to the separation between model and view and that AWT or Swing are not really abstraction, I have to partially agree. This is especially clear when you want to have, say, Swing, SWT, and Tapestry views. The way to do it is to have a model class (abstraction with data and logic) and three different view (presentation) classes. Whenever you need to present the object in some way, you ask the model to provide you a view of the type you need, it picks the correct view class, instantiates and initialzies it, and returns it. (There are multiple ways to organize your program in such a way that you can package only the Swing stuff, for example, without having to ship the SWT or servlet jars).
Please note that the coupling between the views and the model of that object is relatively high -- this is okay, since all those classes represent the same conceptual object. The coupling between the object is much reduced, however, since it does not have to know much about the object at all. In this way you get an excellent model/view (abstraction/presentation) separation, and still preserve the encapsulation the object. You only need to touch a single place to provide the change describe above, rather than 100 places as with the simplistic MVC approach.
|
Anonymous
Unregistered
|
|
Sorry, I guess I have deleted some stuff by mistake. My last part meant to say:
The coupling between the object AND THE REST OF THE SYSTEM is much reduced, however, since it does not have to know how to present the object at all.
|
Anonymous
Unregistered
|
|
How many successful desktop applications have been delivered using Visual Basic vs Java? Good design may not lead to popularity (look at Betamax) but success does.
|
Anonymous
Unregistered
|
|
There is a huge market for small, simple, "rough-around the edges" applications that do not need maintenance (or so people think). These things are thrown away after they are used because it is extremely hard to change them, especially by someone else. This is the market where VB, PHP, etc. excel. I personally call it the "easy now, difficult later" market. Since using these technologies does not require much skill, a lot of people can get into the supply side of it and can produce things on the cheap.
If you are satisfied with the low-margin low-salary work like that, by all means, go ahead. If you want to work on large projects in companies with longer-term view that are much more beficial (both intellectually and financially) and be successful, what AH is saying is a must to know and apply.
Note that there are not many of these projects around done in VB...
|
|
Previous
Index
Next
Threaded
Edit
Reply
Quote
