Objekt-Calisthenics verstehen: Saubereren Code schreiben

Bei der Softwareentwicklung ist die Einhaltung sauberer Codepraktiken für die Erstellung wartbarer, skalierbarer und effizienter Anwendungen von entscheidender Bedeutung. Ein Ansatz, der diese Disziplin fördert, ist Object Calisthenics, ein Regelwerk, das Entwicklern dabei helfen soll, besseren objektorientierten Code zu schreiben.

In diesem Beitrag werde ich die Prinzipien der Object Calisthenics untersuchen und wie sie angewendet werden können, um saubereren, strukturierteren Code zu schreiben. Wenn Sie tiefer in praktische Codebeispiele eintauchen oder erfahren möchten, wie diese Prinzipien in einem echten Projekt umgesetzt werden, schauen Sie sich gerne mein GitHub-Repository an, um weitere Einzelheiten zu erfahren.

Eine praktischere Erklärung finden Sie in meinem GitHub-Repository.

Was ist Objekt-Calisthenics?

Object Calisthenics ist eine Programmierübung, die aus neun Regeln besteht, die Sie dazu ermutigen, sich an objektorientierte Prinzipien zu halten. Die Regeln selbst wurden von Jeff Bay in seinem Buch The ThoughtWorks Anthology eingeführt. Das Ziel besteht darin, eine tiefere Konzentration auf das Design und die Struktur Ihres Codes zu fördern, indem Sie diese Einschränkungen befolgen.

Hier sind die 9 Regeln:

1. Nur eine Einrückungsebene pro Methode

Dieses Prinzip besagt, dass jede Methode nur eine Einrückungsebene haben sollte. Indem wir den Grad der Einrückung niedrig halten, können wir die Lesbarkeit verbessern und die Wartung des Codes vereinfachen. Wenn eine Methode zu viele Einrückungsebenen hat, ist das oft ein Zeichen dafür, dass die Logik darin zu komplex ist und in kleinere Teile zerlegt werden muss.

Beispiel für die Umsetzung
Hier ist ein Beispiel für eine Methode, die diesem Prinzip nicht folgt:

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.");
        }
    }
}

Im obigen Code gibt es mehrere Einrückungsebenen in der Methode „processOrder“, was die Lesbarkeit erschwert, insbesondere wenn die Logik komplexer wird.

Schauen wir uns nun an, wie wir dem Prinzip folgen können, indem wir die Logik vereinfachen:

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();
    }
}

Diese Version verfügt über eine Einrückungsebene pro Logikblock, wodurch der Code sauberer und einfacher zu warten ist.

2. Verwenden Sie nicht das Schlüsselwort else

Bei der objektorientierten Programmierung führt die Verwendung des Schlüsselworts else oft zu unübersichtlichem und schwer zu wartendem Code. Anstatt sich auf else-Anweisungen zu verlassen, können Sie Ihren Code mithilfe früher Rückgaben oder Polymorphismus strukturieren. Dieser Ansatz verbessert die Lesbarkeit, reduziert die Komplexität und macht Ihren Code wartbarer.

Sehen wir uns zunächst ein Beispiel an, das das Schlüsselwort else verwendet:

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.");
        }
    }
}

In diesem Beispiel zwingt uns die else-Anweisung dazu, den negativen Fall explizit zu behandeln, was die Komplexität erhöht. Lassen Sie uns dies nun umgestalten, um die Verwendung von else:
zu vermeiden

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.");
    }
}

Durch die Eliminierung anderer Elemente schreiben Sie fokussierteren Code, wobei jeder Abschnitt eine einzelne Verantwortung übernimmt. Dies steht im Einklang mit dem „Single-Responsibility-Prinzip“ und trägt dazu bei, sauberere, wartbarere Software zu erstellen.

3. Wickeln Sie alle Grundelemente und Zeichenfolgen ein

Eine der Schlüsselpraktiken bei Object Calisthenics besteht darin, alle Grundelemente und Zeichenfolgen in benutzerdefinierte Klassen zu verpacken. Diese Regel ermutigt Entwickler, die direkte Verwendung roher primitiver Typen oder Zeichenfolgen in ihrem Code zu vermeiden. Stattdessen sollten sie sie in bedeutungsvolle Objekte einkapseln. Dieser Ansatz führt zu Code, der aussagekräftiger und leichter verständlich ist und an Komplexität zunehmen kann, ohne unüberschaubar zu werden.

Betrachten wir ein Beispiel, in dem wir primitive Typen und Zeichenfolgen direkt verwenden:

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;
    }
}

In diesem Code werden int, double und String direkt verwendet. Auch wenn dies einfach erscheinen mag, bringt es die Absicht jedes einzelnen Werts nicht klar zum Ausdruck und macht es schwieriger, später neue Verhaltensweisen oder Einschränkungen speziell für diese Werte einzuführen.

Lassen Sie uns nun diesen Code umgestalten, um die Grundelemente und Zeichenfolgen einzuschließen:

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();
    }
}

Wichtige Änderungen:

• Aussagekräftige Klassen: Anstatt die Klassen „raw int“, „double“ und „String“ zu verwenden, haben wir die Klassen „Quantity“, „Price“ und „ProductName“ erstellt. Dies verleiht jedem dieser Werte eine Bedeutung und ermöglicht eine benutzerdefinierte Validierung oder zusätzliches Verhalten.
• Erweiterte Validierung: Wir haben eine Validierung hinzugefügt, um sicherzustellen, dass Menge und Preis immer gültige Werte haben, z. B. nicht negative Beträge. Dies ist viel einfacher zu handhaben, wenn Grundelemente in ihre eigenen Klassen eingeschlossen sind.
• Verbesserte Lesbarkeit, der Code ist selbsterklärender. Sie müssen nicht mehr raten, was ein bestimmter Grundwert darstellt. Jeder Wert ist in einer Klasse gekapselt, die seine Bedeutung klar vermittelt.

4. Erstklassige Sammlungen

Wenn Sie eine Sammlung wie eine Liste oder Karte verwenden, machen Sie sie zu einem dedizierten Objekt. Dies hält Ihren Code sauber und stellt sicher, dass die mit der Sammlung verbundene Logik gekapselt ist.

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 to manage its items. This design can lead to code that lacks clear meaning and responsibilities. It also allows external classes to manipulate the list freely, leading to potential misuse.

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:

• First-Class Collection, The Items class is a wrapper around the List. This pattern gives the collection its own class and behavior, making it easier to manage and encapsulate rules. For example, you can easily add validation or methods that operate on the list (e.g., size()).
• This makes the code more meaningful and prevents misuse of raw collections, as external classes don't have direct access to the list.

Benefits of First-Class Collections:

• Encapsulation: Collection logic is kept in one place.
• Maintainability: Any changes to how the collection is handled can be done in the Items class.
• Readability: Code that deals with collections is clearer and more meaningful.

6. One Dot Per Line

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:

• Read: The longer the chain of method calls, the harder it is to understand what the code does.
• Debug: If something breaks, it’s not clear which part of the chain failed.
• Maintain: Changing a specific operation in a long chain can affect other parts of the code, leading to harder refactoring.

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.

6. Don’t Abbreviate

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
    }
}

• EmpMgr is unclear; is it Employee Manager or something else?
• calcSal is not obvious at a glance—what kind of salary calculation does it perform?
• emp and sal are vague and can confuse developers reading the code later.

Example of Good Practice (Without Abbreviations):

public class EmployeeManager {
    public void calculateSalary(Employee employee) {
        double salary = employee.getSalary();
        // Salary calculation logic
    }
}

• EmployeeManager makes it clear that this class is managing employees.
• calculateSalary is explicit, showing the method’s purpose.
• employee and salary are self-explanatory and much more readable.

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.

7. Keep Entities Small

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:

• Keep the Employee class focused on core employee information.
• Extract responsibilities like payslip generation and tax calculation into their own classes (PaySlipGenerator and TaxCalculator).

8. No Getters/Setters/Properties

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.

9. Separate UI from Business Logic

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.

Conclusion

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!

Das obige ist der detaillierte Inhalt vonObjekt-Calisthenics verstehen: Saubereren Code schreiben. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!