ソフトウェア開発では、保守可能でスケーラブルで効率的なアプリケーションを作成するには、クリーンなコードの実践を遵守することが不可欠です。この規律を奨励する 1 つのアプローチは、開発者がより適切なオブジェクト指向コードを作成できるように設計された一連のルールであるオブジェクト キャリステニクスです。
この投稿では、オブジェクト キャリステニクスの原則と、それらを適用してよりクリーンで構造化されたコードを作成する方法について説明します。実際のコード例をさらに深く掘り下げたり、これらの原則が実際のプロジェクトでどのように実装されるかを知りたい場合は、私の GitHub リポジトリで詳細を確認してください。
さらに実践的な説明については、私の GitHub リポジトリにアクセスしてください。
オブジェクト体操は、オブジェクト指向の原則に従うことを促す 9 つのルールで構成されるプログラミング演習です。ルール自体は、Jeff Bay によって著書『The ThoughtWorks Anthology』で紹介されました。目的は、これらの制約に従うことで、コードの設計と構造にさらに重点を置くことを促すことです。
9 つのルールは次のとおりです:
この原則は、各メソッドのインデントは 1 レベルのみであるべきであると述べています。インデントのレベルを低く保つことで、可読性が向上し、コードの保守が容易になります。メソッドのインデントのレベルが多すぎる場合、多くの場合、内部のロジックが複雑すぎるため、より小さな部分に分割する必要があることを示しています。
実装例
以下は、この原則に従わないメソッドの例です:
public class OrderService {
public void processOrder(Order order) {
if (order.isValid()) {
if (order.hasStock()) {
if (order.hasEnoughBalance()) {
order.ship();
} else {
System.out.println("Insufficient balance.");
}
} else {
System.out.println("Stock unavailable.");
}
} else {
System.out.println("Invalid order.");
}
}
}
上記のコードでは、processOrder メソッドに複数のレベルのインデントがあり、特にロジックが複雑になると読みにくくなります。
それでは、ロジックを単純化することで原理に従う方法を見てみましょう。
public class OrderService {
public void processOrder(Order order) {
if (!isOrderValid(order)) return;
if (!hasStock(order)) return;
if (!hasEnoughBalance(order)) return;
shipOrder(order);
}
private boolean isOrderValid(Order order) {
if (!order.isValid()) {
System.out.println("Invalid order.");
return false;
}
return true;
}
private boolean hasStock(Order order) {
if (!order.hasStock()) {
System.out.println("Stock unavailable.");
return false;
}
return true;
}
private boolean hasEnoughBalance(Order order) {
if (!order.hasEnoughBalance()) {
System.out.println("Insufficient balance.");
return false;
}
return true;
}
private void shipOrder(Order order) {
order.ship();
}
}
このバージョンでは、ロジック ブロックごとに 1 レベルのインデントがあり、コードがクリーンになり、保守が容易になります。
オブジェクト指向プログラミングでは、else キーワードを使用すると、コードが乱雑で保守が困難になることがよくあります。 else ステートメントに依存する代わりに、早期リターンまたはポリモーフィズムを使用してコードを構造化できます。このアプローチにより、可読性が向上し、複雑さが軽減され、コードがより保守しやすくなります。
まず、else キーワードを使用する例を見てみましょう:
public class Order {
public void processOrder(boolean hasStock, boolean isPaid) {
if (hasStock && isPaid) {
System.out.println("Order processed.");
} else {
System.out.println("Order cannot be processed.");
}
}
}
この例では、else ステートメントにより否定的なケースを明示的に処理する必要があり、さらに複雑になります。ここで、else の使用を避けるためにこれをリファクタリングしましょう:
public class Order {
public void processOrder(boolean hasStock, boolean isPaid) {
if (!hasStock) {
System.out.println("Order cannot be processed: out of stock.");
return;
}
if (!isPaid) {
System.out.println("Order cannot be processed: payment pending.");
return;
}
System.out.println("Order processed.");
}
}
else を削除することで、各セクションが 1 つの責任を処理する、より焦点を絞ったコードを作成できます。これは「単一責任原則」と一致しており、よりクリーンで保守しやすいソフトウェアの作成に役立ちます。
オブジェクト体操における重要な実践の 1 つは、すべてのプリミティブと文字列をカスタム クラスでラップすることです。このルールは、開発者がコード内で生のプリミティブ型や文字列を直接使用することを避けることを奨励します。代わりに、それらを意味のあるオブジェクト内にカプセル化する必要があります。このアプローチにより、より表現力が豊かで理解しやすく、管理できなくなることなく複雑になってもよいコードが得られます。
プリミティブ型と文字列を直接使用する例を考えてみましょう:
public class Order {
private int quantity;
private double pricePerUnit;
private String productName;
public Order(int quantity, double pricePerUnit, String productName) {
this.quantity = quantity;
this.pricePerUnit = pricePerUnit;
this.productName = productName;
}
public double calculateTotal() {
return quantity * pricePerUnit;
}
}
このコードでは、int、double、String が直接使用されています。これは単純に見えるかもしれませんが、各値の意図が明確に表現されていないため、後からそれらの値に固有の新しい動作や制約を導入することが難しくなります。
次に、このコードをリファクタリングして プリミティブと文字列をラップしましょう:
public class Quantity {
private final int value;
public Quantity(int value) {
if (value < 1) {
throw new IllegalArgumentException("Quantity must be greater than zero.");
}
this.value = value;
}
public int getValue() {
return value;
}
}
public class Price {
private final double value;
public Price(double value) {
if (value <= 0) {
throw new IllegalArgumentException("Price must be positive.");
}
this.value = value;
}
public double getValue() {
return value;
}
}
public class ProductName {
private final String name;
public ProductName(String name) {
if (name == null || name.isEmpty()) {
throw new IllegalArgumentException("Product name cannot be empty.");
}
this.name = name;
}
public String getValue() {
return name;
}
}
public class Order {
private final Quantity quantity;
private final Price pricePerUnit;
private final ProductName productName;
public Order(Quantity quantity, Price pricePerUnit, ProductName productName) {
this.quantity = quantity;
this.pricePerUnit = pricePerUnit;
this.productName = productName;
}
public double calculateTotal() {
return quantity.getValue() * pricePerUnit.getValue();
}
}
主な変更点:
リストやマップなどのコレクションを使用するときは、必ずそれを専用のオブジェクトにします。これにより、コードがクリーンな状態に保たれ、コレクションに関連するロジックが確実にカプセル化されます。
Problem: Using a Raw Collection Directly
public class Order {
private List<String> items;
public Order() {
this.items = new ArrayList<>();
}
public void addItem(String item) {
items.add(item);
}
public List<String> getItems() {
return items;
}
}
In this example, Order directly uses a List
Solution: Using a First-Class Collection
public class Order {
private Items items;
public Order() {
this.items = new Items();
}
public void addItem(String item) {
items.add(item);
}
public List<String> getItems() {
return items.getAll();
}
}
class Items {
private List<String> items;
public Items() {
this.items = new ArrayList<>();
}
public void add(String item) {
items.add(item);
}
public List<String> getAll() {
return new ArrayList<>(items); // Return a copy to prevent external modification
}
public int size() {
return items.size();
}
}
Explanation:
Benefits of First-Class Collections:
One Dot Per Line is an Object Calisthenics rule that encourages developers to avoid chaining multiple method calls on a single line. The principle focuses on readability, maintainability, and debugging ease by ensuring that each line in the code only contains a single method call (represented by one "dot").
The Problem with Method Chaining (Multiple Dots Per Line)
When multiple methods are chained together on one line, it can become difficult to:
Example: Multiple Dots Per Line (Anti-Pattern)
public class OrderProcessor {
public void process(Order order) {
String city = order.getCustomer().getAddress().getCity().toUpperCase();
}
}
In this example, we have multiple method calls chained together (getCustomer(), getAddress(), getCity(), toUpperCase()). This makes the line of code compact but harder to understand and maintain.
Solution: One Dot Per Line
By breaking down the method chain, we make the code easier to read and debug:
public class OrderProcessor {
public void process(Order order) {
Customer customer = order.getCustomer(); // One dot: getCustomer()
Address address = customer.getAddress(); // One dot: getAddress()
String city = address.getCity(); // One dot: getCity()
String upperCaseCity = city.toUpperCase(); // One dot: toUpperCase()
}
}
This code follows the One Dot Per Line rule by breaking down a method chain into smaller, readable pieces, ensuring that each line performs only one action. This approach increases readability, making it clear what each step does, and improves maintainability by making future changes easier to implement. Moreover, this method helps during debugging, since each operation is isolated and can be checked independently if any errors occur.
In short, the code emphasizes clarity, separation of concerns, and ease of future modifications, which are key benefits of applying Object Calisthenics rules such as One Dot Per Line.
One of the key rules in Object Calisthenics is Don’t Abbreviate, which emphasizes clarity and maintainability by avoiding cryptic or shortened variable names. When we name variables, methods, or classes, it’s important to use full, descriptive names that accurately convey their purpose.
Example of Bad Practice (With Abbreviations):
public class EmpMgr {
public void calcSal(Emp emp) {
double sal = emp.getSal();
// Salary calculation logic
}
}
Example of Good Practice (Without Abbreviations):
public class EmployeeManager {
public void calculateSalary(Employee employee) {
double salary = employee.getSalary();
// Salary calculation logic
}
}
By avoiding abbreviations, we make our code more understandable and maintainable, especially for other developers (or even ourselves) who will work on it in the future.
In Object Calisthenics, one of the fundamental rules is Keep Entities Small, which encourages us to break down large classes or methods into smaller, more manageable ones. Each entity (class, method, etc.) should ideally have one responsibility, making it easier to understand, maintain, and extend.
Example of Bad Practice (Large Class with Multiple Responsibilities):
public class Employee {
private String name;
private String address;
private String department;
public void updateAddress(String newAddress) {
this.address = newAddress;
}
public void promote(String newDepartment) {
this.department = newDepartment;
}
public void generatePaySlip() {
// Logic for generating a payslip
}
public void calculateTaxes() {
// Logic for calculating taxes
}
}
In this example, the Employee class is doing too much. It’s handling address updates, promotions, payslip generation, and tax calculation. This makes the class harder to manage and violates the Single Responsibility Principle.
Example of Good Practice (Small Entities with Single Responsibilities):
public class Employee {
private String name;
private String address;
private String department;
public void updateAddress(String newAddress) {
this.address = newAddress;
}
public void promote(String newDepartment) {
this.department = newDepartment;
}
}
public class PaySlipGenerator {
public void generate(Employee employee) {
// Logic for generating a payslip for an employee
}
}
public class TaxCalculator {
public double calculate(Employee employee) {
// Logic for calculating taxes for an employee
return 0.0;
}
}
By breaking the class into smaller entities, we:
The principle of avoiding getters and setters encourages encapsulation by ensuring that classes manage their own data and behavior. Instead of exposing internal state, we should focus on providing meaningful methods that perform actions relevant to the class's responsibility.
Consider the following example that uses getters and setters:
public class BankAccount {
private double balance;
public double getBalance() {
return balance;
}
public void setBalance(double balance) {
this.balance = balance;
}
public void deposit(double amount) {
balance += amount;
}
public void withdraw(double amount) {
if (amount <= balance) {
balance -= amount;
}
}
}
In this example, the getBalance method exposes the internal state of the BankAccount class, allowing direct access to the balance variable.
A better approach would be to avoid exposing the balance directly and provide methods that represent the actions that can be performed on the account:
public class BankAccount {
private double balance;
public void deposit(double amount) {
balance += amount;
}
public void withdraw(double amount) {
if (amount <= balance) {
balance -= amount;
}
}
public boolean hasSufficientFunds(double amount) {
return amount <= balance;
}
}
In this revised example, the BankAccount class no longer has getters or setters. Instead, it provides methods for depositing, withdrawing, and checking if there are sufficient funds. This approach maintains the integrity of the internal state and enforces rules about how the data can be manipulated, promoting better encapsulation and adherence to the single responsibility principle.
The principle of separating user interface (UI) code from business logic is essential for creating maintainable and testable applications. By keeping these concerns distinct, we can make changes to the UI without affecting the underlying business rules and vice versa.
Consider the following example where the UI and business logic are intertwined:
public class UserRegistration {
public void registerUser(String username, String password) {
// UI Logic: Validation
if (username.isEmpty() || password.length() < 6) {
System.out.println("Invalid username or password.");
return;
}
// Business Logic: Registration
System.out.println("User " + username + " registered successfully.");
}
}
In this example, the registerUser method contains both UI logic (input validation) and business logic (registration). This makes the method harder to test and maintain.
A better approach is to separate the UI from the business logic, as shown in the following example:
public class UserRegistration {
public void registerUser(User user) {
// Business Logic: Registration
System.out.println("User " + user.getUsername() + " registered successfully.");
}
}
public class UserRegistrationController {
private UserRegistration userRegistration;
public UserRegistrationController(UserRegistration userRegistration) {
this.userRegistration = userRegistration;
}
public void handleRegistration(String username, String password) {
// UI Logic: Validation
if (username.isEmpty() || password.length() < 6) {
System.out.println("Invalid username or password.");
return;
}
User user = new User(username, password);
userRegistration.registerUser(user);
}
}
class User {
private String username;
private String password;
public User(String username, String password) {
this.username = username;
this.password = password;
}
public String getUsername() {
return username;
}
}
In this improved design, the UserRegistration class contains only the business logic for registering a user. The UserRegistrationController is responsible for handling UI logic, such as input validation and user interaction. This separation makes it easier to test and maintain the business logic without being affected by changes in the UI.
By adhering to this principle, we enhance the maintainability and testability of our applications, making them easier to adapt to future requirements.
Object Calisthenics might seem a bit strict at first, but give it a try! It's all about writing cleaner, more maintainable code that feels good to work with. So, why not challenge yourself? Start small, and before you know it, you’ll be crafting code that not only works but also shines. Happy coding!
以上がオブジェクトの体操を理解する: よりクリーンなコードを作成するの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
