Phương thức tĩnh không trạng thái so với hàm C trong Mục tiêu-C

Question

Về thực hành mã hóa Mục tiêu-C tốt, nếu tôi tạo một hàm không có trạng thái, tốt hơn là viết nó làm phương thức tĩnh của một số lớp hoặc C chức năng?

Ví dụ, tôi có một phương pháp truy xuất tập tin đặc biệt để kiểm tra thư mục Caches trước khi tiếp tục với NSBundle chính. Tôi hiện đang có nó như là một phương pháp tĩnh theo một lớp học Utils trống rỗng. Đây có nên là hàm C thay thế không?

Lý do tôi chọn sử dụng phương pháp tĩnh (hiện tại) là a) nó phù hợp với cú pháp Objective-C và b) lớp giúp phân loại phương thức. Tuy nhiên, tôi cảm thấy như tôi đang lừa dối một chút, vì tôi có thể dễ dàng điền vào lớp Util của tôi với các phương pháp tĩnh không trạng thái này và kết thúc với một lớp vỏ "xấu xí", mục đích duy nhất là giữ chúng.

Bạn sử dụng quy ước nào? Là một "tốt hơn" khác, bởi một số số liệu khách quan? Cảm ơn bạn!

Answer 1

Nếu bạn có thể nghĩ ra một lớp hiện có trong đó điều này có thể tạo một phương pháp tốt, bạn có thể đưa phương pháp của bạn vào phương pháp đó bằng cách tạo danh mục Mục tiêu-C. Điều này giữ hai lý do của bạn để sử dụng một phương thức tĩnh trong khi không gây ô nhiễm không gian lớp học với một lớp bổ sung.

Ví dụ:

@interface NSString (MyStringCategories) 
- (NSString*) myCoolMethod; 
@end 

// [StringCategories.m] 
#import "StringCategories.h" 

@implementation NSString (MyStringCategories) 
- (NSString*) myCoolMethod { 
    // do cool stuff here 
    return whateverYouLike; 
} 
@end 

Bây giờ bạn có thể gửi myCoolMethod-bất kỳ chuỗi. Mát mẻ!

Trong trường hợp cụ thể của bạn, có vẻ như một phương pháp trên NSBundle có thể là một kiến ​​trúc thích hợp. Và đừng quên, nó có thể là một phương pháp lớp, vì vậy bạn không cần phải khởi tạo bất cứ điều gì để gọi phương thức của bạn.

Answer 2

Đây là một câu hỏi khá khó trả lời bởi vì đối với nhiều người, câu trả lời sẽ tùy thuộc vào sở thích cá nhân và thị hiếu của họ. Cá nhân tôi nghĩ rằng nếu bạn có một hàm là một hàm, tức là nó không liên quan gì đến một đối tượng, nó không có trạng thái bên trong, vv .. hãy để nó là một hàm và không cố gắng bọc mọi thứ bạn có thể vào một đối tượng chỉ vì bạn đang sử dụng một ngôn ngữ OO và bạn có thể.

Để giữ cho câu trả lời của tôi ngắn hãy để tôi đề cập đến một (IMO) cuốn sách khá tốt:

http://www.gotw.ca/publications/c++cs.htm

Tôi biết rằng đây là dành cho C++, nhưng có khá một vài hiểu biết đó có thể là được chia sẻ với các ngôn ngữ khác (đặc biệt là Objective-C và Objective-C++), đặc biệt là từ phần "Class Design and Inheritance". Ở đó bạn sẽ tìm thấy một mục có tiêu đề "Ưu tiên viết các hàm nonfriend không phải là người bạn".

Dòng dưới cùng: "Các chức năng không phải là thành viên cải thiện đóng gói bằng cách giảm thiểu phụ thuộc [...] Chúng cũng phá vỡ các lớp nguyên khối [...] [và] cải thiện tính tổng hợp [...]".

Tôi nghĩ có một số sự thật trong mục đó.

Answer 3

Nếu không có lớp nào ràng buộc rõ ràng, thì tôi sử dụng hàm. Tôi cũng sử dụng các hàm cho các bit tiện ích này vì chúng có thể bị tước bỏ nếu không được sử dụng hoặc tham chiếu. Về vấn đề đó, việc sử dụng hàm cũng hữu ích vì lỗi liên kết tốt hơn lỗi thời gian chạy (ngay cả .m đã vô tình bị bỏ qua từ bản dựng hoặc nếu được tham chiếu từ một phương thức được cập nhật bên ngoài khác).Một vấn đề với các ký hiệu ObjC là chúng không bị tước đi, vì vậy chúng tự nhiên mang một lượng phụ thuộc cao - tất cả các phương thức và lớp objc, và các phương thức danh mục bắt buộc phải tồn tại trong nhị phân cuối cùng. Đó không phải là vấn đề với các chương trình hoặc thư viện thực sự nhỏ, nhưng nó nhanh chóng tăng cân với các hệ thống và thư viện trung bình/lớn.

Mọi thứ không cần phải khai báo trong một @interface - đặc biệt là với các hệ thống lớn hơn nơi tất cả các khai báo đó sẽ thực sự biến các phụ thuộc lẫn nhau của bạn thành spaghetti. So với các phương thức, các hàm nhanh hơn, nhỏ hơn, có thể được tối ưu hóa tốt hơn bởi trình biên dịch hoặc trong quá trình liên kết và có thể bị tước bỏ nếu không được tham chiếu.

Nếu bạn cần đa hình, nó chỉ thuộc về một lớp để tổ chức hoặc thuận tiện, sau đó một lớp hoặc phương pháp thể hiện thường là một lựa chọn tốt hơn.

Tôi cũng giảm thiểu việc khai báo phương pháp danh mục vì cùng một lý do. Khi bạn đang sử dụng các hàm, bạn có thể dễ dàng viết một phương thức trình bao bọc mà bạn cần nó và tận dụng tối đa cả hai thế giới.