Stack Exchange
java prevent a lot of if and replace it with design pattern(s)
I use this code in my application and I find it very ugly. 
Is there a smart way of doing this? 
for (final ApplicationCategories applicationCategorie : applicationCategories) {
          if (applicationCategorie == ApplicationCategories.PROJECTS) {
              // invoke right method
            } else if (applicationCategorie == ApplicationCategories.CALENDAR) {
              // ...
            } else if (applicationCategorie == ApplicationCategories.COMMUNICATION) {

            } else if (applicationCategorie == ApplicationCategories.CONTACTS) {

            } else if (applicationCategorie == ApplicationCategories.DOCUMENTS) {

            } else if (applicationCategorie == ApplicationCategories.WORKINGBOOK) {

            }
        }

My aim is to handle all application categorie enums which contained into the enum list.

Try switch case

but with switch case I also need the for loop and I will prevent this loop.

You can add methods to enums in Java. Then, try add to ApplicationCategories a static method in handle. In this put a switch statement, which helps you to choose the right categories. Finally, add a method to the enum, so that it can handle each kind of behaviour for a specific enum value. But, we definitely need to know how the code varies in each if block.

Thanks for the response, Could you give me an example? Thanks a lot!

How the code inside each if statement varies from each other?

Use single if or switch, if(applicationCategorie == ApplicationCategories[index]), get properties  by index if possible and invoke right method accordingly.

How much are the number of possible max conditions?

The least you can do is to declare the method that handles the behaviour dependent to the enum inside ApplicationCategories. In this way, if you will add a new value to the enum, you will only to change the code relative to enum. 
In this way, your code adheres to the Open Closed Principle, and so it is easier to maintain.
enum ApplicationCategories {
    PROJECTS,
    CALENDAR,
    // And so on...
    WORKINGBOOK;

    public static void handle(ApplicationCategories category) {
        switch (category) {
            case PROJECTS:
                // Code to handle projects
                break;
            case CALENDAR:
                // Code to handle calendar
                break;
            // And so on
        }
    }
}

This solution is only feasable if you do not need any external information to handle the enum value.
Remember you can also add fields to enum values. 
EDIT
You can also implement a Strategy design pattern if you need. First of all, define a strategy interface and some concrete implementations.
interface CategoryStrategy {
    void handle(/* Some useful input*/);
}
class ProjectStrategy implements Strategy {
    public void handle(/* Some useful input*/) {
        // Do something related to projects...
    }
}
class CalendarStrategy implements Strategy {
    public void handle(/* Some useful input*/) {
        // Do something related to calendars...
    }
}
//...

Then, you can modify your enum in order to use the above strategy.
enum ApplicationCategories {
    PROJECTS(new ProjectStrategy()),
    CALENDAR(new CalendarStrategy()),
    // And so on...
    WORKINGBOOK(new WorkingBookStrategy());

    private CategoryStrategy strategy;
    ApplicationCategories(CategoryStrategy strategy) {
        this.strategy = strategy;
    }

    public static void handle(ApplicationCategories category) {
        category.strategy.handle(/* Some inputs */);
    }
}

Clearly, the above code is only a sketch.

The design pattern you need is the Strategy.
Enums and violation of the Open/Closed Principle
The use of enums when you have to perform a different action for each defined value is a bad practice. As the software evolves, it is likely that you have to spread the if chain around different places. If you add a new enum value, you'll have to add a new if for that value in all these places. Since you may not even be able to find all the places where you have to include the new if, that is a source for bugs.
Such approach also violates the Open/Closed Principle (OCP). Just creating a method to handle each enum value doesn't make your code conformant to OCP. It will make the code more organised but doesn't change anything about the "if" issue.
Java 7 solution with Strategy Pattern
Using Java 7 or prior, you can define a ApplicationCategory interface that all categories will implement. This interface will provide a common method that each category will implement to perform the required actions for that category:
public interface ApplicationCategory {
     boolean handle();
}

Usually your method should return something. Since I don't know what is your exact goal, I'm making the method to return just a boolean. It would indicate if the category was handled or not, just as an example.
Then you have to define a class implementing such an interface for each category you have. For instance:
public class CalendarCategory implements ApplicationCategory {
     boolean handle(){
         //the code to handle the Calendar category
         return true;
     }
}

public class CommunicationCategory implements ApplicationCategory {
     boolean handle(){
         //the code to handle the Communication category
         return true;
     }
}

Now you don't need the enum class and the handle method that was inside it needs to be moved elsewhere, that completely depends on your project. That handle method will be changed to:
public static void handle(ApplicationCategory category) {
    //Insert here any code that may be executed,
    //regardless of what category it is.
    category.handle();
}

You don't need an enum anymore because any variable declared as ApplicationCategory just accepts an object that implements such an interface. If you use the enum together with the Strategy implementation, it will be yet required to change the enum class any time you add a new ApplicationCategory implementation, violating the OCP again.
If you use the Strategy pattern, you don't even need the enum anymore in this case.
Java 8 solution with functional programming and Strategy Pattern
You can more easily implement the Strategy pattern using functional programming and lambda expressions, and avoid the proliferation of class just to provide different implementations of a single method (the handle method in this case).
Since the handle method is not receiving any parameter and is retuning something, this description conforms to the Supplier functional interface. An excellent way to identify what kind of functional interface a method you are defining conforms to, it is studying the java.util.function package.
Once the type of functional interface is identified, we can create just a ApplicationCategory class (that in the Java 7 example was an interface) in a functional way, defining the previous handle method as an attribute of the Supplier type. You must define a setter for this handle attribute to enable changing the handle implementation. Defining a method as an attribute, you are enabling such a method implementation to be changed in runtime, providing a different but far simpler, easier and more maintainable implementation of the Strategy pattern. 
If you need to use the category name somewhere, for instance to display it in a user interface, you could define an enum inside the ApplicationCategory class. However, there is no direct relation between the enum value and the handle provided. The enum works just as a tag for the category. It is like a "name" attribute in a Person class, that we usually just use to "tag" and print a person.
public class ApplicationCategory {
     //insert all categories here
     enum Type {CALENDAR, COMMUNNICATION} 

     /**
      * The Supplier object that will handle this category object.
      * It will supply (return) a boolean to indicate if the category
      * was processed or not.
     */
     private Supplier<Boolean> handler;

     private Type type;

     /**
     * A constructor that will receive a Supplier defining how to 
     * handle the category that is being created.
     */
     public ApplicationCategory(Type type, Supplier<Boolean> handler){
         Objects.requireNonNull(type);
         this.handler = handler;
         setType(type);
     } 

     /**
     * Handle the category by calling the {@link Supplier#get()} method,
     * that in turn returns a boolean.
     */
     public boolean handle(){
         return supplier.get();
     }

     public Type getType(){ return type; }

     public final void setHandler(Supplier<Boolean> handler){
        Objects.requiredNonNull(handler);
        this.handler = handler;
     }
}

If you give the behaviour that will handle the enum value at the enum constructor call, as suggested by the other answer provided here, then you don't have how to change the behaviour in runtime and it in fact doesn't conform to the Strategy pattern. Unless you really don't need that, you might implement in that way, but remember it violates the OCP.
How to use the Java 8 functional ApplicationCategory class
To instantiate a ApplicationCategory you have to provide the Type (an enum value) and the handler (that is a Supplier and can be given as a lambda expression). See the example below:
import static ApplicationCategory.CALENDAR;

public class Test {
    public static void main(String args[]){
        new Test();
    }

    public Test(){
        ApplicationCategory cat = new ApplicationCategory(CALENDAR, this::calendarHandler);
        System.out.println("Was " + cat + " handled? " + cat.handle());
    }

    private boolean calendarHandler(){
        //the code required to handle the CALENDAR goes here
        return true;
    }
}

The this::calendarHandler instruction is a method reference to pass a "pointer" to the calendarHandler method. It is not calling the method (you can see that due to the use of :: instead of . and the lack of parenthesis), it is just defining what method has to be in fact called when the handle() method is called, as can be seen in System.out.println("Was " + cat + " handled? " + cat.handle()); 
By using this approach, it is possible to define different handlers for different instances of the same category or to use the same handler for a subset of categories.

Be careful when using the strategy pattern.  It's most common use is to provide complicated re-implementations of simple things that the language already does.

@MattTimmermans It's not clear what you mean, because the Java 8 example exactly uses what the language provides, instead of the Java 7 one that requires the creation of a class for each category. Could you please elaborate on that?

I mean that associating different behavior with different types of objects is what OOP is all about, and when this is what you want to do, then the fundamental constructs of the language (like simple polymorphism) are usually sufficient.  The strategy pattern is justified when the client of an object or class needs to configure its behavior at runtime, but that's only a requirement here because you made it a requirement.  Sometimes it's a requirement in real life, often it's not.

Unlike other languages, Java provides facilities that specifically allow this sort of thing to be done in a safe object-oriented way.
Declare an abstract method on the enum, and then specific implementations for each enum constant. The compiler will then ensure that every constant has an implementation and nobody has to worry about missing a case somewhere as new values are added:
enum ApplicationCategories {
    PROJECTS {
       void handle() {
           ...
       }
    },
    ...

    public abstract void handle();
}

Then, instead of calling some static handle(category), you just call category.handle()

But the point is that this doesn't make your class open for extension and closed for modifications, violating the OCP principle that is really an issue. It also doesn't allow changing the handle method at runtime.

@ManoelCampos changing the handle method at runtime wasn't a requirement.   Re. OCP:  Look at your code and then look at this code.  Obviously you're not getting OCP for free.  It has a cost that is sometimes justified and sometimes not.  Your code is not faster, not easier to understand, and not easier to maintain. I'd be interested to hear what you think the benefits are in practical, rather than dogmatic, terms.

@MattTimmermans I totally agree with you that I'm not getting OCP for free. And considering that changing the handle behaviour at runtime was not a requirement, the solution you presented is straightforward. My solution requires more code, but for anyone that understands functional in Java programming, it is cristal clear. About speed, there is no point here since 1 or 2 additional method calls will be irrelevant. As far as speed is concerned, one has to measure it and likely will find out places that code should and can be really optimized.

I do not agree that my solution is less maintainable. It in fact provides some actual (and not just dogmatic) benefits such as a more flexible design, avoids code duplication, increases reusability (by enabling reusing the same handler for different categories), provides reduced coupling (since the handler behaviour is not tightly linked to the category) making it easier to test without even duplicating test code (since each behaviour is not duplicated and can be tested independently).

Therefore, it is in fact more maintainable. I understand that a simpler solution implemented in just one class is in fact easier to understand and straightforward to change. But if we are talking about maintainability, considering that the only constant in software development is requirements change, my solution is able to attend new requirements such as dynamic behaviours, behaviours reuse, compound behaviours, etc. But again, for the current requirements, I see that your solution is pretty good.
