You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I identified some violations of the SOLID principles in the current implementation of the Laundry, Transportation, and Service classes. To improve code quality and flexibility, I propose a refactoring using new classes and interfaces. Below, I outline the issues found and the implemented solution:
Identified Issues: Single Responsibility Principle (SRP) Violation:
The Laundry and Transportation classes are handling multiple responsibilities (input handling, cost logic, and detail storage), which goes against the SRP.
Open/Closed Principle (OCP) Violation:
The setDetails() methods in Laundry and Transportation depend on multiple cases, making it difficult to extend functionality without modifying the base code.
Interface Segregation Principle (ISP) Violation:
The Service class includes methods that aren’t necessary for all service types, such as getTotalCost and getStatus.
Solutions that I came with: Modularization through Strategies and Interfaces:
I created interfaces (Costeable, Statuseable, Detallable) and strategy classes (BasicWashStrategy, DeluxeWashStrategy, PremiumWashStrategy) to manage different wash cost types. This approach separates input handling and cost logic into independent classes.
Dependency Inversion Principle (DIP) Application:
Classes now depend on abstractions (interfaces) rather than concrete implementations, making it easier to extend service types without modifying existing classes.
I've attached some of the refactored code with the improvements incorporated:
public class Laundry implements Costeable, Statuseable, Detallable {
private CostStrategy costStrategy;
private int quantity;
private boolean status;
public Laundry(CostStrategy costStrategy, int quantity) {
this.costStrategy = costStrategy;
this.quantity = quantity;
this.status = false;
}
@Override
public void setDetails() {
this.status = true;
}
@Override
public int getTotalCost() {
return costStrategy.calculateCost(quantity);
}
@Override
public boolean getStatus() {
return status;
}
}
public class LaundryInputHandler {
private Scanner scanner;
public LaundryInputHandler() {
scanner = new Scanner(System.in);
}
public int getWashType() {
System.out.println("Enter type of wash (1/2/3): ");
return scanner.nextInt();
}
public int getClothesQuantity() {
System.out.println("Enter quantity of clothes: ");
return scanner.nextInt();
}
}
class PremiumWashStrategy implements CostStrategy {
@Override
public int calculateCost(int quantity) {
return quantity * 300;
}
}
class DeluxeWashStrategy implements CostStrategy {
@Override
public int calculateCost(int quantity) {
return quantity * 200;
}
}
class BasicWashStrategy implements CostStrategy {
@Override
public int calculateCost(int quantity) {
return quantity * 100;
}
}
The text was updated successfully, but these errors were encountered:
Hello madhuv-sharma
I identified some violations of the SOLID principles in the current implementation of the
Laundry
,Transportation
, andService
classes. To improve code quality and flexibility, I propose a refactoring using new classes and interfaces. Below, I outline the issues found and the implemented solution:Identified Issues:
Single Responsibility Principle (SRP) Violation:
The
Laundry
andTransportation
classes are handling multiple responsibilities (input handling, cost logic, and detail storage), which goes against the SRP.Open/Closed Principle (OCP) Violation:
The
setDetails()
methods in Laundry and Transportation depend on multiple cases, making it difficult to extend functionality without modifying the base code.Interface Segregation Principle (ISP) Violation:
The
Service
class includes methods that aren’t necessary for all service types, such asgetTotalCost
andgetStatus
.Solutions that I came with:
Modularization through Strategies and Interfaces:
I created interfaces (Costeable, Statuseable, Detallable) and strategy classes (BasicWashStrategy, DeluxeWashStrategy, PremiumWashStrategy) to manage different wash cost types. This approach separates input handling and cost logic into independent classes.
Dependency Inversion Principle (DIP) Application:
Classes now depend on abstractions (interfaces) rather than concrete implementations, making it easier to extend service types without modifying existing classes.
I've attached some of the refactored code with the improvements incorporated:
The text was updated successfully, but these errors were encountered: