Prinsip Paling Tidak Kehairanan (POLA)

Konsep Utama

1. Penamaan Kaedah Konsisten

// Bad - Inconsistent naming
class UserManager {
    public function getUser($id) { /* ... */ }
    public function fetchRole($id) { /* ... */ }
    public function retrievePermissions($id) { /* ... */ }
}

// Good - Consistent naming pattern
class UserManager {
    public function getUser($id) { /* ... */ }
    public function getRole($id) { /* ... */ }
    public function getPermissions($id) { /* ... */ }
}

Apabila menamakan kaedah, konsistensi adalah penting. Dalam contoh buruk, kami menggunakan tiga kata kerja yang berbeza (dapatkan, ambil, ambil semula) untuk operasi yang serupa. Ini memaksa pembangun mengingati istilah yang berbeza untuk jenis tindakan yang sama. Contoh yang baik menggunakan 'dapat' secara konsisten merentas semua kaedah, menjadikan API lebih mudah diramal dan lebih mudah diingati. Apabila pembangun perlu mengakses data, mereka secara intuitif akan tahu untuk mencari kaedah yang bermula dengan 'mendapatkan'.

2. Jenis Pulangan yang Dijangka

// Bad - Unexpected return types
class FileHandler {
    public function readFile($path) {
        if (!file_exists($path)) {
            return false; // Unexpected boolean
        }
        return file_get_contents($path);
    }
}

// Good - Consistent return types with exceptions
class FileHandler {
    public function readFile($path): string {
        if (!file_exists($path)) {
            throw new FileNotFoundException("File not found: {$path}");
        }
        return file_get_contents($path);
    }
}

Contoh buruk mencampurkan jenis pulangan - kadangkala mengembalikan rentetan (kandungan fail) dan kadangkala boolean (palsu). Ini mewujudkan ketidakpastian tentang cara mengendalikan nilai pulangan. Contoh yang baik memastikan keselamatan jenis dengan mengisytiharkan jenis pemulangan rentetan dan menggunakan pengecualian untuk kes ralat. Ini sepadan dengan gelagat terbina dalam PHP dan menjadikan pengendalian ralat lebih jelas dan boleh diramal.

3. Susunan Parameter Boleh Diramal

// Bad - Inconsistent parameter order
class OrderProcessor {
    public function createOrder($items, $userId, $date) { /* ... */ }
    public function updateOrder($date, $orderId, $items) { /* ... */ }
}

// Good - Consistent parameter order
class OrderProcessor {
    public function createOrder($userId, $items, $date) { /* ... */ }
    public function updateOrder($orderId, $items, $date) { /* ... */ }
}

Tertib parameter hendaklah konsisten merentas kaedah yang serupa. Contoh buruk meletakkan parameter yang sama dalam kedudukan yang berbeza, menjadikan API mengelirukan. Contoh yang baik mengekalkan susunan logik: pengecam dahulu (userId/orderId), diikuti dengan data utama (item) dan parameter pilihan/metadata terakhir (tarikh). Corak ini sepadan dengan konvensyen biasa dalam rangka kerja PHP dan menjadikan API lebih intuitif.

4. Gelagat Kaedah yang Jelas

// Bad - Ambiguous behavior
class Cart {
    public function add($product) {
        // Sometimes creates new item, sometimes updates quantity
        // Unpredictable!
    }
}

// Good - Clear, single responsibility
class Cart {
    public function addNewItem($product) { /* ... */ }
    public function updateQuantity($productId, $quantity) { /* ... */ }
}

Kaedah harus mempunyai tanggungjawab tunggal yang jelas. Kaedah 'tambah' contoh buruk adalah samar-samar - ia mungkin menambah item baharu atau mengemas kini yang sedia ada. Contoh yang baik membahagikan ini kepada dua kaedah berbeza dengan nama dan tujuan yang jelas. Ini menjadikan tingkah laku kod boleh diramal dan mengikut Prinsip Tanggungjawab Tunggal (SRP).

5. Pengendalian Ralat yang Konsisten

class PaymentProcessor {
    public function processPayment(float $amount): PaymentResult {
        try {
            // Process payment
            return new PaymentResult(true, 'Payment successful');
        } catch (PaymentException $e) {
            // Always handle errors the same way
            throw new PaymentFailedException($e->getMessage());
        }
    }
}

Contoh ini menunjukkan pengendalian ralat yang konsisten melalui pengecualian. Daripada mengembalikan jenis yang berbeza atau menggunakan kod ralat, ia sentiasa membuang jenis pengecualian tertentu (PaymentFailedException) apabila berlaku masalah. Ini mencipta corak yang boleh diramal untuk pengendalian ralat merentas aplikasi. Kaedah ini juga menggunakan objek PaymentResult khusus untuk kes yang berjaya, mengekalkan ketekalan jenis.

Setiap amalan ini menyumbang kepada kod yang lebih boleh diselenggara, lebih mudah difahami dan kurang terdedah kepada pepijat kerana ia berkelakuan mengikut cara yang diharapkan oleh pembangun berdasarkan corak dan konvensyen biasa dalam pembangunan PHP.

Atas ialah kandungan terperinci Prinsip Paling Tidak Kehairanan (POLA). Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!