Content deleted Content added
→Elaboration: comments about specific areas o the article that need context and/or depth. |
|||
Line 54:
:: As to the "why", I can give an answer that reflects why I use JavaBeans in my code, whether professional or personal: just to avoid the hassle of ever growing lists of parameters in function signatures. This happens when the same parameters are passed along a chain of function calls, with or without additional parameters. Adding a new piece of information at one end of the chain requires changing all signatures until the point of consumption. Above a certain number of parameters, it's just a pain to change the signatures of all functions in the chain just so that the newly added piece of information can be passed along until it is consumed. By using a JavaBean, I just have to 1- add the field, initialized to either null or a suitable default value, and its setter/getter pair, 2- set it where it becomes available and 3- consume it where it has to be used: the set of changes and file modifications if lower. That's all... although not always feasible/sensible depending on the context. So the "reusable software components for Java that can be manipulated visually in a builder tool" definition was unknown to me (and never-experienced) until I read the article minutes ago. [[User:Amenel|Amenel]] ([[User talk:Amenel|talk]]) 13:23, 15 July 2010 (UTC)
As a developer with experience mostly in .NET/C#, I find this article too vague as well, probably because it is lacking sufficient context and depth. First, it sounds to me that an important high-level implication of the JavaBean convention is that initial state is set not via constructors but via setters (which has implications for dependency injection). This is not explicitly mentioned, and might be obvious to someone who has actually built something with them, but is not immediately apparent from a cursory reading. Further, a technical justification should be given for each of the individual JavaBean requirements. Second, the phrases "manipulated visually", and "builder tool" are far too amorphous, yet they are supposed to suffice to explain the existence of JavaBeans. In what ways are JavaBeans manipulated visually? (As structural class diagrams? Couldn't source code be considered a visual representation that can be manipulated? Should this be reworded as "manipulated graphically"?) What are the advantages of visual manipulation that JavaBeans ultimately support? (Complexity management? Diagram construction to enhance documentation and communication? Rapid prototyping? Reduced learning curve of Java?) What "builder tools" are we talking about? (Eclipse? IntelliJ IDEA? javac and ant are "builder tools" but do they support the referenced "visual manipulation"? Do these builder tools inherently know what qualifies as a JavaBean through static code analysis? Is reflection involved in any of this?) Third, are JavaBeans standard practice? Are they coming into or going out of favor with mainstream developers? With leading-edge developers? Fourthly, how do JavaBeans relate to other technologies or patterns? Are they used in distributed computing? Do they support component-proxying? What is the relationship to Enterprise JavaBeans? [[User:Lunalot|Lunalot]] ([[User talk:Lunalot|talk]]) 17:10, 28 July 2011 (UTC)
== Serializable classes ==
| |||