@DavidHarkness hey I am thinking of making a factory for ClientData class so that I can ask the mapping of any ENUM type from that factory instead of doing everything in one ClientData class. I will have one factory, two class one for each enum type and one interface right if I go this route?

If I go this route, then how my Interface will look like and its implementation?

This is what you were also thinking or something else to simplify the ClientData class?

@lining That sounds similar to what I was thinking from your description, though I would say two instances of the same class (maybe what you meant).

There's no reason they couldn't share an instance to manage the block list and others to manage the host-to-IP mappings

Any time you see fields with similar names like primaryHostIdToPartitionMapping and secondaryHostIdToPartitionMapping it's a clue to a refactoring. Both mappings require hostIdToMachineMapping which could be shared easily between two mapping class instances. That's an example of what I mentioned earlier.

I see, so you mean to say there won't be any interface in this right?

Can you provide a simple example how does my two classes will look like?

Not necessarily. I'm talking about refactoring the Mappings class which wouldn't need an interface, but you were speaking about ClientData, right? I'm not sure what part of the code you meant. What responsibilities do you want to refactor into separate classes? Start by listing those, and some appropriate class names will pop out at you.