CODEWITHSUNDEEP
javaspringjakarta-ee
LuckyLuke
LuckyLuke

Reputation: 49097

How to avoid potentially long if statements for the same thing multiple places

I am creating an application and at the front I check if the user is an admin, user, moderator or superadmin. Based on this I create a different XML.

So what I currently do is to pass a string in the method argument that converts the object to XML to specify which mapping it should use. However passing those strings around isn't good. Are there any patterns to do this better?

I could bring the role check to the mapping class, and then change the mapping id to the same as the role of the current user. But I don't think security checks fits those classes.

Would you just create an enum to keep the roles and pass that instead of a string?

Or create different classes and use a factory to return the right object?

Upvotes: 0

Views: 94

Answers (2)

MarcoS
MarcoS

Reputation: 13574

You question is not very clear. Anyway, I try to give some option:

  1. if you want to serialize to XML different kind of users, then I would suggest to model the different kind of users as a hierarchy of classes, and have a specialized toXML() serialization method in each class. By the way, JAXB can help you a lot, if this is what you want to do.

  2. if you have a class XMLBuilder that writes some XML, and the way the XML is built depends on the kind of user, then I would suggest to model your different kind of users with a hierarchy of classes, and then use method overloading in XMLBuilder, i.e. have several build() methods each one taking as input a different subclass of your user-kind hierarchy.

I hope this helps.

Upvotes: 0

christopher
christopher

Reputation: 27356

A Common Interface Approach

By implementing a common interface between all return objects, you can develop some loose coupling in your code. For example:

public interface XmlReturn
{
     public void displayXML(); // Just an example method.
}

And a class that implements this interface:

public class AdminXmlReturn implements XmlReturn
{
     public void displayXML() { // Some code here for the admin XML }
}

With this, you can generate some sort of factory that takes a discriminator:

public abstract class XmlFactory 
{
     public static XmlReturn getInstance(String type)
     {
         // Using string as an example type. Doesn't need to be.
         if(type.equals("Admin")) {
              return new AdminXmlReturn();
         }
     }
}

and by referring to the object by it's interface type, you can generate as many different XML files you want, without having to change any code. IE:

public void loadPage(String permission)
{
    // permission can be any type. This is just an example.
    XmlReturn xml = XmlFactory.getInstance(permission);
    xml.displayXML();
    // This method exists in all objects that implement XmlReturn
}

Advantages

This approach has the main advantage that you can add as many new XML files and permissions as you want, and you won't need to change the code that loads the XML. This "separation of concerns" will help you to make your program very manageable and extendable.

By porting your decision logic to a factory, you help make your code more readable, and allows other people to abstract away from the details of the inner workings of your program, if you intend on sharing your code.

Upvotes: 3

Related Questions