Các lớp tiện ích không có gì ngoài các thành viên tĩnh là một mô hình chống trong C ++?

Câu hỏi Tôi nên đặt các hàm không liên quan đến một lớp ở đâu đã gây ra một số tranh luận về việc liệu C ++ có hợp lý để kết hợp các hàm tiện ích trong một lớp hay chỉ tồn tại chúng dưới dạng các hàm miễn phí trong một không gian tên.

Tôi đến từ nền C # trong đó tùy chọn thứ hai không tồn tại và do đó, xu hướng sử dụng các lớp tĩnh trong mã C ++ nhỏ mà tôi viết. Tuy nhiên, câu trả lời được bình chọn cao nhất cho câu hỏi đó cũng như một số ý kiến ​​nói rằng các hàm miễn phí sẽ được ưu tiên hơn, thậm chí đề xuất các lớp tĩnh là một mô hình chống. Tại sao lại như vậy trong C ++? Ít nhất là trên bề mặt, các phương thức tĩnh trên một lớp dường như không thể phân biệt được với các hàm tự do trong một không gian tên. Tại sao lại ưu tiên cho cái sau?

Mọi thứ sẽ khác đi, nếu bộ sưu tập các chức năng tiện ích cần một số dữ liệu chia sẻ, ví dụ như bộ đệm có thể lưu trữ trong trường tĩnh riêng?

Tôi đoán để trả lời rằng chúng ta nên so sánh ý định của cả hai lớp và không gian tên. Theo Wikipedia:

Lớp học

Trong lập trình hướng đối tượng, một lớp là một cấu trúc được sử dụng như một kế hoạch chi tiết để tạo ra các thể hiện của chính nó - được gọi là các thể hiện của lớp, các đối tượng lớp, các đối tượng thể hiện hoặc các đối tượng đơn giản. Một lớp định nghĩa các thành viên cấu thành cho phép các thể hiện của lớp này có trạng thái và hành vi. Các thành viên trường dữ liệu (biến thành viên hoặc biến thể hiện) cho phép một đối tượng lớp duy trì trạng thái. Các loại thành viên khác, đặc biệt là các phương thức, cho phép hành vi của một đối tượng lớp. Các thể hiện của lớp là loại của lớp liên quan.

Không gian tên

Nói chung, một không gian tên là một thùng chứa cung cấp ngữ cảnh cho các định danh (tên, hoặc thuật ngữ kỹ thuật hoặc từ) mà nó giữ và cho phép phân định các từ định danh từ đồng nghĩa nằm trong các không gian tên khác nhau.

Bây giờ, bạn đang cố gắng đạt được điều gì bằng cách đặt các hàm trong một lớp (tĩnh) hoặc một không gian tên? Tôi muốn đặt ra rằng định nghĩa của một không gian tên mô tả rõ hơn ý định của bạn - tất cả những gì bạn muốn là một thùng chứa cho các chức năng của bạn. Bạn không cần bất kỳ tính năng nào được mô tả trong định nghĩa lớp. Lưu ý rằng các từ đầu tiên của định nghĩa lớp là " Trong lập trình hướng đối tượng ", tuy nhiên không có gì hướng đối tượng về một tập hợp các hàm.

Có lẽ cũng có những lý do kỹ thuật nhưng như một người nào đó đến từ Java và cố gắng tìm hiểu về ngôn ngữ đa mô hình là C ++, câu trả lời rõ ràng nhất với tôi là: Bởi vì chúng ta không cần OO để đạt được điều này.

Tôi sẽ rất thận trọng khi gọi đó là một mô hình chống. Không gian tên thường được ưa thích, nhưng vì không có mẫu không gian tên và không gian tên không thể được chuyển qua làm tham số mẫu, nên sử dụng các lớp không có gì ngoài các thành viên tĩnh là khá phổ biến.

Ngày trước tôi cần học lớp FORTRAN. Lúc đó tôi đã biết các ngôn ngữ bắt buộc khác, vì vậy tôi nghĩ rằng tôi có thể học FORTRAN mà không cần học nhiều. Khi tôi làm bài tập về nhà đầu tiên, giáo sư đã trả lại cho tôi và yêu cầu làm lại: ông nói rằng các chương trình Pascal được viết theo cú pháp FORTRAN không được tính là bài nộp hợp lệ.

Vấn đề tương tự đang diễn ra ở đây: sử dụng các lớp tĩnh để lưu trữ các hàm tiện ích trong C ++ là một thành ngữ xa lạ với C ++.

Như bạn đã đề cập trong câu hỏi của mình, sử dụng các lớp tĩnh cho các hàm tiện ích trong C # là vấn đề cần thiết: các hàm đứng tự do đơn giản không phải là một tùy chọn trong C #. Ngôn ngữ cần thiết để phát triển một mẫu cho phép các lập trình viên xác định các hàm đứng tự do theo một cách khác - cụ thể là, trong các lớp tiện ích tĩnh. Đây là một mẹo Java được sử dụng từng từ: ví dụ: java.lang.Math và System.Math của .NET gần như là đẳng cấu.

C ++, tuy nhiên, cung cấp các không gian tên, một phương tiện khác để đạt được cùng một mục tiêu và nó tích cực sử dụng nó trong việc thực hiện thư viện chuẩn của nó. Thêm một lớp bổ sung của các lớp tĩnh không chỉ không cần thiết mà còn hơi phản cảm đối với người đọc không có nền tảng C # hoặc Java. Theo một nghĩa nào đó, bạn đang giới thiệu một "bản dịch cho vay" sang ngôn ngữ cho một cái gì đó có thể được diễn đạt nguyên bản.

Khi các chức năng của bạn cần chia sẻ dữ liệu, tình hình sẽ khác. Vì các chức năng của bạn không còn không liên quan , mẫu Singleton trở thành cách ưa thích để giải quyết yêu cầu này.

Có lẽ bạn cần hỏi tại sao bạn muốn có một lớp toàn tĩnh?

Lý do duy nhất tôi có thể nghĩ đến là các ngôn ngữ khác (Java và C #) rất nhiều 'mọi thứ đều là một lớp' yêu cầu chúng. Các ngôn ngữ này hoàn toàn không thể tạo ra các hàm cấp cao nhất, vì vậy chúng đã phát minh ra một mẹo để giữ chúng và đó là hàm thành viên tĩnh. Chúng là một cách giải quyết, nhưng C ++ không cần một thứ như vậy, bạn có thể trực tiếp tạo ra các chức năng độc lập, cấp cao hoàn toàn mới.

Nếu bạn cần các hàm hoạt động trên một mục dữ liệu cụ thể, thì sẽ hợp lý khi bó chúng vào một lớp chứa dữ liệu, nhưng sau đó, chúng dừng lại là các hàm và bắt đầu là thành viên của lớp đó hoạt động trên dữ liệu của lớp.

Nếu bạn có một chức năng không hoạt động trên một loại dữ liệu cụ thể (tôi sử dụng từ ở đây vì các lớp là cách để xác định các loại dữ liệu mới) thì đó thực sự là một mô hình chống đẩy chúng vào một lớp, không phải là ngoài mục đích ngữ nghĩa.

Ít nhất là trên bề mặt, các phương thức tĩnh trên một lớp dường như không thể phân biệt được với các hàm tự do trong một không gian tên.

Nói cách khác, có một lớp thay vì một không gian tên không có lợi thế.

Tại sao lại ưu tiên cho cái sau?

Đối với một điều, nó giúp bạn tiết kiệm statictất cả thời gian, mặc dù đó được cho là một lợi ích khá nhỏ.

Lợi ích chính là nó là công cụ ít mạnh nhất cho công việc. Các lớp có thể được sử dụng để tạo các đối tượng, chúng có thể được sử dụng làm kiểu biến hoặc làm đối số khuôn mẫu. Cả hai đều là những tính năng bạn muốn cho bộ sưu tập các chức năng của bạn. Vì vậy, tốt hơn là sử dụng một công cụ không có các tính năng đó, để lớp không thể vô tình bị sử dụng sai.

Theo đó, việc sử dụng một không gian tên sẽ giúp mọi người sử dụng mã của bạn rõ ràng rằng đây là một tập hợp các hàm chứ không phải là một kế hoạch chi tiết để tạo các đối tượng.

Tuy nhiên, một số ý kiến ​​nói rằng các hàm miễn phí sẽ được ưu tiên, thậm chí đề xuất các lớp tĩnh là một kiểu chống. Tại sao lại như vậy trong C ++? Ít nhất là trên bề mặt, các phương thức tĩnh trên một lớp dường như không thể phân biệt được với các hàm tự do trong một không gian tên. Tại sao lại ưu tiên cho cái sau?

Một lớp hoàn toàn tĩnh sẽ hoàn thành công việc, nhưng nó giống như lái một chiếc xe tải bán hàng dài 53 feet đến cửa hàng tạp hóa để mua chip và salsa khi một chiếc xe bốn cửa sẽ làm (nghĩa là quá mức cần thiết). Các lớp học đi kèm với một lượng nhỏ chi phí bổ sung và sự tồn tại của chúng có thể mang lại cho ai đó ấn tượng rằng việc bắt đầu một người có thể là một ý tưởng tốt. Các hàm miễn phí được cung cấp bởi C ++ (và C, trong đó tất cả các hàm đều miễn phí) không làm điều đó; chúng chỉ là chức năng và không có gì khác.

Mọi thứ sẽ khác đi, nếu bộ sưu tập các chức năng tiện ích cần một số dữ liệu chia sẻ, ví dụ như bộ đệm có thể lưu trữ trong trường tĩnh riêng?

Không hẳn vậy. Mục đích ban đầu của staticC (và sau này là C ++) là cung cấp lưu trữ liên tục có thể sử dụng được ở mọi cấp độ phạm vi:

int counter() {
    static int value = 0;
    value++;
}

Bạn có thể đưa phạm vi ra tới mức của một tệp, làm cho nó hiển thị với tất cả các phạm vi hẹp hơn nhưng không nằm ngoài tệp:

static int value = 0;

int up() { value++; }
int down() { value--; }

Một thành viên lớp tĩnh riêng trong C ++ phục vụ cùng một mục đích nhưng bị giới hạn trong phạm vi của một lớp. Kỹ thuật được sử dụng trong counter()ví dụ trên cũng hoạt động bên trong các phương thức C ++ và là điều tôi thực sự khuyên bạn nên làm nếu biến không cần phải hiển thị cho toàn bộ lớp.

Nếu một hàm duy trì không có trạng thái và được phát lại, thì dường như không có nhiều điểm trong việc đẩy nó vào trong một lớp, (trừ khi ngôn ngữ bị ép buộc). Nếu hàm duy trì một số trạng thái, (ví dụ: nó chỉ có thể được tạo ra an toàn luồng bằng phương thức tĩnh), thì các phương thức tĩnh trên một lớp có vẻ phù hợp.

Phần lớn các diễn ngôn về chủ đề ở đây có ý nghĩa, mặc dù có một cái gì đó rất cơ bản về C ++ làm cho namespacesvà classes / structs rất khác nhau.

Các lớp tĩnh (các lớp trong đó tất cả các thành viên là tĩnh và lớp sẽ không bao giờ được khởi tạo) chính là các đối tượng. Chúng không chỉ đơn giản là namespaceđể chứa các chức năng.

Lập trình meta mẫu cho phép chúng ta sử dụng một lớp tĩnh làm đối tượng thời gian biên dịch.

Xem xét điều này:

template<typename allocator_type> class allocator
{
public:
    inline static void* allocate(size_t size)
    {
        return allocator_type::template allocate(size);
    }
    inline static void release(void* p)
    {
        allocator_type::template release(p);
    }
};

Để sử dụng nó, chúng ta cần các hàm có trong một lớp. Một không gian tên sẽ không hoạt động ở đây. Xem xét:

class mallocator
{
    inline static void* allocate(size_t size)
    {
        return std::malloc(size);
    }
    inline static void release(void* p)
    {
        return std::free(p);
    }
};

Bây giờ để sử dụng nó:

using my_allocator = allocator<mallocator>;

void* p = my_allocator::allocate(1024);
...
my_allocator::release(p);

Miễn là một công cụ cấp phát mới cho thấy một chức năng allocatevà releasetương thích, việc chuyển sang một công cụ cấp phát mới là dễ dàng.

Điều này không thể đạt được với không gian tên.

Bạn luôn cần các chức năng là một phần của lớp học? Không.

Là sử dụng một lớp tĩnh một mô hình chống? Nó phụ thuộc vào ngữ cảnh.

Mọi thứ sẽ khác đi, nếu bộ sưu tập các chức năng tiện ích cần một số dữ liệu chia sẻ, ví dụ như bộ đệm có thể lưu trữ trong trường tĩnh riêng?

Trong trường hợp đó, những gì bạn đang cố gắng đạt được có khả năng được phục vụ tốt nhất thông qua lập trình hướng đối tượng.

Như John Carmack nổi tiếng đã nói:

"Đôi khi, việc thực hiện tao nhã chỉ là một hàm. Không phải là một phương thức. Không phải là một lớp. Không phải là một khung công tác. Chỉ là một hàm."

Tôi nghĩ rằng khá nhiều tiền nó lên. Tại sao bạn lại biến nó thành một lớp mạnh mẽ nếu nó rõ ràng không phải là một lớp? C ++ có sự sang trọng mà bạn thực sự có thể sử dụng các chức năng; trong Java, mọi thứ đều là một phương thức. Sau đó, bạn cần các lớp tiện ích, và rất nhiều trong số họ.