// 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) { /* ... */ } }
방법 이름을 지정할 때는 일관성이 중요합니다. 나쁜 예에서는 유사한 작업에 세 가지 다른 동사(get, fetch,retrieve)를 사용합니다. 이로 인해 개발자는 동일한 유형의 작업에 대해 다른 용어를 기억해야 합니다. 좋은 예는 모든 메서드에서 일관되게 'get'을 사용하여 API를 더 예측 가능하고 기억하기 쉽게 만듭니다. 개발자는 데이터에 접근해야 할 때 'get'으로 시작하는 메소드를 찾아야 한다는 것을 직관적으로 알게 될 것입니다.
// 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); } }
나쁜 예에서는 반환 유형이 혼합되어 있습니다. 때로는 문자열(파일 내용)을 반환하고 때로는 부울(false)을 반환합니다. 이로 인해 반환 값을 처리하는 방법에 대한 불확실성이 발생합니다. 좋은 예는 문자열 반환 유형을 선언하고 오류 사례에 대한 예외를 사용하여 유형 안전성을 보장합니다. 이는 PHP의 내장 동작과 일치하며 오류 처리를 더욱 명확하고 예측 가능하게 만듭니다.
// 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) { /* ... */ } }
매개변수 순서는 유사한 방법 전체에서 일관되어야 합니다. 나쁜 예는 유사한 매개변수를 다른 위치에 배치하여 API를 혼란스럽게 만듭니다. 좋은 예에서는 식별자가 먼저(userId/orderId), 기본 데이터(항목), 선택적/메타데이터 매개변수가 마지막(날짜)으로 이어지는 논리적 순서를 유지합니다. 이 패턴은 PHP 프레임워크의 일반적인 규칙과 일치하며 API를 더욱 직관적으로 만듭니다.
// 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) { /* ... */ } }
메서드에는 명확하고 단일한 책임이 있어야 합니다. 나쁜 예의 '추가' 방법은 모호합니다. 새 항목을 추가하거나 기존 항목을 업데이트할 수 있습니다. 좋은 예에서는 이를 명확한 이름과 목적을 가진 두 가지 별개의 메서드로 나눕니다. 이는 코드의 동작을 예측 가능하게 하며 단일 책임 원칙(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()); } } }
이 예에서는 예외를 통한 일관된 오류 처리를 보여줍니다. 다른 유형을 반환하거나 오류 코드를 사용하는 대신 문제가 발생하면 항상 특정 예외 유형(PaymentFailedException)을 발생시킵니다. 이는 애플리케이션 전반에 걸쳐 오류 처리에 대한 예측 가능한 패턴을 만듭니다. 또한 이 메소드는 성공적인 사례에 대해 전용 PaymentResult 객체를 사용하여 유형 일관성을 유지합니다.
이러한 각 사례는 PHP 개발의 일반적인 패턴과 규칙을 기반으로 개발자가 기대하는 방식으로 작동하기 때문에 유지 관리가 더 쉽고, 이해하기 쉽고, 버그 발생 가능성이 낮은 코드를 만드는 데 기여합니다.
위 내용은 최소한의 놀라움의 원리(POLA)의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!