Differences between data object's field and Java Bean property


News: Differences between data object's field and Java Bean property

  1. In the Fishbolt data model, a data field is presented by the IDataField interface. Its generic parameter T defines the type of a data field value. The IDataField interface declares setValue and getValue methods which are used to set and get the value of a data field, respectively. For example, a data field with an Integer value is presented by the IDataField interface whose setter and getter methods are used to set and get an Integer value. The life cycle of an IDataField instance is the same as the life cycle of its enclosing IDataObject instance. The value of a data field can be changed many times during its life cycle. But the data field instance itself will remain the same. A data field is declared in a data object as a constant, for example: final static FieldDeclaration name = new FieldDeclaration(); Assuming that our data object is called Department, we can make a static reference to the data field in our code using this constant: Department.name. The constant declaration defines existence of the data field (IDataField instance) in the data object instance of the corresponding type. The constant is used to access the value of the corresponding data field. The base data object interface called IDataObject declares the following method: IDataField getDataField(FieldDeclaration<T> declaration); The code to access the value of the data field presented by the name constant of the Department object is shown below: Department d = ...; IDataField dataField = d.getDataField(Depatment.name); String name = dataField.getValue(); Or you can use a shortcut method of the ModelUtil class to get the data field value as shown below: String name = ModelUtil.getValue(d,Depatment.name); In contrast to the Fishbolt data model, the Java beans-based approach doesn’t involve a separate class for a Java bean property. In other words, Java beans do not provide an object that wraps up a property value and has the same life cycle as a bean instance. Such an object may be implicitly present in developer’s mind as a property name – Java bean instance pair. But the presence of such an object in developer’s mind doesn’t allow the developer to make a reference to this object in program code. Of course, the developer can easily create a class defining the property name – Java bean instance pair. But there is a price to pay for it because such a class will make it much more expensive to change the property name or to delete the property. In program code, it's impossible to make a reference to a bean property in such a way that reference-related errors occurring as a result of deleting the property or changing its name can be detected at compile-time. (The errors became apparent only at runtime.) The reason behind the problem is that a bean property can be only referenced using a String that specifies the name of the property. You may ask: is an object-wrapper for a field value really needed? A strong argument against effectiveness of these wrappers is that they require extra memory comparing with Java beans. But the advantages of the Fishbolt data model outweigh this shortcoming. The model provides a self-descriptive and simple way of presenting a data unit (i.e. a field value) and allows users to create a variety of reusable components for data handling. With the model, it's possible to make a reference (via a static constant) to a data field before an instance of its enclosing data object is created (constants like Depatment.name don’t require for an instance of a data object to exist). This possibility allows creating whole systems that will be configured by declaring a set of constants, with correctness of references in program code being checked at compile-time. As an example of such a system, see the "User interface for the data model in Eclipse IDE" project (http://fishbolt.org/eclipse/org.fishbolt.model.eclipse/doc/plugin.article.en.html). In this project, data is bound to components of the user interface in a declarative way as described above.

    Threaded Messages (7)

  2. Why not just fields ?[ Go to top ]

    Java Bean seems to be a good pratice at first... Following the trend, you add another layer with your solution that is even more generic, ... and heavier to use. So if you really need it, because you perform some real task in the methods, why not ? (But in that case using a getter is maybe not the right solution ?) But imagine, a java class, just with public fields. You access them directly in all cases. No getters/setters to code or generate. No comment to duplicate, no unit test to perform, cleaner and shorter code... The .NET solution is far better because with property you have what you thinked about, but with a nice syntaxic sugar. You can use public fields everywere and you add the methods only when needed, that's it in pratice in 0.1% of cases. Java Bean are a good pratice, but for object that have no behaviour object at all and just contain data (aka value object), it not usefull at all. Functionnality should be exposed as small to medium services, with Value object for interraction with the service using a Facade. Then you dont need getter/setter at all, but as an old habit we still use them.
  3. You miss the point[ Go to top ]

    I think that the point of FishBolt is not to replace getter/setter but to replace field reference as a string. For example : "select foo from Department" can be rewritten "select " + Department.foo + " from Department" Then, if you rename the field 'foo' by 'bar', then you will have a COMPILE time error (field foo does not exist) instead of a runtime error saying that there is no field named "foo" on department Having said that, I do not think the overweight is needed compared to public final String foo = "foo" (you just need to remember that every time you change a field name, you must rewrite the constant exactly as you do in your example).
  4. Re: Why not just fields ?[ Go to top ]

    Just using public final fields has a major disadvantage... they can't be defined in an interface. Therefore you can't define a generic interface with a property and expect to access this property of an implementation class through polymorphic behavior. I would love a language level change to make Bean Properties more sane.
  5. fields in interface[ Go to top ]

    You can include fields in interfaces.
  6. Graph models[ Go to top ]

    This is interesting. Thanks for posting. I have been experimenting with a similar mechanism myself, but this is the first time I've heard of FishBolt. All that would be needed now is a separate repository for standard data fields and a means for attaching them to classes at design-time (or even run-time), and you would have a means for building very flexible triple-based graphs of objects. Kit
  7. EMF anyone ?[ Go to top ]

    I hate to say, but this sure looks like the Eclipse Modelling Framework to me (dynamic EMF). See http://eclipse.org/modeling/emf Ronald
  8. regarding EMF[ Go to top ]

    EMF based model also self descriptive and has similar purposes. Yes it's possible to say that EMF and fishbolt is the same thing if its possible say that bean property and data field are the same (depends on abstraction level). EMF started with java 1.2 without generics and annotations. And EMF will continue a trend of compatibility with java 1.2. Fishbolt is based on java 1.5 features. And with the features developer produces less code and evaluates more errors at the compilation stage.