Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
Where is preferred place to store functions for improve readibility of streams?
For example:
private BinaryOperator<Cash> sumPayments() {
return (payment1, payment2) -> payment1.sum(payment2);
}
I'm not sure if it should be in service class where it's used, but maybe it will be in many places so whats about some extra static Utils? or in entity?
Where possible avoid unnecessary helper methods.
In this particular example, the helper method can easily be replaced with a method reference, which is (arguably more) readable:
Cash total = subtotals.stream().reduce(Cash.ZERO, Cash::sum);
In other cases, where you actually do need a helper: think about where you would search for such a helper method in a year, when you have to adapt your now-barely-familiar code to new requirements.
Is it more entity related? Put it in the entity class
Is it more business logic related? Put it into the business logic
Is it generally useful? Put it into a utility class
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 months ago.
Improve this question
While using streams, I learned how to handle exceptions using functional interfaces and wrapper functions.
If so, what is the best way to structure the package?
Is it defined together in the class where stream is used? Or should I create a separate common class and define the wrapper function in it?
Thanks!
I think it depends. If you have one instance of using this technique, then it probably makes sense to simply use an functional interface and a wrap function that are part of the class which utilizes it. If you are using this same pattern in several places (and they all have the same function interface signature) then you can define the functional interface at the package level and put the wrap function in a utility class.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I'm working on a project where we have a method like this:
processEvent(event, context) {
// var result = some processing here
context.setResult(result);
// context's class have nothing to do with processEvent's class
return context;
}
The class SomeClass containing processEvent method has no inheritance relation with context's class (so it's not about a builder pattern here). For me, the context returning is silly because the direct caller would already have it. Are any other more plausible arguments in favor of or against this approach?
It's not uncommon to have a method return one of its parameters' values if it doesn't have any other return value. It enables code like this:
Context context = processEvent(event, new Context(/*...*/));
Whether that's good or bad style is, er, a matter of style. :-) It's not all that common, but I wouldn't say it's uncommon, either.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have a method doing something like this
class CodeProvider implements Provider {
List<String> getCodes() {
return List.of("1", "2", "3");
}
}
Is there any reason to write a unit test for it like this?
#Test
public void test_GetCodes() {
assertThat(getCodes(), is(of("1", "2", "3")));
}
In order to have more context. This class is part of Provider hierarchy, that doesn't have any more logic than this. Providers only reason to exists is to be used as parameter for an common external service call.
As the commenters have pointed out, testing that the data matches exactly doesn't seem that useful. However, there are other types of tests you can write for such a method.
(Taking into account that this is a simplified sample and that the underlying data may be more complex:) With source code like this your method becomes an abstraction for the underlying data. Maybe your client code will rely on some properties of this data, for example that the data items are ordered, or that there is an upper bound on their cardinality, etc. In cases where getCodes is likely to evolve, unit tests will help gain confidence that your properties/assumptions of interest do not become violated as as the code changes.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Can someone explain this property with use cases by an example.
In the context of Collections class (and some other class of the Java Collections Framework) it means that a Collection is a "wrapper" of another Collection: the inner class stores the data and the outer class adds some behavior that the inner one hasn't. An example are the methods of Collections whose name starts with synchronized or unmodifiable: the method synchronizedList(List) adds synchronization to any given List, the method unmodifiableList(List) makes any given List unmodifiable and so on.
See also the Decorator Pattern.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have common methods written in different classes, making code duplicate and now to avoid this duplicacy, I am thinking of 2 approaches:
Make static methods in some util class and call them, or
Make a super class and write all these methods in super class and extend each class with this super class.
Definitely, with approach 2, I will loose the ability to extend my class further. So I am thinking to go with approach 1.
Can you please help me in identifying which approach is good and also in suggesting better approach, if you have any?
Creating Utility packages and/or class is a common solution to this problem. Apache Commons is a prime example. I would favour approach 1