Đừng sử dụng Tĩnh Tĩnh trong C #?

Tôi đã gửi một ứng dụng tôi đã viết cho một số kiến ​​trúc sư khác để xem xét mã. Một trong số họ gần như ngay lập tức viết lại cho tôi và nói "Đừng sử dụng" tĩnh ". Bạn không thể viết các bài kiểm tra tự động với các lớp và phương thức tĩnh." Tĩnh "là phải tránh."

Tôi đã kiểm tra và đầy đủ 1/4 các lớp học của tôi được đánh dấu "tĩnh". Tôi sử dụng tĩnh khi tôi sẽ không tạo một thể hiện của một lớp vì lớp này là một lớp toàn cầu duy nhất được sử dụng trong toàn bộ mã.

Ông tiếp tục đề cập đến một cái gì đó liên quan đến chế nhạo, các kỹ thuật IOC / DI không thể được sử dụng với mã tĩnh. Ông nói rằng thật không may khi các thư viện bên thứ 3 tĩnh vì không thể kiểm tra được.

Đây có phải là kiến ​​trúc sư khác đúng không?

cập nhật: đây là một ví dụ:

APIManager - lớp này lưu giữ từ điển API của bên thứ 3 mà tôi đang gọi cùng với thời gian được phép tiếp theo. Nó thực thi các giới hạn sử dụng API mà rất nhiều bên thứ 3 có trong điều khoản dịch vụ của họ. Tôi sử dụng nó ở bất cứ đâu tôi đang gọi dịch vụ của bên thứ 3 bằng cách gọi Thread.S ngủ (APIManager.GetWait ("CarrierXYZ")); trước khi thực hiện cuộc gọi. Mọi thứ ở đây đều an toàn và nó hoạt động rất tốt với TPL trong C #.

Nó phụ thuộc vào việc các lớp tĩnh có duy trì trạng thái hay không. Cá nhân, tôi không có vấn đề gì với các hàm không trạng thái được ném vào nhau trong một lớp tĩnh.

Anh ấy quá chung chung về nó. Ông là chính xác, nó cản trở thử nghiệm. Tuy nhiên, staticcác lớp và phương thức có vị trí của chúng và nó thực sự phụ thuộc vào ngữ cảnh. Không có ví dụ mã bạn không thể thực sự nói.

Tôi sử dụng tĩnh khi tôi sẽ không tạo một thể hiện của một lớp vì lớp này là một lớp toàn cầu duy nhất được sử dụng trong toàn bộ mã.

Đây có thể là mùi mã nghiêm trọng. Bạn đang sử dụng các lớp học để làm gì? Để giữ dữ liệu? Để truy cập cơ sở dữ liệu? Rồi anh đúng. Bạn nên xem xét việc tiêm phụ thuộc trong trường hợp đó, vì một lớp tĩnh như vậy thực sự là một singleton ẩn.

Nếu bạn đang sử dụng chúng cho các phương thức mở rộng hoặc người trợ giúp không thay đổi trạng thái và chỉ hoạt động dựa trên các tham số bạn cung cấp, thì chúng thường ổn.

Tôi đã kiểm tra và đầy đủ 1/4 các lớp học của tôi được đánh dấu "tĩnh". Tôi sử dụng tĩnh khi tôi sẽ không tạo một thể hiện của một lớp vì lớp này là một lớp toàn cầu duy nhất được sử dụng trong toàn bộ mã.

Điều tốt nhất để làm là thử và kiểm tra đơn vị mã của bạn. Hãy thử thiết kế các bài kiểm tra có thể lặp lại, độc lập, đơn giản và chỉ kiểm tra một phương pháp tại một thời điểm. Hãy thử chạy thử nghiệm của bạn theo thứ tự ngẫu nhiên khác nhau. Bạn có thể có được bản dựng "xanh" ổn định không?

Nếu có, đó là một điểm hợp lệ để bảo vệ mã của bạn. Tuy nhiên, nếu bạn gặp khó khăn, thì có lẽ bạn nên dùng các phương pháp dựa trên ví dụ.

Các câu trả lời đã được đăng bao gồm rất nhiều điểm thực sự tốt, nhưng có một điểm dường như còn thiếu:

Các trường tĩnh không bao giờ được thu gom rác.

Điều này thực sự quan trọng nếu bạn có một ứng dụng có nhiều hạn chế về bộ nhớ và mẫu này có thể rất phổ biến khi mọi người cố gắng thực hiện bộ đệm.

Các hàm tĩnh gần như không tệ, nhưng mọi người khác đã trình bày chi tiết này đủ chi tiết.

Một trong những lợi thế mà bạn nhận được từ IoC / DI là hầu hết các tương tác giữa các lớp được đàm phán giữa các giao diện. Điều này làm cho việc kiểm tra đơn vị dễ dàng vì các giao diện có thể được mô phỏng tự động hoặc bán tự động, và do đó mỗi bộ phận có thể được kiểm tra cho đầu vào và đầu ra. Hơn nữa, ngoài khả năng kiểm tra, việc đặt giao diện giữa mọi thứ cho phép bạn có mã mô-đun nhất có thể - bạn có thể dễ dàng thay thế một triển khai mà không quá lo lắng rằng bạn đang làm hỏng phụ thuộc.

Vì C # không có siêu dữ liệu, nên một lớp không thể thực hiện giao diện bằng các tính năng tĩnh, do đó, các tính năng tĩnh của các lớp kết thúc mọi nỗ lực để thực hiện mô hình đối tượng IoC / DI thuần túy. Điều đó có nghĩa là, bạn không thể tạo ra một bản giả để kiểm tra chúng và bạn phải tạo ra sự phụ thuộc thực sự.

Nếu công ty / dự án của bạn được đầu tư rất nhiều vào việc thực hiện IoC, thì điều này tất nhiên là một mối quan tâm hợp lý và nỗi đau bạn trải qua là vì lợi ích của tất cả. Tuy nhiên, từ quan điểm kiến ​​trúc, cá nhân tôi không nghĩ rằng bất kỳ mô hình nào nên được theo dõi đến ngôi mộ. Có một số điều hợp lý khi thực hiện bằng các phương thức tĩnh - ví dụ như chiến lược thiết kế singleton. Bản thân tôi ít nghiêng về các lớp tĩnh hơn vì tôi nghĩ rằng chúng có xu hướng bắt đầu mất đi những lợi thế của OO, nhưng có những lúc, một lớp thư viện có lẽ là biểu hiện tự nhiên của một thứ gì đó hơn là một động cơ.

Bình luận viên nhắc nhở tôi về các phương thức mở rộng, tất nhiên phải có trong các lớp tĩnh trong C #. Điều đó hợp pháp và là một ví dụ về cách IoC thuần túy không hoạt động tốt trong C #, ít nhất là nếu bạn đang cố gắng tận dụng lợi thế của ngôn ngữ.

Các lớp tĩnh đôi khi bị sử dụng sai và nên:

• một singleton (trong đó lớp không tĩnh có thành viên tĩnh và biến Instance tĩnh công khai để truy xuất / tạo nó chỉ một lần.
• một phương thức trong một lớp khác (trong đó nhà nước quan trọng). Nếu bạn có một thành viên đang sử dụng không có dữ liệu từ lớp đó, có lẽ nó không phải là một phần của lớp đó.

Nó cũng có thể là một chức năng được gọi là 'tiện ích' và là một phần của lớp tiện ích. Các lớp tiện ích là các lớp chỉ chứa các phương thức tĩnh và đóng vai trò là các hàm trợ giúp mà không có bất kỳ ngữ cảnh nào.

Các phương thức tĩnh là tốt để sử dụng và có một vị trí hợp lý trong lập trình. Có vẻ như kiến ​​trúc sư của bạn có một khung kiểm tra không hỗ trợ đầy đủ các phương thức tĩnh. Nếu mã của bạn là một phần của dự án lớn hơn, thì điều quan trọng là phải đáp ứng các hướng dẫn của kiến ​​trúc sư. Tuy nhiên, đừng để dự án này ngăn cản bạn sử dụng các phương thức tĩnh khi thích hợp để làm như vậy.

Tôi đã sử dụng các thuộc tính tĩnh cho những thứ phổ biến cho tất cả các thể hiện của một lớp. Và tôi đã sử dụng các phương thức tĩnh để có được các nhóm đối tượng lớp. Tôi không có nghĩa là một chuyên gia nhưng điều này đã làm việc cho tôi cho đến nay.

Ví dụ về PHP:

class vendorData {
  private static $data_table = 'vendor_data'; // static property
  private $id; // instance property
  private $name; // instance property

  public function __construct($vendor_id) {
    if(!self::validId($vendor_id) ) { // static method
      return false; // id doesn't exist
    }
    $this->id = $vendor_id; // id has been validated
    $this->getProperties(); // object method
  }

  private static function validId($vendor_id) {
    // send db query to find if the id exists
    // return true/false;
  }

  private function getProperties() { // object method
    $sql = "SELECT * FROM `{self::$data_table}` // using static property
        WHERE `id` = {$this->id}"; // using object instance property
    // get resultset
    foreach($result as $property => $value) {
      $this->$property = $value; // object instance properties all set
    }
  }

  // and here
  public static function getBy($property,$value) { // static method to return object array
    $sql = "SELECT `id` FROM `{self::$data_table}` // using static property
      WHERE `$property` = '$value'";
    // send query, get $ids array
    $obj_array = array();
    foreach($ids as $id) {
      // create array of current class objects using special static keyword
      // meaning of static here is different than in property/method declarations
      $obj_array[$id] = new static($id);
    }
    return $obj_array;
  }
}

Tôi sẽ nói các nguyên tắc họ có đều ổn nhưng tuyên bố (không sử dụng số liệu thống kê) có thể sai. Bảo hiểm mã của bạn là bao nhiêu? nếu số lượng cao và bạn cảm thấy thoải mái với thử nghiệm đơn vị của ứng dụng của mình, thì bạn vẫn ổn. Nếu không, sau đó tôi sẽ đề nghị xem lại mã. Bạn có thể tìm thấy các lớp tĩnh là lý do hay không, nó sẽ phụ thuộc vào rất nhiều thứ.

Các lớp với các phương thức tĩnh lạm dụng các nguyên tắc của OOP. Nó chưa phải là OOP, đó là COP - lập trình hướng lớp.

Họ hiếm khi có "tính cách" rõ ràng (tôi sử dụng phép ẩn dụ con người yêu thích của tôi ở đây), hoặc danh tính. Vì vậy, họ không biết họ là ai. Chỉ riêng điểm này là đủ để loại bỏ khái niệm này trong OOP, nhưng có nhiều hơn trong số họ.

Điều tiếp theo là hậu quả của điểm đầu tiên. Vì những lớp như vậy không biết họ là ai, nên họ có xu hướng từ lớn đến lớn.

Thứ ba làm cho mã của bạn hoàn toàn không thể bảo trì. Việc sử dụng các phương pháp tĩnh giới thiệu các phụ thuộc ẩn . Chúng bật lên khắp nơi và bạn không bao giờ biết chuyện gì đang xảy ra trong lớp của mình. Bạn không thể chắc chắn điều đó chỉ bằng cách nhìn vào chữ ký của nhà xây dựng.

Dần dần, nhưng chắc chắn, mã của bạn ngày càng ít gắn kết hơn, vì các phụ thuộc ẩn được kiểm soát kém. Họ dường như vô hình. Và thật dễ dàng để thêm một cái khác! Bạn không phải sửa đổi chữ ký của phương thức nào. Tất cả bạn phải làm là gọi một phương thức tĩnh. Và những gì một mã xấu xí theo sau ...

Ok, có lẽ bạn đã đoán ra. Khớp nối chặt chẽ là một tiếp viên của sự gắn kết thấp. Nếu có nhiều khách hàng sử dụng một số lớp, thì khớp nối ngày càng chặt chẽ hơn. Và có một sự quyến rũ lớn trong việc sử dụng một lớp hoặc phương thức đã được viết mà chỉ cần sửa chữa nhỏ. Chỉ có một tham số cờ phương thức.

Sử dụng gì thay vì phương thức tĩnh? Vâng, đề nghị của tôi là OOP. Tại sao không thử?