Ưu điểm cho nhiều phương thức chuyển đổi

Tôi đã nhận được một đánh giá mã từ một nhà phát triển cao cấp ngày hôm nay hỏi "Nhân tiện, sự phản đối của bạn đối với việc gửi các chức năng bằng cách tuyên bố chuyển đổi là gì?" Tôi đã đọc ở nhiều nơi về cách bơm một đối số thông qua chuyển sang các phương thức gọi là OOP xấu, không thể mở rộng, v.v. Tuy nhiên, tôi thực sự không thể đưa ra một câu trả lời dứt khoát cho anh ta. Tôi muốn giải quyết điều này cho bản thân mình một lần và mãi mãi.

Dưới đây là các đề xuất mã cạnh tranh của chúng tôi (php được sử dụng làm ví dụ, nhưng có thể áp dụng phổ biến hơn):

class Switch {
   public function go($arg) {
      switch ($arg) {
         case "one":
            echo "one\n";
         break;
         case "two":
            echo "two\n";
         break;
         case "three":
            echo "three\n";
         break;
         default:
            throw new Exception("Unknown call: $arg");
         break;
      }
   }
}

class Oop {
   public function go_one() {
      echo "one\n";
   }
   public function go_two() {
      echo "two\n";
   }
   public function go_three() {
      echo "three\n";
   }
   public function __call($_, $__) {
      throw new Exception("Unknown call $_ with arguments: " . print_r($__, true));
   }
}

Một phần trong lập luận của ông là "Nó (phương thức chuyển đổi) có cách xử lý các trường hợp mặc định gọn gàng hơn nhiều so với những gì bạn có trong phương thức ma thuật __call () chung chung."

Tôi không đồng ý về sự sạch sẽ và thực tế thích gọi điện, nhưng tôi muốn nghe những gì người khác nói.

Đối số tôi có thể đưa ra để hỗ trợ Oopchương trình:

• Sạch hơn một chút về mã bạn phải viết (ít hơn, dễ đọc hơn, ít từ khóa hơn để xem xét)
• Không phải tất cả các hành động được ủy thác cho một phương thức duy nhất. Không có nhiều sự khác biệt trong thực thi ở đây, nhưng ít nhất văn bản có nhiều ngăn hơn.
• Trong cùng một hướng, một phương thức khác có thể được thêm vào bất cứ nơi nào trong lớp thay vì một vị trí cụ thể.
• Các phương thức được đặt tên, đó là tốt đẹp.
• Không áp dụng ở đây, nhưng xem xét một trường hợp Switch::go()hoạt động trên một thành viên chứ không phải là một tham số. Bạn sẽ phải thay đổi thành viên trước, sau đó gọi phương thức. Đối với Oopbạn có thể gọi các phương thức độc lập bất cứ lúc nào.

Đối số tôi có thể đưa ra để hỗ trợ Switchchương trình:

• Để tranh luận, phương pháp sạch hơn để xử lý một yêu cầu mặc định (không xác định)
• Có vẻ ít ma thuật hơn, điều này có thể khiến các nhà phát triển xa lạ cảm thấy thoải mái hơn

Bất cứ ai có bất cứ điều gì để thêm cho cả hai bên? Tôi muốn có một câu trả lời tốt cho anh ấy.

Một chuyển đổi được coi là không OOP vì thường đa hình có thể thực hiện thủ thuật.

Trong trường hợp của bạn, việc triển khai OOP có thể là:

class Oop 
{
  protected $goer;

  public function __construct($goer)
  {
    $this->goer = $goer;
  }

  public function go()
  {
    return $this->goer->go();
  }
}

class Goer
{
  public function go()
  {
    //...
  }
}

class GoerA extends Goer
{
  public function go()
  {
    //...
  }
}

class GoerB extends Goer
{
  public function go()
  {
    //...
  }
}

class GoerC extends Goer
{
  public function go()
  {
    //...
  }
}


$oop = new Oop(new GoerB());
$oop->go();

cho ví dụ này:

class Switch
{
    public function go($arg)
    {
        echo "$arg\n";
    }
}

OK, chỉ đùa một phần ở đây. Đối số / không sử dụng câu lệnh chuyển đổi có thể được đưa ra mạnh mẽ với một ví dụ tầm thường như vậy, bởi vì phía OOP phụ thuộc vào ngữ nghĩa liên quan, không chỉ đơn thuần là cơ chế điều phối .

Các câu lệnh chuyển đổi thường là một dấu hiệu của các lớp hoặc phân loại bị thiếu, nhưng không nhất thiết phải như vậy. Đôi khi một câu lệnh switch chỉ là một câu lệnh switch .

Có lẽ không phải là một câu trả lời, nhưng trong trường hợp mã không chuyển đổi, có vẻ như đây sẽ là một kết hợp tốt hơn:

class Oop {
  /**
   * User calls $oop->go('one') then this function will determine if the class has a 
   * method 'go_one' and call that. If it doesn't, then you get your error.
   * 
   * Subclasses of Oop can either overwrite the existing methods or add new ones.
   */
  public function go($arg){

    if(is_callable(array($this, 'go_'. $arg))){
      return call_user_func(array($this, 'go_'. $arg));
    }

    throw new Exception("Unknown call: $arg");
  }

  public function go_one() {
    echo "one\n";
  }
  public function go_two() {
    echo "two\n";
  }
  public function go_three() {
    echo "three\n";
  }
}

Một phần lớn của câu đố để đánh giá là những gì xảy ra khi bạn cần tạo NewSwitchhoặc NewOop. Các lập trình viên của bạn có phải nhảy qua vòng bằng phương pháp này hay phương pháp khác không? Điều gì xảy ra khi quy tắc của bạn thay đổi, v.v.

Thay vì chỉ đưa mã thực thi của bạn vào các hàm, hãy thực hiện một mẫu lệnh đầy đủ và đặt từng mã trong lớp riêng của chúng thực hiện một giao diện chung. Phương pháp này cho phép bạn sử dụng IOC / DI để kết nối các "trường hợp" khác nhau của lớp và cho phép bạn dễ dàng thêm và xóa các trường hợp khỏi mã của mình theo thời gian. Nó cũng cung cấp cho bạn một chút mã tốt mà không vi phạm các nguyên tắc lập trình RẮN.

Tôi nghĩ rằng ví dụ là xấu. Nếu có một hàm go () chấp nhận đối số $ ở đâu, nếu hoàn toàn hợp lệ để sử dụng chuyển đổi trong hàm. Có chức năng go () duy nhất giúp dễ dàng sửa đổi hành vi của tất cả go_where () phối cảnh. Ngoài ra, bạn sẽ duy trì giao diện lớp - nếu bạn sử dụng nhiều phương thức khác nhau, bạn đang sửa đổi giao diện của lớp với mỗi đích mới.

Trên thực tế, chuyển đổi không nên được thay thế bằng tập hợp các phương thức, nhưng với tập hợp các lớp - đây là đa hình. Sau đó, đích sẽ được xử lý bởi mỗi lớp con và sẽ có phương thức go () cho tất cả chúng. Thay thế điều kiện bằng đa hình là một trong những phép tái cấu trúc cơ bản, được mô tả bởi Martin Fowler. Nhưng bạn có thể không cần đa hình, và chuyển đổi là cách để đi.