I need to write a function which returns a string which should be unique for each state of the object.
i.e. if any of the instance variables are changed, then this method should return another string which should be unique for the given set of instance variables of object.
Similarly I would later require write another method which represents unique static state of the class.
Please suggest any efficient ways to achieve my requirement.
Thanks,
Harish
If you want to track the changes to a given object's state (in its own boundary), this is achievable with a bit of coding or adopting an already implemented approach. Is that what you are asking? What does make using an incrementing serial number inappropriate in your case?
If you are about to guarantee uniqueness amongst all the existing instances of a given class, this is a bit hard. You might need to distinguish an object individually, then asking each object for their unique string representation.
I'd recommend reading about Object.hashcode(). The ideas recommended for hashcode generation could be used for the purpose you want.
You can use Java reflection to find all the fields in your class and work from there:
public String tos() throws IllegalAccessException {
StringBuilder b = new StringBuilder();
for (Field f : getClass().getDeclaredFields()) {
f.setAccessible(true);
b.append(f.get(this));
}
return b.toString();
}
A fairly naive approach would be to serialize the object to memory and take a secure hash of the content. Quite inefficient but it works with any serializable object.
What are the requirements exactly?
Do nested objects also affect state (or is this applicable)? if a.b.c changes does this affect state of a?
Do two different objects with the same content have to end up with the same string?
Related
If I create an immutable class. All the fields have to be final. If I use stringbuilder in that like this
final StringBuilder s = new StringBuilder("Hello ");
, then the append function can append the value of the s and the class wont be immutable. Please advice.
It's "shallow-immutable" in that you can't change the fields themselves, but it's not fully immutable - which means you lose pretty much all the benefits associated with immutability.
Basically to achieve immutability, all the constituent parts must either be naturally immutable, or sometimes you can get away with using something which is mutable but a) you constructed it, so nothing else has a reference to it; b) you never expose a reference to it; c) you never mutate it yourself.
For example, you can write an immutable type that uses java.util.Date (although I'd strongly recommend using java.time) - you'd just need to make sure that if you ever wanted to return a date from a method, you cloned it instead of returning the value of the field.
I'm writing a program with a bunch of classes that will be serialized to save in a database and to be sent through a network.
To make things easier for accessing the class properties via command line interface, I'm considering storing the properties in a Map class, instead of giving each property it's own variable.
Basically, instead of using something like this:
String id = account.getUserId();
I would do this
String id = account.properties.get("userId");
Is this an advisable way to do things?
Yes, it's a pretty sensible model. It's sometimes called the "prototype object model" and is very similar to how you would work in JavaScript where every object is effectively a Map. This in turn has led to the very popular JSON serialisation format.
Nice features:
You don't have to worry about messy inheritance heirarchies - you can just alter the properties at will.
You can create a new object just by copying from another object (the prototype)
Code to manipulate the data can do so in a uniform way, without having to explicitly name all the variables.
It's more "dynamic" compared to a static class definition - it's easy to extend and modify your objects
Potential risks / downsides:
You need to keep track of your property names if you use Strings - the compiler won't do it for you! This issue can be alleviated by using Enums as keys, but then you lose some flexibility...
You don't get the benefits of static type checking, so you may find that you need to write more JUnit tests as a result to ensure things are working properly
There is a slight performance overhead (though probably not enough to worry about, as map lookups are very fast)
I actually wrote an entire game in the 90s using a variant og this object model (Tyrant) and it worked very well.
Rather than having a Map object exposed however, you may want to consider encapsulating this functionality so that you can use an accessor method on the object itself, e.g.
String id = account.getProperty("userId");
How I prefer to do this is often like this:
enum StringPropertyType {
USERID, FIRSTNAME, LASTNAME
}
interface StringAttributes {
String get(StringPropertyType s);
void put(StringPropertyType s, String value);
}
class MapBasedStringAttributes implements StringAttributes {
Map<StringPropertyType, String> map = new HashMap<~>();
String get(StringPropertyType s) { return map.get(s); }
void put(StringPropertyType s, String value) { map.put(s,value); }
}
this gives you compile-time safety, refactoring, etc.
you could also use the stringPropertyType.name() to get the string representation of the enum value and use
Map<String,String>
instead..
I'm using ehcache (via the Grails plugin). The method that adds objects to the cache requires the keys to be serializable, so a typical usage would be:
def key = 22
def someObject = new Object();
cacheService.cache(key, true, someObject)
(The boolean param indicates whether the object should be added to a distributed or local cache)
My question is how I should go about generating keys from value objects such as:
class Person implements Serializable {
String firstName
String lastName
Integer age
}
One approach would be to provide a hashCode() and equals() methods and use the hashCode as the key. In this case, I wouldn't need to make the Person class implement Serializable.
Alternatively, I could simply use the Person object itself as the key. It seems like I would still need to provide the equals and hashCode methods but would also need to implement Serializable. However, there would seem to be a smaller chance of collisions using this approach because a Person can only be equal to another instance of Person.
I'm assuming that ehcache uses the equals() method of a key to determine whether that key already exists in the cache, is this assumption correct?
Is either of the approaches outlined above intrinsically better than the other, or is there another approach that I haven't considered?
Thanks,
Don
Your hashkey question is mostly orthogonal to the serializable question. In answer to the hashkey, I'd use the Apache Commons HashCodeBuilder. It does all of the heavy lifting for you. Similarly with equals, use the EqualsBuilder.
Remember though, hashcodes need to stay the same over the lifespan of the object, so only hash those internal elements that won't change.
I'd avoid using the Person object as the key as that'll call it's equals() to check key comparisons, which is likely slower than comparing an integer hashcode.
I had read in some design book that immutable class improves scalability and its good practice to write immutable class wherever possible. But I think so immutable class increase object proliferation. So is it good of going immutable class or better go for static class (A class with all the methods static) for improve scalability ?
The main benefit of immutable classes however is that you can expose internal data members that are immutable because the caller can't modify them. This is a huge problem with, say, java.util.Date. It's mutable so you can't return it directly from a method. This means you end up doing all sorts of defensive copying. That increases object proliferation.
The other major benefit is that immutable objects do not have synchronization issues, by definition. That's where the scalability issues come in. Writing multithreaded code is hard. Immutable objects are a good way of (mostly) circumventing the problem.
As for "static classes", by your comment I take it to mean classes with factory methods, which is how it's usually described. That's an unrelated pattern. Both mutable and immutable classes can either have public constructors or private constructors with static factory methods. That has no impact on the (im)mutability of the class since a mutable class is one whose state can be changed after creation whereas an immutable class's state cannot be changed after instantiation.
Static factory methods can have other benefits however. The idea is to encapsulate object creation.
Immutable classes do promote object proliferation, but if you want safety, mutable objects will promote more object proliferation because you have to return copies rather than the original to prevent the user from changing the object you return.
As for using classes with all static methods, that's not really an option in most cases where immutability could be used. Take this example from an RPG:
public class Weapon
{
final private int attackBonus;
final private int accuracyBonus;
final private int range;
public Weapon(int attackBonus, int accuracyBonus, int range)
{
this.attackBonus = attackBonus;
this.accuracyBonus = accuracyBonus;
this.range = range;
}
public int getAttackBonus() { return this.attackBonus; }
public int getAccuracyBonus() { return this.accuracyBonus; }
public int getRange() { return this.range; }
}
How exactly would you implement this with a class that contains only static methods?
As cletus said, immutable classes simplify class design and handling in synchronized methods.
They also simplify handling in collections, even in single-threaded applications. An immutable class will never change, so the key and hashcode won't change, so you won't screw up your collections.
But you should keep in mind the lifecycle of the thing you're modeling and the "weight" of the constructor. If you need to change the thing, immutable objects become more complex to deal with. You have to replace them, rather than modify them. Not terrible, but worth considering. And if the constructor takes nontrivial time, that's a factor too.
One thing to consider: If you intend to use instances of a class as keys in a HashMap, or if you're going to put them in a HashSet, it's safer to make them immutable.
HashMap and HashSet count on the fact that the hash code for an object remains constant as long as the object is in the map or set. If you use an object as a key in a HashMap, or if you put it in a HashSet, and then change the state of the object so that hashCode() would return a different value, then you're confusing the HashMap or HashSet and you'll get strange things; for example, when you iterate the map or set the object is there, but when you try to get it, it's as if it is not there.
This is due to how HashMap and HashSet work internally - they organize objects by hash code.
This article by Java concurrency guru Brian Goetz gives a good overview of the pros and cons of immutable objects.
Immutability is generally used to achieve scalability, since immutability is one of the enablers when it comes to concurrent programming in java. So while, as you point out, there may be more objects in an "immutable" solution, it may be a necessary step to improve concurrency.
The other, equally important use og immutability is to consume a design intention; whoever made an immutable class intended you to put mutable state elsewhere. If you start mutating instances of that class, you are probably breaking the original intention of the design - and who knows what the consequences may be.
Consider string objects, as an example. Some languages or class libraries provide mutable strings, some don't.
A system that uses immutable strings can do certain optimizations that one with mutable strings cannot. For example, you can ensure that there is only one copy of any unique string. Since the size of the object "overhead" is generally much smaller than the size of any non-trivial string, this is a potentially massive memory savings. There are other potential space savings, like interning substrings.
Besides the potential memory savings, immutable objects can improve scalability by reducing contention. If you have a large number of threads accessing the same data, then immutable objects don't require elaborate synchronization processes for safe access.
Just one more consideration about the subject. Using immutable object allow you to cache them and not re-create them everytime (ie Strings) it helps a lot on your application performance.
I think, if you want to share the same object among different variables, it needs to be immutable.
For instance:
String A = "abc";
String B = "abc";
String object in Java is immutable. Now both A & B point to the same "abc" string.
Now
A = A + "123";
System.out.println(B);
it should output:
abc
Because String is immutable, A will simply point to new "abc123" string object instead of modifying the previous string object.
Let's say you have two instances of the same bean type, and you'd like to display a summary of what has changed between the two instances - for example, you have a bean representing a user's settings in your application, and you'd like to be able to display a list of what has changed in the new settings the user is submitting (instance #1) versus what is stored already for the user (instance #2).
Is there a commonly used algorithm or design pattern for a task such as this, perhaps something that can be abstracted and re-used for different types of beans? (I'm having a hard time thinking of a good name for this type of problem to know what to Google on). I've checked commons-beanutils and nothing popped out at me.
If you are talking about comparing values, I would consider using reflection and just comparing them field by field.
Something like this:
Field[] oldFields = oldInstance.class.getDeclaredFields();
Field[] newFields = newInstance.class.getDeclaredFields();
StringBuilder changes = new StringBuilder();
Arrays.sort(oldFields);
Arrays.sort(newFields);
int i = 0;
for(Field f : oldFields)
{
if(!f.equals(newFields[i]))
{
changes.append(f.getName()).append(" has changed.\n");
}
i++;
}
This code hasn't been tested. You might need to get the values in the fields and compare them instead of just comparing fields to each other, but it should work in theory.
The reflection not mantains the order of the Field in next calling: it's safier order the arrays.
/*
*declarations of variables
*/
Arrays.sort(oldFields);//natural order - choice 1
Arrays.sort(newFields, new Ordinator());//custom Comparator - choice 2
/*
*logic of comparations between elements
*/
In choice 2 you can decide the logic of sorting (HOW SORTING THE ELEMENTS) with an inner class Ordinator extending Comparator.
PS the code is a draft
We've done something similar with bean utils and it worked well. Things to consider: Do you drill down into field objects - If a Person contains an Address and the address changes do you say the address changed or that address.postalCode changed(we do)? Do you return a list propety name, old value, new value from the diff (we do)? How do you want to handle dates - if all you care about is date part then your comparison should ignore the time? How do you say which fields to ignore?
This isn't really a copy and paste answer but more of list of things that weren't immediately obvious when we wrote our differ.
As for implementation, we just have a static util method that takes two beans and a list of properties to compare and then returns a map of properties to a Pair containing the old value and the new value. Then each bean has a diff(Object o) method that calls the static util method as needed.
These libraries should help.
https://code.google.com/p/beandiff/ - An annotation based bean diffing library. Apache License 2.0
https://github.com/SQiShER/java-object-diff/ - A bean differ based on Visitor pattern. Apache License 2.0
We had a requirement to generate difference between beans in json format for auditing purpose. We ended up implementing it using beandiff library.
** EDIT **
This looks like a newer option. I have not used it though.
http://beandiff.org/
Hope it helps.
Good answers above.
If your data changes structurally, i.e. whole collections of fields may be relevant or not depending on others, you might want to consider differential execution.
Basically, you have a loop over the fields, and you serialize the current field values at the same time as you deserialize the prior values, comparing them as you go.
If there is a conditional test that makes a block of fields relevant or not, you serialize/deserialize the true-or-false value of the conditional test, and use that to decide whether or not to serialize and/or deserialize the affected fields. And it recurs nicely.
Just a suggestion.
Solution using reflection and standard data structures.
Field[] declaredFields = ClassOne.class.getDeclaredFields();
Field[] declaredFields2 = ClassTwo.class.getDeclaredFields();
ArrayList<String> one = new ArrayList<String>();
ArrayList<String> two = new ArrayList<String>();
for (Field field : declaredFields)
{
one.add(field.getName());
}
for (Field field : declaredFields2)
{
two.add(field.getName());
}
List<String> preone = (List<String>)one.clone();
one.removeAll(two);
two.removeAll(preone);
Collections.sort(one);
Collections.sort(two);
System.out.println("fields only in One : " + one);
System.out.println("fields only in Two : " + two);