We Keep Coding

Java avoid using too many if statement or too many validator classes

I am using lot of if statements to check.Like:
if(statement 1){
block 1;
}
if(statement 2){
block 2;
}
...//about at least 20 if
if(statement n){
block n;
}
To avoid using too many if-statement, I have tried to use strategy pattern which would create validator class for each if-statement.Like:
public interface Validator<SomeObejct>{
public Result validate(SomeObject o);
}
public class SomeValidator implements Validator<SomeObject> {
#Override
public boolean validate(SomeObject o) throw Exception{
if(statement 1){
block 1;
}
}
Because I may have at least 20 if-statement, it may need at least 20 validator classes. So if there is any better solution for that? Or how can I manage these 20 validotor classes?
Edit:
To be more specific, I am writing some code for checking the problem on my schedule. For example:
if(currentDate > mustFinishDate){
warning();
}
if(NotScheduleADateForThisTask){
warning();
}
if(DateFormatNotCorrect){
error();
}
Above the date check may also be the if-statement block.

You can use the Composite pattern to maintain a list of all validators:
class ValidatorComposite<T> implements Validator<T> {
List<Validator<T>> validators = new ArrayList<>();
public void addValidator(Validator<T> add) { validators.add(add)); }
public Result validate(T toValidate) {
Result result = Result.OK;
for (Validator<T> v : validators) {
result = v.validate(toValidate);
if (result != Result.OK) break;
}
return result;
}
}
and since Validator only has one method, for Java 8 it's a functional interface, so you don't really need "20 classes" but can create a list on the fly using lambdas.
ValidatorComposite<SomeObject> val = new ValidatorComposite<>();
val.addValidator(so -> condition1 ? block1(so) : Result.OK);
val.addValidator(so -> condition2 ? block2(so) : Result.OK);
and so on.
Your code sample isn't really consistent because first you declare Validator to return Result and later let the implementation return boolean (and even throws an Exception), so I kind of intergrated both by ignoring the exception and using a Result.OK value.

these days what you should not probably care about is performance because of power of computers. now most programmers try to write readable and clean codes.
so i believe if writing 20 ifs makes your code easier to understand and more flexible its not bad to implement that.
BTW you can use switch case too.
switch (variable){
case 1:{
//block 1
}
case 2:{
//block2
}
...
}
if your cases are not similar and have different aspects using that Validator pattern will lead to inflexibility(It may lead to this point, it depends on situation).

How to scalably consider nulls in equals()?

To avoid a null pointer exception in my equals(), I have to consider the possibility of one or more nulls.
Is there a scalable way for considering nulls? The following code will become ugly quite fast if I add more type parameters.
public boolean equals(Pair<T, U> p) {
boolean firstIsEqual, secondIsEqual;
if (p.getFirst()==null) {
firstIsEqual = first == null;
}
else {
firstIsEqual = (first!=null) && (first.equals(p.getFirst()));
}
// copy-paste...
if (p.getSecond()==null) {
secondIsEqual = second == null;
}
else {
secondIsEqual = (second!=null) && (second.equals(p.getSecond()));
}
return (firstIsEqual && secondIsEqual);
}

The only solution that scale are:
to use a library like Lombok that provide means to generate such methods during the compile phase
to use the built-in code generation features of your IDE
Seriously: nobody in the real world writes equals/hashCode methods manually. You use a tool and tell that which fields should be used in the computation. If a field is added, you have to remember to re-generate the methods.
Or you use a jvm language that supports data classes such as Kotlin or Scala.

Effective way to test if object is null

What is better use in order to check if object is null.
To check if the object is null or to set a flag for it.
By saying better im looking for performance (faster and safer).
public class A
{
Object test;
boolean isTestObjectSet;
public A(Object test)
{
this.test = test;
isTestObjectSet = true;
}
public A()
{
}
public void doSomething()
{
if(test != null)
//do something
//VS
if(isTestObjectSet)
//do something
}
}

Using isTestObjectSet is just making things more complicated than they need to be. Just use test != null: it better conveys your intention and doesn't force you to keep this isTestObjectSet variable in-sync with whether or not test is set. There is absolutely no performance difference between the two variants.

In my opinion - explicit checks (comparing to 'null') is faster, in terms not cluttering your code with many intermediary boolean variables.
Safer? Both of the checks are boolean checks, so it is always 'true'/'false' comparison.

Cyclomatic Complexity, joining conditions and readability

Consider the following method (in Java - and please just ignore the content):
public boolean equals(Object object) {
if (this == object) {
return true;
}
if (object == null) {
return false;
}
if (getClass() != object.getClass()) {
return false;
}
if (hashCode() != object.hashCode()) {
return false;
}
return true;
}
I have some plugin that calculates: eV(g)=5 and V(g)=5 - that is, it calculates Essential and common CC.
Now, we can write the above method as:
public boolean equals2(Object object) {
if (this == object) {
return true;
}
if (object == null || getClass() != object.getClass()) {
return false;
}
return hashCode() == object.hashCode();
}
and this plugin calculates eV(g)=3 and V(g)=3.
But how I do understand CC, the values should be the same! CC is not about counting the lines of code, but the independent paths. Therefore, joining two if in one line does not really reduces CC. In fact, it only can make things less readable.
Am I right?
EDIT
Forgot to share this small convenient table for calculating CC quickly: Start with a initial (default) value of one (1). Add one (1) for each occurrence of each of the following:
if statement
while statement
for statement
case statement
catch statement
&& and || boolean operations
?: ternary operator and ?: Elvis operator.
?. null-check operator
EDIT 2
I proved that my plugin is not working well, since when I inline everything in one line:
public boolean equals(Object object) {
return this == object || object != null && getClass() == object.getClass() && hashCode() == object.hashCode();
}
it returns CC == 1, which is clearly wrong. Anyway, the question remains: is CC reduced
[A] 5 -> 4, or
[B] 4 -> 3
?

Long story short...
Your approach is a good approach to calculate CC, you just need to decide what you really want to do with it, and modify accordingly, if you need so.
For your second example, both CC=3 and CC=5 seem to be good.
The long story...
There are many different ways to calculate CC. You need to decide what is your purpose, and you need to know what are the limitations of your analysis.
The original definition from McCabe is actually the cyclomatic complexity (from graph theory) of the control flow graph. To calculate that one, you need to have a control flow graph, which might require a more precise analysis than your current one.
Static analyzers want to calculate metrics fast, so they do not analyze the control flow, but they calculate a complexity metric that is, say, close to it. As a result, there are several approaches...
For example, you can read a discussion about the CC metric of SonarQube here or another example how SourceMeter calculates McCC here.
What is common, that these tools count conditional statements, just like you do.
But, these metrics wont be always equal with the number of independent execution paths... at least, they give a good estimation.
Two different ways to calculate CC (McCabe and Myers' extension):
V_l(g) = number of decision nodes + 1
V_2(g) = number of simple_predicates in decision nodes + 1
If your goal is to estimate the number of test cases, V2 is the one for you. But, if you want to have a measure for code comprehension (e.g. you want to identify methods that are hard to maintain and should be simplified in the code), V1 is easier to calculate and enough for you.
In addition, static analyzers measure a number of additional complexity metrics too (e.g. Nesting Level).

Converting this
if (hashCode() != object.hashCode()) {
return false;
}
return true;
to this
return hashCode() == object.hashCode();
obviously reduces CC by one, even by your quick table. There is only one path through the second version.
For the other case, while we can't know exactly how your plugin calculates those figures, it is reasonable to guess that it is treating if (object == null || getClass() != object.getClass()) as "if a non-null object's class matches then ...", which is a single check and thus adds just one to CC. I would consider that a reasonable shortcut since null checks can be rolled up into "real" checks very easily, even within the human brain.
My opinion is that the main aim of a CC-calculating IDE plugin should be to encourage you to make your code more maintainable by others. While there is a bug in the plugin (that inlined single-line conditional is not particularly maintainable), the general idea of rewarding a developer by giving them a better score for more readable code is laudable, even if it is slightly incorrect.
As to your final question: CC is 5 if you strictly consider logical paths; 4 if you consider cases you should consider writing unit tests for; and 3 if you consider how easy it is for someone else to quickly read and understand your code.

In the second method
return hashCode() == object.hashCode(); costs 0 so you win 1. It's considered as calculation and not logical branch.
But for the first method I don't know why it's cost 5, I calculate 4.

As far as style is concerned, I consider the following the most readable:
public boolean equals(Object object) {
return this == object || (object != null && eq(this, object));
};
private static boolean eq(Object x, Object y) {
return x.getClass() == y.getClass()
&& x.hashCode() == y.hashCode(); // safe because we have perfect hashing
}
In practice, it may not be right to exclude subclasses from being equal, and generally one can not assume that equal hash codes imply equal objects ... therefore, I'd rather write something like:
public boolean equals(Object object) {
return this == object || (object instanceof MyType && eq(this, (MyType) object));
}
public static boolean eq(MyType x, MyType y) {
return x.id.equals(y.id);
}
This is shorter, clearer in intent, just as extensible and efficient as your code, and has a lower cyclomatic complexity (logical operators are not commonly considered branches for counting cyclomatic complexity).

Adding additional checks to the instanceOf check in java

I have a situation where I check for the instanceOf some classes for proceeding with my logic.
For eg.
if (obj instanceof X)
{
result = true;
}
But now this is being used in lot of places in my legacy code.
My problem is now this instanceOf should return true only if some global property variable is true.
I am looking for an alternative solution to replacing all these instanceOf checks as shown below:
if (GLOBALPROPERTY == true)
{
if (obj instanceof X)
{
result = true;
}
}
Can I inject this check inside the class X itself so that, it will return false wherever I check for instanceOf this class.

No, you can't.
The nearest thing I can think of is aspect-oriented programming with AspectJ. But that would be tricky - you'd probably have to switch from using instanceof to using proper polymorphic method calls, first.
But pragmatically, you'll probably just have to do a search and replace through your entire codebase.