According to the SOLID principle open and close principle says class is open for extension and closed for modification.
So I am allowed to add new logic based on new if-else conditions?
If I will not use conditionals so how will I identify based on which condition which action has to be applied
public interface TemplateClassification {
QuesObj processTemplate(RawPart rawPart);
}
public class Template1 implements TemplateClassification{
#Override
public QuesObj processTemplate(RawPart rawPart) {
return new QuesObj("Hi header 1"+rawPart.getHead(),"Hi I am footer 1"+rawPart.getFoot());
}
}
public class Template2 implements TemplateClassification{
#Override
public QuesObj processTemplate(RawPart rawPart) {
return new QuesObj("Hi header 2"+rawPart.getHead(),"Hi I am footer "+rawPart.getFoot());
}
}
public class TemplateInfo {
private TemplateClassification templateClassification;
public TemplateClassification getTemplateClassification() {
return templateClassification;
}
public void setTemplateClassification(TemplateClassification templateClassification) {
this.templateClassification = templateClassification;
}
}
public class TemplateProduct {
public QuesObj calculateTemplate(TemplateInfo templateInfo,RawPart rawPart){
QuesObj ques = templateInfo.getTemplateClassification().processTemplate(rawPart);
return ques;
}
}
#RestController
class Pg {
#Autowired
TemplateInfo templateInfo;
#Autowired
TemplateProduct templateProduct;
public doProcessing(RawPart rawPart){
QuesObj ques = null;
if(rawPart.getId() == 1){
Template1 temp = new Template1();
ques = templateProduct.calculateTemplate(templateInfo,rawPart);
}
elseIf(rawPart.getId() == 2){
Template2 temp = new Template2();
ques = templateProduct.calculateTemplate(templateInfo,rawPart);
}
elseIf(tempId == 3){
// coming soon
}
}
}
How can i eliminte the if else condition so that it can follow open-close principle
To implement the "O" in SOLID, you can follow the below, which includes the "S" as well.
We are going to use polymorphism and inheritance.
Step 1 :
Create an interface that will sit in front of the classes that will be responsible in creating the QuesObj. We are going to need this, because down the line the code could receive a creator (child class) when id is 1,2 or 3.
It is important to note that QuesObj was identified because that is being returned on your original if statements and this is the reason we are allowed to continue with this approach.
public interface QuesObjCreator {
QuesObj calculate(RawPart rawPart);
}
Step 2:
Create individual class that creates the QuesObj in different ways in The only role of that class is to create the object.
public class QuesObjCreatorFor1 implements QuesObjCreator {
private TemplateInfo templateInfo;
private TemplateProduct templateProduct;
#Override
public QuesObj calculate(RawPart rawPart) {
Template1 temp = new Template1();
return templateProduct.calculateTemplate(templateInfo,rawPart);
}
}
public class QuesObjCreatorFor2 implements QuesObjCreator {
private TemplateInfo templateInfo;
private TemplateProduct templateProduct;
#Override
public QuesObj calculate(RawPart rawPart) {
Template2 temp = new Template2();
return templateProduct.calculateTemplate(templateInfo,rawPart);
}
}
Step 3:
Create a factory to return a QuesObjCreator. The factory will be returned to your main code/service.
public class QuesObjectCreatorFactory {
private static final Map<Integer,QuesObjCreator> quesObjCreatorMap = new HashMap<>();
public QuesObjectCreatorFactory() {
quesObjCreatorMap.put(1,new QuesObjCreatorFor1());
quesObjCreatorMap.put(2,new QuesObjCreatorFor2());
}
public static QuesObjCreator getQuesObjCreator(final int number) {
final QuesObjCreator quesObjCreator = quesObjCreatorMap.get(number);
if(quesObjCreator == null) {
throw new IllegalArgumentException("QuesObj for "+number+" does not exist");
}
return quesObjCreator;
}
}
Step 4:
Use Factory to create the QuesObj
public class Pg {
public void doProcessing(RawPart rawPart){
final QuesObjCreator quesObjCreator = QuesObjectCreatorFactory.getQuesObjCreator(rawPart.getId());
QuesObj ques = quesObjCreator.calculate(rawPart);
}
}
Collectively we achieved the Single responsibility across all classes and are decoupled.
It is easy to maintain cause now you can add more options to create QuesObj and none of the code would change, thus achieving open for extensibility/closed for modification.
It all boils down to the Factory and Map that has the creators. The map has to be populated with all the creator instances. With Spring this can be very easy, as Spring can scan your project, find beans of a specific type, give you a List and then you can convert it to a map.
Your case has nothing to do with SOLID. According to open-closed principle, you cannot allow modification to your class IN RUNTIME that can break its behavior.
In your case I suggest the following:
Add getId() method to your TemplateClassification interface.
Make each TemplateClassification implementation a bean
Add bean that will form the map of templates for you
#Bean
public Map<Integer, TemplateClassification> templates(List<TemplateClassification> templates) {
return algorithms.stream()
.collect(Collectors.toMap(TemplateClassification::getId, Function.identity()));
}
Autowire Map<Integter, TemplateClassification> templates to your controller and find the required template by id.
Related
I have a client like with a constructor which is quite lengthy in terms of the argument list , e.g,
Class Client {
private ServiceA _serviceA;
private ServiceB _serviceB;
....
private ServiceE _serviceE;
public Client(ServiceA serviceA, ServiceB serviceB,...ServiceE service E) { ... }
public doTask1(TypeA typeA) { //only serviceA, serviceB service being used... }
public doTask2(TypeB typeB) { //only serviceD, serviceE being used ... }
}
I want to use a service facade here to prune the constructor argument list. However, I am pretty confused as the core responsibility of the facade implementation. So I have written down a facade with the services as the class variables and their getters , as below:
Class Facade {
private ServiceA _serviceA;
private ServiceB _serviceB;
....
private ServiceE _serviceE;
getters () ...
}
Is this correct way to abstract facade in this case. If not , what would have been the proper way to refactor the Client class?
Facedes has a completely different intent: they are created to encapsulate and hide the underlying structure and behaviour of classes. Take an example of a car. It's made of many components: on-board computer, fuel pump, engine etc. If you want to start it, just press the start button:
class FuelPump {
private boolean pumpTurnedOn;
public FuelPump() {
pumpTunrnedOn=false;
}
public boolean isPumpTunredOn() {
return pumpTurnedOn;
}
public void setPumpTurnedOn (boolean newState) {
pumpTurndeOn=newState;
if (newState) {
System.out.println ("fuel pump now is on");
} else {
System.out.println ("fuel pump now is turned off");
}
}
}
class Engine {
private boolean engineStarted;
public Engine() {
engineStarted=false;
}
public boolean isEngineStarted() {
return engineStarted;
}
public void setEngineStarted (boolean newState) {
engineStarted=newState;
if (newState) {
System.out.println("engine now is on");
} else {
System.out.println("engine now is turned off");
}
}
}
// this is the Car facade:
class Car {
private FuelPump fuelPump;
private Engine engine;
// + other components of Car
public Car () {
fuelPump = new FuelPump();
engine = new Engine();
}
public void startCar() {
fuelPump.setPumpTurnedOn(true);
engine.setEngineStarted(true);
// + other methods of start procedures with other components
System.out.println("Your car has been startded");
}
public void stopCar() {
engine.setEngineStarted(false);
fuelPump.setPumpTurnedOn(false);
// + other methods on other components for shutting down car
}
}
The client code snippet:
Car car=new Car();
car.startCar();
// later on
car.stopCar();
As you may see the client doesn't know anything about the underlying components to start the car. It has only to use the startCar() method, and the Car facade will do the rest. Facade is a structural pattern.
If you have many constructor arguments and want to reduece them use one of the creational patterns. In case you have compulsory and non compulsory fields I suggest using the builder pattern.
For example your compulsory constructor arguments are Service_A and Service_B and Service_C to Service_E are not required.
Then your ClientBuilder class should like be this:
class ClientBuilder{
private static Service_A serviceA; // required
private static Service_B serviceB; // required
private static Service_C serviceC;
private static Service_D serviceD;
private static Service_E serviceE;
// since this builder is singleton
private static ClientBuilder builderInstance = new ClientBuilder();
private ClientBuilder () {};
public static ClientBuilder getBuilderInstance (Service_A service_A, Service_B service_B){
serviceA = service_A;
serviceB = service_B;
serviceC = null;
serviceD = null;
serviceE = null;
return builderInstance;
}
public static ClientBuilder addServiceC (Service_C service_C) {
serviceC = service_C;
return builderInstance;
}
public static ClientBuilder addServiceD (Service_D service_D) {
serviceC = service_D;
return builderInstance;
}
public static ClientBuilder addServiceE (Service_E service_E) {
serviceE = service_E;
return builderInstance;
}
public static Client build(){
return new Client (serviceA, ServiceB, ServiceC, ServiceD, ServiceE);
}
In this case you can instantinate your Client class only with the mandatory arguments. The best thing is the not required arguments' order are interchangeable:
Client aClient = ClientBuilder.getBuilderInstance(aServiceA, aServiceB)
.addServiceE(aServiceE)
.addServiceC(aServiceC)
.build();
Now aClient has been created with services A,B,C,E and serviceD remains null. Later you can set it by appropriate setter. The getters and setters must be in your Client class.
To put it in a nutshell, with builder class you can reduce the number of constructor arguments only for the mandatory and set up optional fields later with setters.
You can read more details in the Gang of Four book or if you are a serious Java fun I suggest Head First's Design Patterns book.
Hope I could help you, bye!
I'm working on a small project where I want to have a list of a class called "DevelopmentEmployee", but only one of them is allowed to manipulate certain methods in another class "Project". The way I have implemented it, the class Project has a field called projectLeader, which is of the type DevelopmentEmployee. When a DevelopmentEmployee attempts to access methods in the class Project, I want to check if the DevelopmentEmployee is equal to the specific instance of Project's projectLeader.
Something like
public class Project {
private DevelopmentEmployee projectLeader;
private List < Activity > activities = new ArrayList < Activity > ();
public Project(DevelopmentEmployee pL) {
this.projectLeader = pL;
}
public void addActivity(String activityName) {
if (projectLeader.equals(DevelopmentEmployee * ) {
activities.add(activity);
}
}
}
But I can't figure out a way to make the access requirement work. How can the instance of the class Project know who is trying to access it?
You should also pass the DevelopementEmployee in addActivity for checking it against the projectLeader.
public void addActivity(String activityName,DevelopmentEmployee employee) {
if (projectLeader.equals(employee) {
activities.add(activity);
}
}
Then you need to override equals method in DevelopmentEmployee class, for proper checking of equality, like the one as shown below :
public boolean equals(DevelopementEmployee e){
if(e!=null && this.employeeId==e.employeeId)
return true;
else
return false;
}
Several possibilities come to mind:
Provide the instance of the one accassing the project method to the method:
public void addActivity(String activityName, DevelpmentEmployee user) {
if (projectLeader.equals(user)) {`
Create some class that holds information about active user and use that inside the methods:
public class Project {
private UserRegistry userRegistry;
private List<Activity> activities = new ArrayList<Activity>();
public Project(UserRegistry userRegistry) {
this.userRegistry = userRegistry;
}
public void addActivity(String activityName) {
if (userRegistry.isActiveUserProjectLeader()) {
activities.add(activity);
}
}
}
public class UserRegistry {
private DevelpmentEmployee projectLeader;
private DevelpmentEmployee activeUser;
private List<DevelpmentEmployee> user;
public void addUser(DevelpmentEmployee user) { ... }
public void makeProjectLeader(DevelpmentEmployee newLeader) { ... }
public void makeActiveUser(DevelpmentEmployee newActiveUser) { ... }
public boolean isActiveUserProjectLeader() { ... }
}`
I need to build a process which will validate a record against ~200 validation rules. A record can be one of ~10 types. There is some segmentation from validation rules to record types but there exists a lot of overlap which prevents me from cleanly binning the validation rules.
During my design I'm considering a chain of responsibility pattern for all of the validation rules. Is this a good idea or is there a better design pattern?
Validation is frequently a Composite pattern. When you break it down, you want to seperate the what you want to from the how you want to do it, you get:
If foo is valid
then do something.
Here we have the abstraction is valid -- Caveat: This code was lifted from currrent, similar examples so you may find missing symbology and such. But this is so you get the picture. In addition, the
Result
Object contains messaging about the failure as well as a simple status (true/false).
This allow you the option of just asking "did it pass?" vs. "If it failed, tell me why"
QuickCollection
and
QuickMap
Are convenience classes for taking any class and quickly turning them into those respected types by merely assigning to a delegate. For this example it means your composite validator is already a collection and can be iterated, for example.
You had a secondary problem in your question: "cleanly binding" as in, "Type A" -> rules{a,b,c}" and "Type B" -> rules{c,e,z}"
This is easily managed with a Map. Not entirely a Command pattern but close
Map<Type,Validator> typeValidators = new HashMap<>();
Setup the validator for each type then create a mapping between types. This is really best done as bean config if you're using Java but Definitely use dependency injection
public interface Validator<T>{
public Result validate(T value);
public static interface Result {
public static final Result OK = new Result() {
#Override
public String getMessage() {
return "OK";
}
#Override
public String toString() {
return "OK";
}
#Override
public boolean isOk() {
return true;
}
};
public boolean isOk();
public String getMessage();
}
}
Now some simple implementations to show the point:
public class MinLengthValidator implements Validator<String> {
private final SimpleResult FAILED;
private Integer minLength;
public MinLengthValidator() {
this(8);
}
public MinLengthValidator(Integer minLength) {
this.minLength = minLength;
FAILED = new SimpleResult("Password must be at least "+minLength+" characters",false);
}
#Override
public Result validate(String newPassword) {
return newPassword.length() >= minLength ? Result.OK : FAILED;
}
#Override
public String toString() {
return this.getClass().getSimpleName();
}
}
Here is another we will combine with
public class NotCurrentValidator implements Validator<String> {
#Autowired
#Qualifier("userPasswordEncoder")
private PasswordEncoder encoder;
private static final SimpleResult FAILED = new SimpleResult("Password cannot be your current password",false);
#Override
public Result validate(String newPassword) {
boolean passed = !encoder.matches(newPassword,user.getPassword());
return (passed ? Result.OK : FAILED);
}
#Override
public String toString() {
return this.getClass().getSimpleName();
}
}
Now here is a composite:
public class CompositePasswordRule extends QuickCollection<Validator> implements Validator<String> {
public CompositeValidator(Collection<Validator> rules) {
super.delegate = rules;
}
public CompositeValidator(Validator<?>... rules) {
super.delegate = Arrays.asList(rules);
}
#Override
public CompositeResult validate(String newPassword) {
CompositeResult result = new CompositeResult(super.delegate.size());
for(Validator rule : super.delegate){
Result temp = rule.validate(newPassword);
if(!temp.isOk())
result.put(rule,temp);
}
return result;
}
public static class CompositeResult extends QuickMap<Validator,Result> implements Result {
private Integer appliedCount;
private CompositeResult(Integer appliedCount) {
super.delegate = VdcCollections.delimitedMap(new HashMap<PasswordRule, Result>(), "-->",", ");
this.appliedCount = appliedCount;
}
#Override
public String getMessage() {
return super.delegate.toString();
}
#Override
public String toString() {
return super.delegate.toString();
}
#Override
public boolean isOk() {
boolean isOk = true;
for (Result r : delegate.values()) {
isOk = r.isOk();
if(!isOk)
break;
}
return isOk;
}
public Integer failCount() {
return this.size();
}
public Integer passCount() {
return appliedCount - this.size();
}
}
}
and now a snippet of use:
private Validator<String> pwRule = new CompositeValidator<String>(new MinLengthValidator(),new NotCurrentValidator());
Validator.Result result = pwRule.validate(newPassword);
if(!result.isOk())
throw new PasswordConstraintException("%s", result.getMessage());
user.obsoleteCurrentPassword();
user.setPassword(passwordEncoder.encode(newPassword));
user.setPwExpDate(DateTime.now().plusDays(passwordDaysToLive).toDate());
userDao.updateUser(user);
Chain of responsibility implies that there is an order in which the validations must take place. I would probably use something similar to the Strategy pattern where you have a Set of validation strategies that are applied to a specific type of record. You could then use a factory to examine the record and apply the correct set of validations.
I have the following db table:
id method_id
1 1
1 2
1 3
and 2 classes:
EmailController and Smscontroller
in my code, I need to iterate over the table and according to the method_id (1 or 2) to invoke the send method of either EmailController or Smscontroller.
What is the recommended design pattern for it?
EDITED
There could be 100 methods! I put only 3. This is why I do not prefer the if else.
As well, the object that I send to EmailController send method is different than the one that I send to SmsController send method.
In EmailController I need to send User object.
In SmsController I need to send Manager object
I can't think of a design pattern. But for ultimate flexibility you can have a design similar to this:
public interface Sendable /* or Sender, SendingManager, etc. */ {
public int getId();
public void send();
}
public class EmailController implements Sendable {
}
public class SmsController implements Sendable {
}
public class Sendables {
private Map<Integer, Sendable> sendables = new HashMap<Integer, Sendable>();
public void addSendable(Sendable s) {
this.sendables.put(s.getId(), s);
}
public void sendById(Integer id) {
this.sendables.get(id).send();
}
}
Then you can use it like this:
Sendables sendables = new Sendables();
sendables.add(new EmailController());
sendables.add(new SmsController());
sendables.add(new ChatController());
// etc.
Row row = table.getRow(...); // let's assume this gets a row from your table
sendables.send(row.getId());
Another solution could be to have an extra table like this:
TABLE: CLASS_NAMES
method_id class_name
1 "com.foo.SmsController"
2 "com.foo.EmailController"
And then pass class_name to Class.forName and let it instantiate the appropriate controller for you to use.
EDIT: A reflection-based version of the code as suggested by Luis. Note that for production use you should ensure that the passed parameters are valid (not null, etc.) and also handle exceptions with rigor.
TABLE: CLASS_NAMES
method_id class_name param_class_name
1 "com.foo.SmsController" "com.foo.Manager"
2 "com.foo.EmailController" "com.foo.User"
SendManager
public class SendManager {
private static final String SEND_METHOD_NAME = "send";
/* DAO for the CLASS_NAMES tables */
private ClassNameDAO classNameDao;
/**
* Gets the row corresponding to methodId, for example
* (1, "com.foo.SmsController", "com.foo.Manager") then using reflection
* instantiates an instance of SmsController and invokes its send method
* with <code>param</code> passed to it.
*/
public void send(int methodId, Object param) throws Exception {
ClassNameRow classNameRow = classNameDao.findByMethodId(methodId);
String senderParameterClassName = className.senderParameterClassName();
Class paramClass = Class.forName(senderParameterClassName);
if (!paramClass.isInstance(param)) {
throw new IllegalArgumentException("methodId and param are not compatible");
}
String senderClassName = classNameRow.getSenderClassName();
Class senderClass = Class.forName(senderClassName);
/* Your sender classes must be JavaBeans and have no-arg constructors */
Object sender = senderClass.newInstance();
Class paramClass = Class.forName(senderParameterClassName);
Method send = senderClass.getMethod(SEND_METHOD_NAME, paramClass);
send.invoke(sender, param);
}
}
Sample Usage
SendManager sendManager = new SendManager();
Manager m = ...;
sendManager.send(1, m);
User u = ...;
sendManager.send(2, u);
How about this:
abstract class Controller {
public static Controller getInstance(int methodId) {
switch (methodId) {
case 1:
return new EmailController();
case 2:
return new SmsController();
default:
return null;
}
}
public abstract void send();
}
class EmailController extends Controller {
#Override
public void send() {
System.out.println("sending email");
}
}
class SmsController extends Controller {
#Override
public void send() {
System.out.println("sending sms");
}
}
And use it like this:
Controller.getInstance(methodId).send();
I'm using the Strategy pattern and the Factory Method pattern in my solution.
Strategy Pattern
http://johnlindquist.com/2010/08/25/patterncraft-strategy-pattern/
http://en.wikipedia.org/wiki/Strategy_pattern
I am having an abstract factory class StudentValidatorFactory which is suppossed to create(based on a specified parameter) various StudentValidator class instances to which a validation map has to be injected (see the code bellow).
public class StudentValidatorFactory{
public static final int JUNIOR_STUDENT_TYPE = 1;
public static final int SENIOR_STUDENT_TYPE = 2;
public StudentValidator createStudentValidator(int studentType) throws StudentValidatorCreationException{
Map<String,ValidationBean> validationMap = readValiationMapFromPersistentOrCachedStorage(studentType);
switch (studentType){
case JUNIOR_STUDENT:
return new JuniorStudentValidator(validationMap);
case SENIOR_STUDENT:
return new SeniorStudentValidator(validationMap);
}
}
}
public interface StudentValidator{
void validate(Student student) throws StudentValidationException;
}
public class JuniorStudentValidator{
private Map<String, ValidationBean> validationMap;
public JuniorStudentValidator(Map<String,ValidationBean> validationMap){
this.validationMap = validationMap;
}
public void validate(Student student) throws StudentValidationException{
// make use of validation map for apply junior student related validations on the student
}
}
public class SeniorStudentValidator{
private Map<String, ValidationBean> validationMap;
public SeniorStudentValidator(Map<String,ValidationBean> validationMap){
this.validationMap = validationMap;
}
public void validate(Student student) throws StudentValidationException{
// make use of validation map for apply senior student related validations on the student
}
}
My question is about the StudentValidatorFactory.createStudentValidator(int studentType) method whether reading the validation map from a persistent storage (based on the student type) should be done within the create method ? Otherwise said, should the factory be aware/dependent about such implementation details?
I'd appreciate if there would be a solution to avoid the switch(studentType) statement when creating the student validator - an idea on top of my head is to have an internally managed map and perform the StudentValidator concrete class instantiation via reflection .
Advantages of using such a technique is that the validators are much easier to be tested (through dependency injection).
Extract the readValiationMapFromPersistentOrCachedStorage(studentType) in a separated service interface StudentValidatorService and inject an instance of the service in the StudentValidatorFactory using a property or constructor argument:
public interface StudentValidatorService {
Map<String,ValidationBean> getValidationMap(int studentType);
}
public class StudentValidatorFactory{
public static final int JUNIOR_STUDENT_TYPE = 1;
public static final int SENIOR_STUDENT_TYPE = 2;
public StudentValidatorFactory(StudentValidatorService studentValidatorService) {
this.studentValidatorService = studentValidatorService;
}
public StudentValidator createStudentValidator(int studentType) throws StudentValidatorCreationException{
Map<String,ValidationBean> validationMap = studentValidatorService.getValidationMap(studentType);
switch (studentType){
case JUNIOR_STUDENT:
return new JuniorStudentValidator(validationMap);
case SENIOR_STUDENT:
return new SeniorStudentValidator(validationMap);
}
}
}
Now you can write an implementation of StudentValidatorService backed by database. Or you can write a mock implementation for testing. The implementation is now decoupled from the usage.
To remove the switch-case, invert it using an enum:
public enum StudentType {
JUNIOR_STUDENT {
public StudentValidator getValidator(Map<String,ValidationBean> validationMap) {
return new JuniorStudentValidator(validationMap);
}
},
SENIOR_STUDENT {
public StudentValidator getValidator(Map<String,ValidationBean> validationMap) {
return new SeniorStudentValidator(validationMap);
}
};
public abstract StudentValidator getValidator(Map<String,ValidationBean> validationMap);
}
public class StudentValidatorFactory{
public StudentValidatorFactory(StudentValidatorService studentValidatorService) {
this.studentValidatorService = studentValidatorService;
}
public StudentValidator createStudentValidator(StudentType studentType) throws StudentValidatorCreationException{
Map<String,ValidationBean> validationMap = studentValidatorService.getValidationMap(studentType);
return studentType.getValidator(validationMap);
}
}