Liệu chi phí phương thức của object-c có làm cho phương pháp thiết kế 'nhiều phương thức nhỏ' không thể thực hiện được không?

Tôi thường thích sử dụng các phương pháp nhỏ, theo khuyến nghị của, trong số những người khác, Bob Martin trong Clean Code . Tôi cũng đã đọc đủ về nội bộ của Objective-C để có ít nhất một số ý tưởng về cách thức gửi tin nhắn của nó hoạt động ( loạt bbums đặc biệt nhiều thông tin về điều này).

Tuy nhiên, tối ưu hóa mối quan tâm sớm, tôi muốn biết liệu tất cả những gì mà Objective-c làm với objc_msgSend, về mặt thực tế, có đủ ý nghĩa đối với phương pháp 'nhiều phương pháp nhỏ' không phù hợp với các dự án Objective-C không.

Kết quả thực nghiệm đặc biệt được hoan nghênh (đôi khi tôi sẽ tự mình thiết lập một bài kiểm tra). Kinh nghiệm từ bất cứ ai đã viết các dự án mục tiêu lớn cũng sẽ rất tuyệt.

Làm rõ

Giọng điệu chung của câu hỏi là có chủ ý. Tôi không hỏi về việc điều chỉnh hiệu suất của các ứng dụng cụ thể (đó là lý do tại sao tôi hỏi ở đây thay vì trên SO), nhưng nhiều hơn về việc liệu các đặc điểm ngôn ngữ của Objective-C có khuyến khích một phương pháp thiết kế nhất định hay không. Tôi đã quan sát thấy rằng phần lớn mã tôi đã thấy từ Apple và các bên khác (trên github, v.v.) có xu hướng hướng tới các phương thức lớn (và các lớp) và tôi tự hỏi liệu đây có phải là sự thiên vị đã xuất hiện vì ngôn ngữ chinh no. Tất nhiên tôi có thể đã đọc sai mã, hoặc nó có thể là văn hóa hơn là các yếu tố kỹ thuật đã dẫn đến xu hướng nếu nó tồn tại.

(Để biết giá trị của nó, tôi hiện đang viết Objective-C và tôi đang sử dụng các phương thức nhỏ)

Yêu cầu thêm

Tôi đồng ý với cả hai câu trả lời đã được đưa ra. Một điều nữa tôi muốn là cho ai đó chỉ cho tôi một cơ sở mã nguồn Objective-C (hoặc có thể nhìn thấy rõ) khác sử dụng các phương thức ngắn (và các lớp nhỏ). Tôi chưa thấy bất cứ điều gì trong Objective-C để so sánh với (ví dụ) nguồn fitnesse .

Tôi thực sự không biết liệu chi phí có đáng kể hay không. Nhưng, tôi muốn thiết kế một hệ thống để dễ hiểu và dễ bảo trì trước tiên , và điều đó thường có nghĩa là các phương thức và lớp nhỏ, tập trung. Điều này thậm chí sẽ giúp điều chỉnh mã tiếp theo (chỉ vì mã dễ bảo trì hơn). Ngoài ra, điều quan trọng là lập hồ sơ mã để tìm các tắc nghẽn thực sự, thậm chí có thể không liên quan đến chi phí cuộc gọi phương thức. Nếu bạn thực hiện bất kỳ hoạt động ngoài quy trình nào (ví dụ như các cuộc gọi đến cơ sở dữ liệu, mạng, hệ thống tệp), thì chúng có xu hướng chi phối thời gian chạy của chương trình.

Nhưng, như thường lệ, số dặm của bạn có thể thay đổi ...

Phần lớn mã sẽ không quan trọng về hiệu năng trong bất kỳ ứng dụng nào , vì vậy ngay cả khi chi phí phương thức là đáng kể so với các ngôn ngữ khác, cách tiếp cận tối ưu vẫn sẽ có nhiều phương thức nhỏ ở hầu hết các phương thức và chỉ nội tuyến đã được chỉ ra là quan trọng về hiệu suất.

Tất nhiên, có nhiều người không biết cách tối ưu hóa đúng cách và một số người có thể biết về chi phí phương pháp và tham gia vào các hành động tối ưu hóa sớm toàn cầu, nhưng tôi không tin rằng nhóm đó đủ lớn để có tác động đáng kể trên hệ sinh thái Objective-C.

Các phương pháp và lớp học lớn có nhiều khả năng là công việc của một nhóm lớn những người không biết hoặc không quan tâm đến hồ sơ, phương pháp hay thiết kế phù hợp, và những người sẽ có xu hướng tạo ra Big Balls of Mud bằng bất kỳ ngôn ngữ nào . Và vâng, một số người làm việc trên các cơ sở mã cao cấp trong các công ty phần mềm lớn.