Hello,
it very often when I have to write code like this:
class Any{
void build(param);
}
a.build(i);
process(a);
a.build(i2);
process(a)
Is the following programming style better?
class Any{
Any build(param){ ...;returnthis;}
}
...
process(a.build(i));
process(a.build(i));
And how about? class Any {
Any build(param) {...return instance_of_any;}
}//Any
...
process(build(i));
process(build(i2));
I see (didn't read it properly. Sorry.)
Well, it depends whether you need you objects to be persistent, or not (if not, use my syntax). If so, the question is why process is not a method of the class Any too?
Could you give some little bit more narrative description (what is build, process) I'm leaving in a short time, so I will not be able to answer you today, but perhaps someone will give you the answer soon.
The build method represents here the object modification routine. After an object is modified the caller can do whatever it wants with the object processing it. Actually the the caller knows the reference to the object and it is not required to be returned but doing so allows "processing on the fly". Which considirations should I follow?
> To be clarified better: the build method is an
> analogue of constructor and is used to reconstruct an
> object without creating new one.
Yes, I thought about the parallel to a constructor too. Then, naturally, a question comes why build is not actually a part of the constructor. Do you need several such build methods?
The enxt question (still unanswered!) is the link between build and process. Mainly, why is not process a method of the class, how can you prepare an object to a state needed for an unknown method?
Anyway, let's assume this scenario: you've got 2 different methods process1, process2, and for each the object needs to be in a consistent state (secured by methods build1, build2). You know the description of the states (some common interface), but you don't know the exact implementation of process1, process2.
In such a case I would:
- create an abstract class where build1, build2 are implemented and implementation of process1, process2 is secured (e.g. by interface)
- the first step to be run in process1 is calling of build1
or
(I don't know if that's allowed)
- the abstract class actually implements all build1, build2, process1, process2. The implemetation of process1 looks likevoid process1(param){
build(param);
process1_body();
}//process1
and implementation of process1_body, process2_body is secured (e.g. by interface) - but I'm not sure whether you can use this construct (my guess: no)
In my case the object containing build(param) method is a path, like a path on the disk, but it isn't. The constructor of the path needs only the root, i.e. c:\ for forthcoming path builds. Providing the location (param), for example passing src I'm building the path c:\java\src\. Now I can move forth and back throughout these 3 locations and do whatever I want with the files on the path.
The path object mustn't know all the ways it will be processed like the Object class implements only basic set of methods.
Building is a time-consuming process, usually I can use pre-existing path and pass it for processing.
The only need to build the object is to use it afterards, right? Is it good to return this in the build method?
> Is it good to return this in
> the build method?
Look, there is no such thing as good or not good. If you want to do it that way - no problem. Personally, I would do it as I've tried to describe; i.e. using a parent class for build, constructors and all that stuff and a child class for process***. I don't like the fact that the method process stands somehow "out-of-object".
As for using this as a return parameter - if I saw it, and observed that it's the only value ever returned, I'd consider it as something strange, but again - to each according to his or her taste.
StringBuffer.append() does return this to allow constructs a la
sb.append("i : [").append(i).append("]");
Returning this is just syntactic suggar.
However, you should consider to return another object.
This might even be better in your case (see re-use of old paths).
Oh, and rename your method if you're returning this.
The name suggests the construction of a new object, but currently your modifying the existing. changePath() or so, would be better.
If your going to return a new object, build() is ok.
buildOnSameRoot() is IMHO even better.