> From: Mike Wilson <[email protected]> > What's your best practice when changing value object classes? > > Consider: > > myservice-api-1.0.0.jar > META-INF/MANIFEST.MF > Export-Package: myservice;version="1.0" > public interface MyService { > void doStuffWithValue(MyValue v) ... > MyValue returnValue() ... > } > public class MyValue { > String member1; > int member2; > public boolean equals(Object obj) ... > public int hashCode() ... > } > > myservice-impl-1.0.0.jar > class MyServiceImpl implements MyService { > ... > } > > Now if I need to update the implementation of MyValue's > hashCode method, what would you do?
If you are using the specification of hashCode from Object, then the specific hash value is an implementation detail. Update away and probably bump the micro version of the package/bundle. If however MyValue specifically defines how to compute the hash value from the values and you want to change that, then you make have a breaking change in your API since you have allowed people to depend upon the specific values. > - not update API version > - update API version > - wrong design, use a factory pattern for MyValue > - wrong question, you should avoid value objects altogether Value objects are fine but you should probably not specify any behavior on them because they are then more just values. See DTOs in the OSGi spec. For DTOs, we use equals and hashCode from Object. That means, object identity. > - <other suggestions> -- BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
