// 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) { /* ... */ } }
Bei der Benennung von Methoden ist Konsistenz entscheidend. Im schlechten Beispiel verwenden wir drei verschiedene Verben (Get, Fetch, Retrieval) für ähnliche Operationen. Dies zwingt Entwickler dazu, sich unterschiedliche Begriffe für dieselbe Art von Aktion zu merken. Das gute Beispiel verwendet „get“ konsistent über alle Methoden hinweg, wodurch die API vorhersehbarer und leichter zu merken ist. Wenn Entwickler auf Daten zugreifen müssen, wissen sie intuitiv, dass sie nach einer Methode suchen müssen, die mit „get“ beginnt.
// 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); } }
Das schlechte Beispiel vermischt Rückgabetypen – manchmal wird eine Zeichenfolge (Dateiinhalt) und manchmal ein boolescher Wert (falsch) zurückgegeben. Dies führt zu Unsicherheit darüber, wie mit dem Rückgabewert umgegangen werden soll. Das gute Beispiel stellt die Typsicherheit sicher, indem es einen String-Rückgabetyp deklariert und Ausnahmen für Fehlerfälle verwendet. Dies entspricht dem integrierten Verhalten von PHP und macht die Fehlerbehandlung expliziter und vorhersehbarer.
// 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) { /* ... */ } }
Die Parameterreihenfolge sollte bei ähnlichen Methoden konsistent sein. Das schlechte Beispiel platziert ähnliche Parameter an unterschiedlichen Positionen, was die API verwirrend macht. Das gute Beispiel behält eine logische Reihenfolge bei: Bezeichner zuerst (Benutzer-ID/Bestell-ID), gefolgt von Hauptdaten (Elemente) und optionalen/Metadaten-Parametern zuletzt (Datum). Dieses Muster entspricht gängigen Konventionen in PHP-Frameworks und macht die API intuitiver.
// 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) { /* ... */ } }
Methoden sollten klare, einheitliche Verantwortlichkeiten haben. Die „add“-Methode des schlechten Beispiels ist mehrdeutig – sie könnte ein neues Element hinzufügen oder ein vorhandenes aktualisieren. Das gute Beispiel unterteilt dies in zwei unterschiedliche Methoden mit klaren Namen und Zwecken. Dies macht das Verhalten des Codes vorhersehbar und folgt dem Single-Responsibility-Prinzip (SRP).
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()); } } }
Dieses Beispiel demonstriert die konsistente Fehlerbehandlung durch Ausnahmen. Anstatt unterschiedliche Typen zurückzugeben oder Fehlercodes zu verwenden, wird immer ein bestimmter Ausnahmetyp (PaymentFailedException) ausgelöst, wenn etwas schief geht. Dadurch entsteht ein vorhersehbares Muster für die Fehlerbehandlung in der gesamten Anwendung. Die Methode verwendet für erfolgreiche Fälle außerdem ein dediziertes PaymentResult-Objekt, wobei die Typkonsistenz gewahrt bleibt.
Jede dieser Vorgehensweisen trägt dazu bei, dass der Code besser wartbar, leichter zu verstehen und weniger anfällig für Fehler ist, da er sich auf eine Weise verhält, die Entwickler aufgrund allgemeiner Muster und Konventionen in der PHP-Entwicklung erwarten.
Das obige ist der detaillierte Inhalt vonDas Prinzip des geringsten Erstaunens (POLA). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!