This question already has answers here:
WITH statement in Java
(8 answers)
Closed 8 years ago.
In VB / VBA you can do something like this:
With person
.Name = "John"
.Age = 32
End With
But in java I can't figure out how or if that functionality exists. Everything I see seems to just repeat the object references, like this:
person.setName("John");
person.setAge("32");
If it doesn't exists, is there at least some methodology to cut down on the repetition?
If it doesn't exists, is there at least some methodology to cut down on the repetition?
Nope, not really - not unless you control the type.
If you do control the type, you can make the set methods return this, allowing you to chain the method calls. This is often useful for builder types:
Person person = Person.newBuilder().setName("John").setAge(32).build();
(You can just make your types mutable rather than separating builder types from immutable non-builder types, but I'm just a fan of immutability...)
Related
This question already has answers here:
How do I use optional parameters in Java?
(17 answers)
Closed 1 year ago.
I need to have method that accepts let say 3 input parametars.
Calculate_Salary(int ratio, int vocationDays, int travelDays)
Many of the people do not travel, and rearly use vocation days in that case I want to call the functions in the best way (let say like in C++ only with one parametar, and other two will have default values)
There are planty of way to implement it I know (call method with zero values, overload it, implement default valuses in the body of method ). And note. it is simple with ints, it is more complex with the objects.
Calculate_Salary (ratio)
Which is the safest and fastest soulution, and is there something "new" in Java that can make this happen easy?
Thanks
As far as I know there is no solution that makes it really easy. But overloading is by far the best implementation you can do, moreover it is really easy, therefore I would go with this.
Moreover you do not need to implement a whole new function, simply call the first method with the default parameters you want.
This question already has answers here:
What does it mean to "program to an interface"?
(33 answers)
Closed 5 years ago.
I was a bit confused, when we use
List<String> lst = new LinkedList<>();
when we use
LinkedList<String> lklst = new LinkedList<>();
At the beginning, I thought they are the same, but today, I realized they are not the same. For example, if I call lst.getFirst() It will tell me there is a error. However, if i do lklst.getFirst(), it works fine. My question is when do we use lklst then? why they are different? Also, does it apply same rule for Map. THanks!
On the left hand side you're declaring the type of the variable, lst. Since lst's type is List you can only access methods of a List, even if the object lst points to is really a LinkedList. There's an inherent tradeoff between declaring a variable of a concrete type like LinkedList (access to more methods / behavior) vs. a more abstract interface (safer, better compartmentalized code).
This is a big topic, and there isn't one simple answer for when to do one vs. the other (though there's lots of advice out there about it!) - you'll need to figure out which is appropriate for your use case.
Effective Java - Item 52: Refer to objects by their interfaces is a pretty canonical citation for this issue, and as the title implies suggest preferring List rather than LinkedList.
This question already has an answer here:
Why can't Stream.flatMap accept a collection?
(1 answer)
Closed 5 years ago.
Currently, to convert a List<List<Foo>> to a Stream<Foo>, you have to use the following:
Stream<Foo> stream = list.stream().flatMap(fs -> fs.stream());
//or
Stream<Foo> stream = list.stream().flatMap(Collection::stream);
I think this is exactly what the method references were designed for, and it does improve readability quite a bit. Now consider this:
Stream<Bar> stream = list.stream().flatMap(fs -> fs.getBarList().stream());
Having two chained method calls, no method reference is possible, and I've had this happen to me a few times. While it is not a big issue, it seems to drift away from the method-reference brevity.
Having worked with JavaFX 8 a bit, I noticed that a constant of their API's is the convenience methods. Java is a very verbose language, and it seemed to me that simple method overloads were a big selling point for JavaFX.
So my question is, I wonder why there is no convenience method Stream.flatMap(Collection) that could be called like:
Stream<Bar> stream = list.stream().flatMap(Foo::getBarList);
Is this an intentional omission by the folks at Oracle? Or could this cause any confusion?
Note: I'm aware of the "no-opinion-based-questions policy," and I'm not looking for opinions, I'm just wondering if there is a reason that such a method is not implemented.
Because Stream is already a pretty big interface and there's resistance to making it bigger.
Because there's also the workaround list.stream().map(Foo::getBarList).flatMap(List::stream).
You can also see the original discussion at http://mail.openjdk.java.net/pipermail/lambda-libs-spec-observers/2013-April/001690.html ; I'm not seeing that option specifically discussed; it may have been discarded already at that point?
This question already has answers here:
Is there a difference between explicitly putting the type into the diamond operator vs letting java figure it out?
(4 answers)
Closed 5 years ago.
What is purpose of re-specifying the type on the right / constructor side of a Java Collection declaration + instantiation?
For example, how is
List<MyClass> a = new ArrayList<MyClass>();
different / better / worse than
List<MyClass> a = new ArrayList<>();
My understanding is the the second form became legal in Java 7, but I still see a lot of examples in Java 7 and 8 where the first form is used.
It is not worse or different. It is the same.
A new and easy way introduced by compiler to reduce human effort of defining of type.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
What's the best way to refactor a method that has too many (6+) parameters?
If a constructor has a long parameter list, should we consider it bad style and refactor it? If yes, how?
Consider using a Builder. Instead of having a constructor where some of the parameters can be null:
Foo foo = new Foo(name, id, description, path, bar);
And instead of telescoping constructors - i.e. making one constructor for each combination of parameters, you can have:
Foo foo = new FooBuilder().setName(name).setPath(path).build();
It may be an appropriate set of parameters, but a lot of the time my answer would be yes. Break the parameters into a logical subgroupings if they exist i.e. rather than creating a Car from many different parts, group some parts into an Engine object, some into a Chasis etc.
Alternatively, if some of those parameters are optional, make use of the builder pattern so that you only include them when necessary.
Ultimately, though, do whatever makes most sense for you and your domain.
Yes, you should. See What's the best way to refactor a method that has too many (6+) parameters?