I write the code for creating multiple instances for the thread-safe factory creation:
public class XWebserviceObjectFactoryCreator {
}
However, the code looks repeating to me and not happy about it. Is it possible to use enum (or something else) to make it more readable?
Since the example shows all the classes have no-argument constructors, you can use the Class.newInstance method, so something like :
private static Map<Class<?>, Object> instances = new HashMap<>();
public static <T extends Object> T getObjectFactoryInstance(Class<T> clazz) {
Object result;
if ((result = instances.get(clazz)) == null) {
synchronized (instances) {
if ((result = instances.get(clazz)) == null) {
try {
result = clazz.newInstance();
instances.put(clazz, result)
} catch (InstantiationException | IllegalAccessException e) {
// do something
}
}
}
}
return (T)result;
}
Apologies if layout or syntax is off, but I’m away from my computer and doing this on the phone - but hope you get the idea !
If any classes do require arguments in their constructors, then you’ll have to use reflection to invoke the constructor.
Finally, note that I’ve modified the declaration of clazz from Class<?> to Class< T>, to let the generics validate the caller by tying the output to the given Class.
you can use the Abstract Factory design Pattern along with Enum where Sales2ObjectFactory, OrderingObjectFactory, Settings2ObjectFactory, and SettingsObjectFactory can be a factory in itself with a common interface.
Then you can use Enum to get the instance of one of those factories.
public static class FactoryMaker {
public enum FactoryType {
SALES2OBJECT, ORDERING,SETTING2OBJECT,SETTINGS
}
public static CommonFactory makeFactory(FactoryType type) {
switch (type) {
case SALES2OBJECT:
return new Sales2ObjectFactory();
case ORDERING:
return new OrderingObjectFactory();
case SETTING2OBJECT:
return new Settings2ObjectFactory();
case SETTINGS:
return new new SettingsObjectFactory();
default:
throw new IllegalArgumentException("FactoryType not supported.");
}
}
}
Please check :: https://java-design-patterns.com/patterns/abstract-factory/
Related
Say you have a lot of similar classes that may get instantiated at any point. One obvious way to write this would be a whole slew of conditionals:
public static Common factory(String key, InstantiationObj instantiationObj) {
if( key == "A") {
return new TypeA(instantiationObj);
}
else if( key == "B") {
return new TypeB(instantiationObj);
}
else if( key == "C" ) {
return new TypeC(instantiationObj);
}
else if( key == "D" ) {
return new TypeD(instantiationObj);
}
else {
return new DefaultClass(instantiationObj);
}
}
I like to avoid all the conditionals though. In Java I got this working:
public static <T extends Common> T factory(String key, InstantiationObj instantiationObj) throws Exception {
Class[] cArg = new Class[1];
cArg[0] = InstantiationObj.class;
HashMap<String, Class> potentialClasses = new HashMap<>();
potentialClasses.put("A", TypeA.class);
potentialClasses.put("B", TypeB.class);
potentialClasses.put("C", TypeC.class);
potentialClasses.put("D", TypeD.class);
Class<T> classType = potentialClasses.getOrDefault(key, DefaultClass.class);
return classType.getDeclaredConstructor(cArg).newInstance(instantiationObj);
}
This is much easier to test, but it still looks clunky to me especially the block to determine the right constructor. Does Java have a more streamlined way of executing this pattern?
One suggestion can be
public class CommonClass {
private static HashMap<String, Class> potentialClasses = new HashMap<>();
static {
potentialClasses.put("A", TypeA.class);
potentialClasses.put("B", TypeB.class);
potentialClasses.put("C", TypeC.class);
potentialClasses.put("D", TypeD.class);
}
public static <T extends Common> T factory(String key) throws Exception {
Class[] cArg = new Class[1];
cArg[0] = NecessaryConstructor.class;
Class<T> classType = potentialClasses.getOrDefault(key, DefaultClass.class);
return classType.getDeclaredConstructor(cArg).newInstance(descriptor);
}
In case the logic is so simple as in your case, you may use reflection, without defining mapping:
public static Common factory(String key, InstantiationObj instantiationObj) {
String className = "Type" + key;
Class<T> classType = Class.forName(className);
...
Thus, for key "A" the variable className will have value "TypeA", for key "B" it will have value "TypeB", etc.
But this will work in this simple case only, when mapping of parameter key to class names follows a simple pattern.
In case the logic becomes more complex later on, you would need if (...) clauses for every condition.
One way I like implementing the factory pattern is with using spring. You can have as many classes of a specific type in your project.
Then, inject or autowire a List of same type in a class and Spring will set all instances of that type in the list.
Finally, transform the list to a map like you have and you will have maximized the idea of
“Closed for modification , open for extensibility” on you factory and project.
I'm designing a module which can support different datasources.
My module gets the user's company id as inputs and I must call the appropriate class based on the company id.
I'm trying to incorporate some good design and avoid conditional statements where possible.
I have a FetchDataSource singleton class with this method.
public class FetchDataSourceSingleton {
private static Map<String, Communicator> communicatorMap;
public static Communicator getCommunicatorInstance(String dataSourceType) {
if (communicatorMap == null || communicatorMap.isEmpty())
populateCommunicatorMap();
if (communicatorMap.containsKey(dataSourceType))
return communicatorMap.get(dataSourceType);
return null;
}
.... other methods including populateCommunicatorMap()
}
"Communicator" is an interface, and the communicator map will return the appropriate instance.
This is the populateCommunicatorMap() method in the same singleton class.
private static void populateCommunicatorMap() {
communicatorMap = new HashMap<String, Communicator>();
communicatorMap.put("AD", new ADCommunicator());
communicatorMap.put("DB2", new DB2Communicator());
communicatorMap.put("MYSQL", new MYSQLCommunicator());
}
ADCommunicator, DB2Communicator and MYSQLCommunicator will implement the Communicator inteface.
The code seems to work in my test draft.
The only concern I have is the HashMap will return the same object for all communication requests to the same type. I can't seem to avoid having the same instance in the hashmap if I want to avoid the conditional statements. Otherwise instead of the hashmap, I could have just make calls like this.
Communicator comm;
if (type = "AD") comm = new ADCommunicator();
if (type = "DB2") comm = new DB2Communicator();
if (type = "MYSQL") comm = new MYSQLCommunicator();
I've avoided this by using the hashmap to return an instance based on type.
But then I can't avoid the singleton problem where I get the same instance.
In a multithreaded environment, which needs to support hundreds of thousands of communication requests at a time, this could be a problem considering I'll need to syncronize a lot of code in each of the Communicator classes.
Is there a way I can avoid the syncronization and make it thread safe without impacting performance?
I can't seem to avoid having the same instance in the hashmap
You can use a switch instead of a bunch of ifs.
Switch Over an enum (Java 5)
Change type to be an enum in Java 5+, then you can switch on it. I'd recommend enums in general for type safety.
// type is-a enum Communicator.TYPE
switch(type) {
case AD: return new ADCommunicator();
case DB2: return new DB2Communicator();
case MYSQL: return new MYSQLCommunicator();
default: return null;
}
Switch over a String (Java 8)
Java 8 can switch over Strings directly.
// type is-a String
switch(type) {
case "AD": return new ADCommunicator();
case "DB2": return new DB2Communicator();
case "MYSQL": return new MYSQLCommunicator();
default: return null;
}
Switching over an enum will be as fast as a map, if not faster. Switching on the string will be as fast as a Map.
A Map of Factory (factory of factories)
Or have a map of factories:
private final static Map<String, Factory<? extends Communicator>> map;
static {
map.put("AD", ADCommunicatorFactory.getInstance());
//...
map.put(null, NullFactory<Communicator>.getInstance());
} // populated on class-load. Eliminates race from lazy init
// on get
return map.get(type).make();
A Map of Class (reflection)
Or use the reflection API to make instances, but then it would probably be better to just use conditionals.
// on init
Map<String, Class<? extends Communicator>> map = new HashMap<>();
map.put("AD", ADCommunicator.class);
// on get
try {
return (Communicator) map.get(type).newInstance();
} catch(InstantiationException | IllegalAccessException | NullPointerException e) {
return null;
}
P.S.
This all sounds like premature optimization. I doubt that determining which Communicator to use is going to be a bottleneck in your system.
If all your communicators can be constructed with empty argument list constructor, then you can store the type (class) of the communicator in the map instead of an instance. Then you can look up the type (java.lang.Class) from your communicatorMap and instantiate a new instance with java.lang.Class.newInstance().
For example:
public interface Communicator {
void communicate();
}
public class Communicator1 implements Communicator {
public void communicate() {
System.out.println("communicator1 communicates");
}
}
public class Communicator2 implements Communicator {
public void communicate() {
System.out.println("communicator2 communicates");
}
}
public class CommuniicatorTest {
public static void main(String[] args) throws Exception {
Map<String, Class<? extends Communicator>> communicators = new HashMap<String, Class<? extends Communicator>>();
communicators.put("Comm1", Communicator1.class);
communicators.put("Comm2", Communicator2.class);
Communicator comm2 = communicators.get("Comm2").newInstance();
comm2.communicate();
System.out.println("comm2: " + comm2);
Communicator anotherComm2 = communicators.get("Comm2").newInstance();
anotherComm2.communicate();
System.out.println("anotherComm2: " + anotherComm2);
}
}
result:
communicator2 communicates
comm2: pack.Communicator2#6bc7c054
communicator2 communicates
anotherComm2: pack.Communicator2#232204a1
Assylias is correct about using a static initializer. It runs when your class loads, which guarantees that the map will be loaded before anything else happens to the class.
You didn't show the declaration of the map; I assume that it is static.
private final static Map<String, Communicator> communicatorMap;
static {
communicatorMap = new HashMap<>();
communicatorMap.put("AD", new ADCommunicator());
communicatorMap.put("DB2", new DB2Communicator());
communicatorMap.put("MYSQL", new MYSQLCommunicator());
}; // populated on class-load. Eliminates race from lazy init
The remaining issue is the Communicator implementation. All this assumes that it is thread-safe as well.
I have a Trigger Manager scenario where I delegate the triggers (in other-words subscribe triggers) to different handlers.
For now I have three handler types, I use a switch-case with enum (enum here is the handler type) to redirect to correct handler.
But my code seems not extensible, its not generic and it doesn't follow SOLID principle. Imagine if I need to have more handler
I will be eventually coming and editing my switch case code and I will have more cases where it affects the cyclomatic complexity of my code
Below is my exact code snippet
private static TriggerContext getTriggerContext(TriggerHandlerType triggerHandlerType) throws TriggerHandlerException {
switch (triggerHandlerType) {
case DASHBOARD_HANDLER:
triggerContext = new TriggerContext(new DashboardTriggerHandler());
return triggerContext;
case COMPONENT_HANDLER:
triggerContext = new TriggerContext(new ComponentTriggerHandler());
return triggerContext;
case WIDGET_HANDLER:
triggerContext = new TriggerContext(new WidgetTriggerHandler());
return triggerContext;
default:
LOGGER.error(MIS_CONFIGURED_REQUEST_IS_PROVIDED);
throw new TriggerHandlerException(TRIGGER_HANDLER_TYPE_GIVEN_IS_NOT_CONFIGURED_IN_THE_LIST_OF_TRIGGER_HANDLERS);
}
}
Can someone help me to enhance this code in-which I can make it more generic and avoid cyclomatic complexity and follow SOLID Principle along with some design pattern.
I think you mean "make code more dynamic", and your problem comes from using objects as primitives.
Rather than switching on the enum object, your enum objects should contain the type to be instantiated:
enum TriggerHandlerType {
DASHBOARD {
#Override
TriggerHandler create() {
return new DashboardTriggerHandler();
}
},
COMPONENT_HANDLER {
//...
};
abstract TriggerHandler create();
}
getTriggerContext can then call create() to instantiate the handler:
private static TriggerContext getTriggerContext(TriggerHandlerType triggerHandlerType) throws TriggerHandlerException {
return new TriggerContext(triggerHandlerType.create());
}
I am not sure about the overall design structure, but the switch can be replaced with a newHandler() method on the enum.
private static TriggerContext getTriggerContext(TriggerHandlerType triggerHandlerType)
throws TriggerHandlerException
{
return new TriggerContext(triggerHandlerType.newHandler());
}
In the enum you would implement the method for each type enum as
enum TriggerHandlerType {
DASHBOARD_HANDLER
{
Handler newHandler() { return new DashboardHandler(); }
},
...;
abstract Handler newHandler();
}
You could use a map of configurations for that:
// All your triggers classes should implement this interface
interface TriggerHandler {}
// For example:
public static class DashboardTriggerHandler implements TriggerHandler {
}
// Create your configuration
static Map<TriggerHandlerType, Class> contexts;
static {
contexts = new HashMap<>();
contexts.put(TriggerHandlerType.DASHBOARD_HANDLER, DashboardTriggerHandler.class);
contexts.put(TriggerHandlerType.COMPONENT_HANDLER, ComponentTriggerHandler.class);
contexts.put(TriggerHandlerType.WIDGET_HANDLER, WidgetTriggerHandler.class);
}
// Return your instance through reflection
public static TriggerContext getTriggerContext(TriggerHandlerType triggerHandlerType) throws TriggerHandlerException, IllegalAccessException, InstantiationException {
Class className = contexts.get(triggerHandlerType);
if (className == null) {
throw new TriggerHandlerException();
}
return new TriggerContext((TriggerHandler)className.newInstance());
}
I have a use case with 7-8 if else. Sample use case:
String type;
List < Entity > entityList;
if (type.equals("A")) {
ClassA a = new ClassA();
a.performTask();
for (Entity e: entitylist) {
// do some task
}
}
else if (type.equals("B")) {
ClassB b = new ClassB();
b.performTask();
for (Entity e: entitylist) {
// do some different task
}
}
Which java design pattern fits best in this case as I want to eliminate this if else ladder?
If you really want to use a design pattern in this case I would suggest the Visitor Pattern. This is the one (as far as I know) which is best suited for this kind of "type-checking". You can find an good example here. But as alreday stated in the comments, I agree that a pattern would be to much overhead in this case.
Introduce an interface for all tasks and use a factory pattern. The factory can use a map internally. E.g.
public class TaskFactory {
private Map<String, Class<? extends Task>> taskTypeMap = new HashMap<String, Class<? extends Task>>();
public TaskFactory() {
taskTypeMap.put("A", ATask.class);
taskTypeMap.put("B", BTask.class);
}
public Task createTask(String type) {
Class<? extends Task> taskType = taskTypeMap.get(type);
if (taskType == null) {
throw new IllegalArgumentException("Task type " + type
+ " is not supported");
}
try {
return taskType.newInstance();
} catch (Exception e) {
throw new IllegalStateException(
"Unable to instantiate Task of type " + taskType, e);
}
}
}
Your client code will then change to
String type = ...;
List<Entity> entityList = ...;
TaskFactory taskFactory = new TaskFactory();
Task task = taskFactory.createTask(type);
task.performTask();
for (Entity e: entitylist) {
// do some task
}
A factory implementation could look like this:
public class WidgetFactory {
public static void main(String[] args) {
String type = "A";
List<Entity> entityList = new ArrayList<>();
Widget widget = WidgetFactory.createWidget(type);
widget.performTask();
for (Entity e : entityList) {
widget.performTaskOnEntity(e);
}
}
private static Widget createWidget(String type) {
switch (type) {
case "A":
return new ClassA();
case "B":
return new ClassB();
default:
throw new IllegalArgumentException("Unknown type: " + type);
}
}
private interface Widget {
void performTask();
void performTaskOnEntity(Entity entity);
}
private static class ClassA implements Widget {
public void performTask() { }
public void performTaskOnEntity(Entity entity) { }
}
private static class ClassB implements Widget {
public void performTask() { }
public void performTaskOnEntity(Entity entity) { }
}
private static class Entity {
}
}
You need the following patterns to make this design generic -
Factory Pattern - Make a BaseClass. Class A, B(and C...) should extend this BaseClass. BaseClass should have a single abstract method performTask() which should be implemented by Class A & Class B (and C...) to make them concrete implementations
Template Pattern - Lets define a base class for the template - BaseTemplateClass. Now, the reason why I am using a template pattern here is that you have 3 distinct steps in the flow here -
Step 1- Create a new instance of the BaseClass(we will use Factory defined in step 1 to do this). CreateInstance() will be the first concrete method in the TemplateBaseClass which will take in the string param identifier and call the factory. Since, this a fixed step we will keep CreateInstance() as a concrete method.
Step 2 - BaseClass's performTask() will be called. This will be abstract.
Step 3 - processEntityList() method will contain the for loop. This will also be a concrete method containing the call to the for loop - for (Entity e: entitylist){..}
Lastly, we need a method execute() in BaseTemplateClass which calls the 3 methods defined in Steps 1, 2 & 3.
An implementation of the BaseTemplateClass will have only the implementation of the abstract method performTask() as per its needs - in this case just invoking the A, B (or C...)'s performtask(). But this will be helpful if more needs to be done with A, B(or C...).
The client(in classical terms) just needs to call execute() method of an instance of suitable implementation of BaseTemplateClass and rest will happen as per the design above.
I am currently working on a serialization routine which uses a library of generically typed adapters. If the object being serialized is an instance of one of the specific adapters I have, then I need to call that adapter on the object prior to performing my other serialization procedures.
The following code works:
private final static String serialize(Object obj, Map<Class<?>,
XmlAdapter<?,?>> classToAdapterMap) throws JAXBException
{
Object adaptedObj = null;
for (Class<?> clazz : classToAdapterMap.keySet()) {
if (clazz.isInstance(obj)) {
XmlAdapter<?,?> adapter = classToAdapterMap.get(clazz);
Class<?>[] argTypes = new Class[] {clazz};
try {
Method method = adapter.getClass().getMethod("marshal", argTypes);
adaptedObj = method.invoke(adapter, obj);
break;
} catch (Exception e) {
// handle method retrieval and invocation related exceptions
}
}
}
// serialize
}
However, I had originally thought that I would be able to do this more simply, for example with code like:
/* DOES NOT WORK */
private final static String serialize(Object obj, Map<Class<?>,
XmlAdapter<?,?>> classToAdapterMap) throws JAXBException
{
Object adaptedObj = null;
for (Class<?> clazz : classToAdapterMap.keySet()) {
if (clazz.isInstance(obj)) {
XmlAdapter<?,?> adapter = classToAdapterMap.get(clazz);
adaptedObj = adapter.marshal(clazz.cast(obj));
break;
}
}
// serialize
}
Clearly the problem is that the wildcard generically typed adapter isn't guaranteed to handle an object of type clazz. However, I can't indicate that these two are the same by changing the method signature—as I might otherwise do—to private final static <T> String serialize(Object obj, Map<Class<T>, XmlAdapter<?,T>> classToAdapterMap), because the map needs to hold adapters of all different types.
What would be a better way to do this? Or should I stick with the Reflection based solution?
Thanks in advance,
-Dan
There are several solutions to circumvent this problem.
Most likely, the easiest one is using raw types: don't specify the type parameters for the adapter, and the compiler will happily accept the marshall call (with a raw type warning of course):
XmlAdapter adapter = classToAdapterMap.get(clazz);
adaptedObj = adapter.marshal(obj);
(This is actually roughly the same solution as Bastian's, without the intermediate type)
If you don't like raw types, you may choose the unchecked cast to an Object-parameterized adapter. It's not really better, but it also works (by tricking the compiler…):
XmlAdapter<?, Object> adapter = (XmlAdapter<?, Object>) classToAdapterMap.get(clazz);
adaptedObj = adapter.marshal(obj);
My last solution is to use a type parameter at the method level. This time, what you do is semantically correct (as long as the map itself is correct), and the unchecked cast really means “I know what I am doing here”:
private final static <T> String serialize(T obj, Map<Class<?>,
XmlAdapter<?,?>> classToAdapterMap) throws JAXBException
{
Object adaptedObj = null;
for (Class<?> clazz : classToAdapterMap.keySet()) {
if (clazz.isInstance(obj)) {
try {
XmlAdapter<?, ? super T> adapter = (XmlAdapter<?, ? super T>) classToAdapterMap.get(clazz);
adaptedObj = adapter.marshal(obj);
break;
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
// serialize
}
The semantic correctness comes from the following:
you may consider T to be the actual class of obj since T is a method-bound parameter, not used elsewhere in the signature;
clazz is a super type of the type of T since we checked clazz.isInstance(obj);
adapter can handle instances of clazz or a super-type of it since it is how the map was built;
by consequent, adapter can handle all instances of an (unknown) super type of T, hence the ? super T declaration.
There is a simpler and safer way without using reflection:
At first, we need a small specialization of the XmlAdapter as it allows us to ask the adapter for the type it can handle.
public abstract class TalkingXmlAdapter<ValueType, BoundType> extends XmlAdapter<ValueType, BoundType> {
public abstract Class<BoundType> getBoundType();
}
My custom adapters now need to extend TalkingXmlAdapter:
public class AppleXmlAdapter extends TalkingXmlAdapter<String, Apple> {
#Override
public Class<Apple> getBoundType() {
return Apple.class;
}
#Override
public Apple unmarshal(String v) throws Exception {
System.out.println("Unmarshalling Apple");
return new Apple();
}
#Override
public String marshal(Apple v) throws Exception {
System.out.println("Marshalling Apple");
return "Apple";
}
}
public class BananaXmlAdapter extends TalkingXmlAdapter<String, Banana> {
#Override
public Class<Banana> getBoundType() {
return Banana.class;
}
#Override
public Banana unmarshal(String v) throws Exception {
System.out.println("Unmarshalling Banana");
return new Banana();
}
#Override
public String marshal(Banana v) throws Exception {
System.out.println("Marshalling Banana");
return "Banana";
}
}
That allows us to write a simplified serialization method:
public class SimpleSerializer {
public static final String serialize(Object obj, List<TalkingXmlAdapter> allAdapters) throws Exception {
Object adaptedObj = null;
for (TalkingXmlAdapter adapter : allAdapters) {
if (adapter.getBoundType().isInstance(obj)) {
adaptedObj = adapter.marshal(obj);
break;
}
}
// serialize
System.out.println("Simple serializing for " + obj.toString());
return "Simply serialized " + obj.toString();
}
}
Using the code e.g. like in the subsequent listing shows the behavior you want:
List<TalkingXmlAdapter> allAdapters = new ArrayList<>();
allAdapters.add(new AppleXmlAdapter());
allAdapters.add(new BananaXmlAdapter());
SimpleSerializer.serialize(new Banana(), allAdapters);
SimpleSerializer.serialize("Lemmon", allAdapters);
SimpleSerializer.serialize(new Apple(), allAdapters);
Output:
Marshalling Banana
Simple serializing for generic.adapter.Banana#659e0bfd
Simple serializing for Lemmon
Marshalling Apple
Simple serializing for generic.adapter.Apple#2a139a55
To sum this up, the solution gives you following advantages:
You don't need reflection which simplifies your code.
You need fewer generic programming in your serialization routine which simplifies your code.
The solution is more safe. Note that no type cast is needed. Every adapter accepts the type Object. However by using the generic method getBoundType() you can ensure the specific runtime type is the correct one. When building your map as in the reflection solution, a wrongly mapped class results in a runtime exception. In the proposed solution the super class TalkingXmlAdapter enforces each adapter to state their correct type by using generics.
The price you pay is:
Introduction of a new super type.
Requires small adaptions for your custom adapters.
Hope that helps!