Bỏ qua những kẻ hủy diệt của người Viking trong C đang đưa YAGNI đi quá xa?

Tôi đang làm việc trên một ứng dụng nhúng trung bình trong C bằng các kỹ thuật tương tự OO. Các "lớp" của tôi là các mô đun .h / .c sử dụng các cấu trúc dữ liệu và các cấu trúc con trỏ hàm để mô phỏng đóng gói, đa hình và tiêm phụ thuộc.

Bây giờ, người ta sẽ mong đợi một myModule_create(void)chức năng đi kèm với một myModule_destroy(pointer)đối tác. Nhưng dự án đang được nhúng, các tài nguyên được khởi tạo thực tế không bao giờ nên được phát hành.

Ý tôi là, nếu tôi có 4 cổng nối tiếp UART và tôi tạo 4 phiên bản UART với các chân và cài đặt cần thiết của chúng, thì hoàn toàn không có lý do gì để muốn phá hủy UART # 2 tại một số điểm trong thời gian chạy.

Vì vậy, theo nguyên tắc YAGNI (Bạn sẽ không cần nó), tôi có nên bỏ qua các hàm hủy không? Điều này có vẻ cực kỳ lạ đối với tôi nhưng tôi không thể nghĩ ra cách sử dụng chúng; tài nguyên được giải phóng khi thiết bị tắt nguồn.

Nếu bạn không cung cấp một cách để loại bỏ đối tượng, bạn đang truyền một thông điệp rõ ràng rằng chúng có "vô hạn" trọn đời một khi được tạo. Nếu điều này có ý nghĩa với ứng dụng của bạn, tôi nói: làm điều đó.

Glampert là đúng; không cần thiết cho tàu khu trục ở đây. Họ sẽ chỉ tạo ra sự phình to mã và một cạm bẫy cho người dùng (sử dụng một đối tượng sau khi hàm hủy của nó được gọi là hành vi không xác định).

Tuy nhiên, bạn nên chắc chắn rằng thực sự không cần phải vứt bỏ đồ vật. Chẳng hạn, bạn có cần phải có một đối tượng cho một UART hiện không được sử dụng không?

Cách dễ nhất tôi đã tìm thấy để phát hiện rò rỉ bộ nhớ là có thể thoát khỏi ứng dụng của bạn một cách sạch sẽ. Nhiều trình biên dịch / môi trường cung cấp một cách để kiểm tra bộ nhớ vẫn được phân bổ khi ứng dụng của bạn thoát. Nếu không được cung cấp, thường có một cách để thêm một số mã ngay trước khi thoát mà có thể tìm ra nó.

Vì vậy, tôi chắc chắn sẽ cung cấp các hàm tạo, hàm hủy và logic tắt ngay cả trong một hệ thống nhúng mà "về mặt lý thuyết" không bao giờ thoát ra để dễ dàng phát hiện rò rỉ bộ nhớ. Trong thực tế, phát hiện rò rỉ bộ nhớ thậm chí còn quan trọng hơn nếu mã ứng dụng không bao giờ thoát ra.

Trong quá trình phát triển của tôi, việc sử dụng rộng rãi các loại dữ liệu mờ để thúc đẩy cách tiếp cận giống như OO, tôi đã quá vật lộn với câu hỏi này. Lúc đầu, tôi đã quyết định loại bỏ kẻ hủy diệt khỏi viễn cảnh YAGNI, cũng như viễn cảnh "mã chết" của MISRA. (Tôi có rất nhiều phòng tài nguyên, đó không phải là một sự cân nhắc.)

Tuy nhiên ... việc thiếu một bộ hủy có thể làm cho việc kiểm tra khó khăn hơn, như trong kiểm tra đơn vị / tích hợp tự động. Thông thường, mỗi thử nghiệm phải hỗ trợ thiết lập / phá vỡ để các đối tượng có thể được tạo, thao tác, sau đó hủy. Chúng bị phá hủy để đảm bảo một điểm khởi đầu sạch sẽ, chưa được xử lý cho thử nghiệm sau đó. Để làm điều này, lớp cần một hàm hủy.

Do đó, theo kinh nghiệm của tôi, "không" trong YAGNI hóa ra là "được" và cuối cùng tôi đã tạo ra các hàm hủy cho mọi lớp cho dù tôi nghĩ tôi có cần hay không. Ngay cả khi tôi bỏ qua kiểm tra, ít nhất một kẻ hủy diệt được thiết kế chính xác tồn tại cho khẩu hiệu kém theo tôi sẽ có một. (Và, với giá trị thấp hơn nhiều, nó làm cho mã có thể tái sử dụng nhiều hơn ở chỗ nó có thể được sử dụng trong môi trường mà nó sẽ bị phá hủy.)

Trong khi địa chỉ YAGNI, nó không giải quyết mã chết. Vì thế, tôi thấy rằng một macro biên dịch có điều kiện giống như #define BUILD_FOR_TESTING cho phép loại bỏ hàm hủy khỏi bản dựng sản xuất cuối cùng.

Thực hiện theo cách này: bạn có hàm hủy để thử nghiệm / tái sử dụng trong tương lai và bạn đáp ứng các mục tiêu thiết kế của YAGNI và quy tắc "không có mã chết".

Bạn có thể có một hàm hủy không op, giống như

  void noop_destructor(void*) {};

sau đó thiết lập hàm hủy của Uartcó lẽ bằng cách sử dụng

  #define Uart_destructor noop_destructor

(thêm dàn diễn viên phù hợp nếu cần thiết)

Đừng quên tài liệu. Có thể bạn muốn

 #define Uart_destructor abort

Ngoài ra, trường hợp đặc biệt trong mã phổ biến gọi hàm hủy là trường hợp khi hàm con trỏ hàm hủy là NULLđể tránh gọi nó.