Develop Reference

Should the "set" method(s) of a class return "void" or "boolean"?

So I run into this fairly often when I'm designing a class:
class foo {
private Bar bar;
public foo(Bar bar) {
this.bar = bar;
}
public Bar getBar() {
return bar;
}
public void setBar(Bar bar) {
this.bar = bar;
}
}
So far, so good, right? But then I think "How do I know that the user will pass an acceptable bar object? So then:
private bool validateBar(Bar bar) {
return amIgood(bar);
}
Well, of course I need to put this with the setBar function like so:
public bool setBar(Bar bar) {
if (validateBar(bar)) {
this.bar = bar;
return true;
}
else
return false;
}
Well, if that's what I need to do, then I have to include in the constructor, too, right? Except that the constructor does not have an option to return anything other than a foo object, so I try and think of workarounds, like this:
public foo(Bar bar) {
if validateBar(bar)
this.bar = bar;
else
throw Exception("Invalid bar passed along to foo");
}
Or:
public foo(Bar bar) {
if (!setBar(bar))
throw Exception("Invalid bar passed along to foo");
}
You can see how something simple went out of control pretty quickly. It's even worse if there's some sort of sanitation to do on top of the validation.
So my question is how to approach the problem of validation while keeping a class structure relatively simple?
Edit
The first example for setbar was supposed to be void but accidentally put bar, now corrected

None of the above.
Conventionally, setters return void, but may return the type of the instance (in this case Foo, not Bar) if implementing a fluent interface, in which case the setter method’s last line is return this;. (Your example is missing a return and thus does not compile).
If the parameter to a setter must be “valid”, that should not affect the return type. Rather, the method should explode:
public void setBar(Bar bar) {
if (!validateBar(bar)) {
throw new IllegalArgumentException("Bar is invalid");
}
this.bar = bar;
}
A good reason not to return boolean here is that the caller may not check the return and may blindly continue as if everything is OK, which of course would be bad.
Further, it is better to make it impossible to create an invalid Bar by moving the logic of validateBar() inside the Bar constructor, throwing an IllegalArgumentException if the parameters passed in would create an invalid Bar, then you could remove the check from Foo.
If the validateBar() method is static it means the a Bar can be validated without the context of a Foo, so the logic should be implemented in Bar - Foo should not have the responsibility or knowledge of how to validate a Bar if it doesn't need to.
However, if Foo has special requirements for a valid Bar that doesn't apply elsewhere, create a subclass of Bar, eg FooBar extends Bar, that implements Foo's special validation requirements, again in its constructor.
If validating a Bar does need the context of a Foo to validate, and reusing Bar instances between Foos is not required, then the Bar class should be an inner class of Foo, in which case the validation can still be in the Barconstructor, and the state of the containingFoo` is available to the validation logic as required.
If validating a Bar needs the context of a Foo to validate, and reusing Bar instances is required, then Bar cannot be an inner class and the validation code should live in Foo as you have suggested with your validateBar(Bar bar) method, except it wouldn't be static so the method would have the fields of Foo to use.
Also, consider re-naming it validate(Bar bar), since the type of the parameter makes it clear what is being validated.

Returning an immutable reference to a mutable object in Java

Basically, I have a mutable object in Java and its state is both accessed and modified by several methods of a certain class. The data stored in the object is also used by another class, but the difference is that the second class should not be allowed to modify the data, just to use it.
In C++, I would normally just pass a const reference to the object at hand, but I realize that there is no direct equivalent in Java.
Just to clarify, the following code snippet shows what I have in mind:
public interface Figure
{
void onSizeChanged(SizeInfo info);
void draw();
}
public class FigureView extends View
{
private Figure figure;
private SizeInfo sizeInfo;
...
public void onResize()
{
//Modify the state of sizeInfo, then pass it to the figure.
figure.onSizeChanged(sizeInfo);
}
}
Let's say that SizeInfo is a large object, so I don't want to make a memberwise copy, but just pass it by reference. The code above succeeds in allowing any Figure to access the data of the SizeInfo object, but it also allows the Figure to modify the object. Errors caused by such behavior may be hard to track, so I want to pass an 'immutable reference' to the SizeInfo.
The best solution I have found so far is to create an non-static inner class of SizeInfo which only consists of getters:
public class SizeInfo
{
//These represent the large set of data inside the class.
private long foo;
private double bar;
private Export mExport = new Export();
//Setters (only available if you have a direct reference to SizeInfo):
public void incrementFoo()
{
foo++;
}
public void setBar(double bar)
{
this.bar = bar;
}
//SizeInfo getters:
public long getFoo()
{
return foo;
}
public double getBar()
{
return bar;
}
public double getBaz()
{
return bar * foo;
}
//A non-static inner class:
public class Export
{
public long getFoo() { return foo; }
public double getBar() { return bar; }
public double getBaz() { return bar * foo; }
}
public Export export() { return mExport; }
}
With this code, you only have to change the method signature in Figure from onSizeChanged(SizeInfo) to onSizeChanged(SizeInfo.Export) and pass sizeInfo.export() to the method instead of sizeInfo to make it work as expected. This is very easy to use from the client side, but the code redundancy caused by having to repeat each getter twice is definitely not elegant. The alternative of placing the getters only in SizeInfo.Export and replacing each sizeInfo.getBaz() with sizeInfo.export().getBaz() is even worse. That is why I am looking for a more elegant approach.
I realize that this particular example might not be believable in terms of SizeInfo being too big to just create a memberwise clone. However, there are countless other examples. For instance, if I had a mutable object representing the ARGB data of an image (perhaps due to the image being generated pixel by pixel with the use of some mathematical formulas), and then wanted to pass it to a method which should not be able to modify it, the problem would still appear.

You could create an interface, say SizeInfoView, which contains only the getters. Then SizeInfo would implement that interface, but add setters as well. Figure would only receive a reference to the SizeInfoView interface. The caller can of course still downcast to a SizeInfo, but you'd have the same issue in C++ with const_cast. It's usually good enough to prevent accidents.
Bear in mind, though, that you're getting an unmodifiable object, not an immutable object. The difference is that somebody else could modify it, and the changes would be reflected in the unmodifyable view. But again, the same is true for C++ const references.

Create a ReadOnlySizeInfo interface containing the getters, make SizeInfo implement that interface, and pass the interface instead of SizeInfo to onSizeChanged().
You will still pass a mutable object, but the Figure doesn't know about it: all it knows about what it receives is that it's a ReadOnlySizeInfo. It could still cast and mutate the object, but that wouldn't be a bug anymore: it would be an evil behavior.

Is creation of new object thread safe

Is method getCopyOf in following code thread-safe in java ?
I am not sure if construction of object is atomic operation.
public class SomeClass {
private final String arg1;
private final String arg2;
public SomeClass(String arg1, String arg2){
this.arg1= arg1;
this.arg2 = arg2;
}
public SomeClass getCopyOf() {
return new SomeClass(this.arg1,this.arg2);
}
public String getArg1(){
return arg1;
}
public String getArg2(){
return arg2;
}
}

In your example yes, String being immutable and not accessible then your constructor will be thread safe.
However if you replace the string with an arbitrary object (say another class) and have setters for these objects then you may run into problems regarding thread safety. So in a more general answer to your question, no, constructors, like any other methods, offer no explicit thread safety mechanism it is up to you to make sure your operations are thread safe.
Even worst should your class contain static fields then the constructor itself may have thread safety problems with itself.

It is thread safe until you delegate the this reference from the constuctor. After that it is no longer thread safe.
public class MyClass {
public MyClass(Object someObject) {
someObject.someMethod(this); // can be problematic
}
}
This is just one example I think you can imagine some scenarios where thread safety issues can occur.
Related: Constructor synchronization in Java

Synchronize write access to Volatile field (Cheap read-write block)

Let's say I have the following class that will be read heavily, but only written to occasionally. It will be used in a multi-threaded web app, so it needs to be thread safe:
public class Foo {
private volatile String foo;
public String getFoo() {
return foo;
}
public synchronized String setFoo(String in) {
this.foo = in;
}
}
Java Concurrency (http://www.ibm.com/developerworks/java/library/j-jtp06197/index.html) states that this is a fragile way to protect write access while improving read access. What is a stronger alternative to this pattern? Or any alternative if foo will need to mutable in a read-heavy environment? Thank you.

Volatile provides fast thread-safe lock-free access to a field without synchronization
private volatile String foo;
public String getFoo() {
return foo;
}
public void setFoo(String in) {
this.foo = in;
}
volatile solves 3 problems 1) memory visibility 2) atomic writes for double and long fields 3) forbids instructions reordering. But it's not enough if you need several operations over a field as one atomic transaction, such as increment. This code is broken
private volatile int id;
public void incrementId() {
id++;
}
because if 2 threads simulataneously read and increment it and save the result then the result of the first increment will be overwritten with the result of the second increment. To prevent this from happening we need to use synchronization
private int id;
public synchronized int nextId() {
return ++id;
}
or java.util.concurrent.atomic package
private AtomicInteger id = new AtomicInteger();
public void incrementId() {
return id.incrementAndGet();
}

If all you are doing is setting foo, then you don't need to synchronize the method. making the reference volatile is sufficient.

At the link you said there is this code for "infrequent updates" usage:
#ThreadSafe
public class CheesyCounter {
// Employs the cheap read-write lock trick
// All mutative operations MUST be done with the 'this' lock held
#GuardedBy("this") private volatile int value;
public int getValue() { return value; }
public synchronized int increment() {
return value++;
}
}
The increment method is only using synchronized because it is doing more than just setting the value of value as stated in the description, if all you are doing is this.foo = in; that is atomic.
In the text the "fragility of this pattern" means things can get messy very fast when you mix volatile and other synchronization methods to do more than just simple examples.
See package java.util.concurrent.locks for the interfaces Condition and Lock and the class ReentrantLock. I think that, and using synchronized is what the author means by "stronger alternatives". You should also see Object.wait, Object.notify and Object.notifyAll if you don't know that yet.

java thread safe code + an atomic method question

I have a class Manager that is going to be accessed by multiple threads at the same time, I want to know if I did it the right way ?
also I think I need RemoveFoo to be atomic, but I'm not sure
public class Manager
{
private ConcurrentHashMap<String, Foo> foos;
//init in constructor
public RemoveFoo(String name)
{
Foo foo = foos.Get(name);
foo.RemoveAll();
foos.Remove(name);
}
public AddFoo(Foo foo)
{...}
}
public class Foo
{
private Map<String,Bar> bars;
//intialize it in constructor
//same for RemoveBar
public void AddBar(Bar bar)
{
synchronized(this)
{
bars.put(bar.id, bar);
}
}
public void RemoveAll()
{
synchronized(this)
{
//some before removall logic for each one
bars.remove(bar.id, bar);
}
}
}
public class Bar
{}

You do not need synchronised methods as you are using a ConcurrentHashMap, however be aware that Foo foo = foos.Get(name) could return null as another thread could already have removed the entry from the map.
Members can be declared as Map<String, Foo> foos, but must be initialsed as foos = new ConcurrentHashMap<String, Foo>;

RemoveFoo could be problematic. I suggest to use:
Foo foo = foos.remove (name);
if (foo != null) foo.removeAll();
instead. This makes sure that the map doesn't change between get() and remove().
In Foo, it's enough to synchronize on bars instead of the whole instance. But that's just a minor optimization.

Declare RemoveFoo(String) as synchronized:
public synchronized void RemoveFoo(String name) {
…
}
Also, be advised of the following:
method names should be lower case, e.g. removeFoo instead of RemoveFoo. This is not C#. :)
Every method needs a return type: public removeFoo() is not a valid method declaration, it needs to be public void removeFoo().

If you use a concurrentHashMap in Foo like
private Map<String,Bar> bars = new ConcurrentHashMap<String, Bar>();
maybe you can do away with the synchronization in Foo as well.

I am not sure what you are going to do on Foo and Bar, but it looks like a pattern of deallocation.
If they are not referenced by others, just call foos.Remove(name); and let GC engine handle the deallocation.