2009-05-17 48 views
6

Tôi thấy rằng có hai loại phương pháp được gọi là phương pháp tĩnh và phương pháp thể hiện và sự khác biệt của chúng. Nhưng tôi vẫn không thể hiểu được ưu điểm của cái khác.Điều gì là tốt hơn? Phương pháp tĩnh HOẶC Phương pháp thể hiện

Thỉnh thoảng tôi cảm thấy rằng các phương pháp tĩnh không được định hướng đối tượng 100%.

Có sự khác biệt về hiệu suất nào giữa hai điều này hay không.

Ai đó có thể trợ giúp?

Trả lời

2

Phương pháp thể hiện yêu cầu chuyển một tham số ngầm định (tham chiếu this) khiến chúng chậm hơn một chút so với phương thức static. Nhưng điều đó thực sự không phải là lý do để thích chúng.

Đối với một cuộc thảo luận liên quan, xem xét:

Should C# methods that *can* be static be static?

+1

Vui lòng chỉ xem xét đối số tốc độ nếu bạn đang cố gắng thực hiện điều gì đó trên nền tảng rất chậm hoặc hàng trăm danh sách số lần trong một giây. Tôi đoán là bạn đang làm việc với một bộ xử lý lõi kép> 2 Ghz. Chênh lệch tốc độ giữa cuộc gọi hàm thành viên và cuộc gọi hàm tĩnh không phải là tiêu chí thiết kế. –

+1

Vâng, ngay cả trên nền tảng chậm hơn nhiều, nó không phải là một xem xét thiết kế (như tôi đã nói trong câu trả lời). Tôi chỉ lưu ý sự khác biệt về hiệu suất vì nó được yêu cầu cụ thể. –

1

tôi một phần đoán dựa trên các di sản của C# nhưng tôi nghi ngờ nó giống như các ngôn ngữ OO khác.

Phương pháp tĩnh không yêu cầu đối tượng cần thực hiện. Một ví dụ điển hình là:

Double pi = Math.PI. 

Phương pháp thể hiện yêu cầu đối tượng. Một ví dụ nằm dọc theo các dòng:

Integer x = 9; 
Integer y = x.sqrt(); 

Không phải tất cả thông tin thuộc một lớp đều cần một đối tượng được khởi tạo cho lớp đó để truy cập vào lớp đó. Tất cả các hằng số có thể được sử dụng để tạo các đối tượng (Math.PI, Window.OVERLAPPED, v.v.) là các ví dụ chính về điều này.

2

Nếu phương pháp của bạn sử dụng thành viên dữ liệu không tĩnh, đừng làm cho nó tĩnh (bạn "không thể").

Nếu phương pháp của bạn không sử dụng bất kỳ thành viên dữ liệu không tĩnh nào, bạn có thể làm cho nó tĩnh, nhưng chủ yếu phụ thuộc vào thiết kế của bạn hơn là sử dụng hay không sử dụng thành viên không tĩnh (không có nhiều khác biệt về hiệu suất anyway như Mehrdad nói).

Nếu bạn có NO thành phần dữ liệu không tĩnh trong lớp, đôi khi thực hành tốt nhất là làm cho tất cả các phương thức tĩnh (như trong trường hợp nhóm các hàm trợ giúp theo một lớp vì lợi ích của thứ tự tốt).

6

Trong một thế giới OO hoàn hảo, có thể sẽ không cần bất kỳ phương pháp tĩnh nào (tôi nghĩ Eiffel cũng không có chúng). Nhưng vào cuối ngày, những vấn đề không phải là sự thuần khiết của mã của bạn (C# có đủ khái niệm không phải là OO thuần túy hoàn toàn, ví dụ như các phương thức mở rộng) mà là những gì bạn đang làm.

Bạn có thể sử dụng phương pháp tĩnh cho phương pháp trợ giúp chung (không cần lớp trợ giúp chung hoặc trạng thái của chính nó) hoặc những thứ như Color.FromARGB() hoạt động hơi giống với kiểu giá trị.

Nói chung, bất kỳ phương pháp nào không chạm vào trạng thái đối tượng (và do đó có nhiều lớp cụ thể hơn đối tượng cụ thể) có thể được tạo thành tĩnh. Hiệu suất khác biệt không thực sự phát sinh. Không phải là rất có thể đo lường, trong mọi trường hợp. Bài viết tuyệt vời của Jan Gray Writing faster managed code: Know what things cost có một số dữ liệu khó về vấn đề này, mặc dù được thực hiện cẩn thận.

+2

Ngay cả trong một "thế giới OO thuần túy", tôi không thấy cách làm Math.Cos một phương pháp thể hiện sẽ là "nhiều OO" hơn. Đối với các phương thức tiện ích như vậy, không có sự khác biệt về khái niệm giữa việc có một phương thức tĩnh với tham số N hoặc có một phương thức thể hiện với tham số N-1 trong đó "this" được hiểu là tham số đầu tiên ("Math.Cos (double)" VS "double.Cos()"). – Trillian

4

Tính hữu ích của phương pháp tĩnh chủ yếu xuất hiện khi bạn cần gọi phương thức mà không bao giờ khởi tạo đối tượng. Ví dụ, có lẽ phương thức tĩnh là ở đó để thực sự tìm kiếm một cá thể hiện có và trả về nó (một ví dụ là một cá thể singleton).

Như những người khác đã nêu, bạn có thể thực hiện bất kỳ phương pháp tĩnh nào nếu nó không truy cập trạng thái và bạn sẽ nhận được một cải tiến hiệu suất nhỏ.

Nếu bạn thực sự muốn có thể gọi phương thức trên một trường hợp cụ thể và nhận được lợi ích của đa hình (nghĩa là lớp dẫn xuất có thể ghi đè hành vi của phương thức), thì bạn nên đặt phương thức .

Nếu lớp của bạn triển khai giao diện, thì các phương thức thuộc về các giao diện đó cũng phải được khai báo là phương thức mẫu.

3

Phương pháp thể hiện chặt chẽ với một phiên bản. Vì vậy, bạn có thể thấy một lợi thế của các phương thức tĩnh không được chặt chẽ với một cá thể. Các phương thức tĩnh có thể (nếu có thể nhìn thấy) được các đối tượng khác sử dụng để giải quyết các vấn đề của chúng. Đôi khi điều này tốt và cần thiết. Sau đó, bạn phải suy nghĩ về việc giữ các phương thức tĩnh trong cùng một lớp hoặc nếu bạn bắt đầu xây dựng các lớp tiện ích để sử dụng rộng rãi hơn. Tôi sẽ không thấy việc sử dụng các phương pháp tĩnh là "ít OO". Các phương thức tĩnh là một cách để phá vỡ những thiếu sót của OO (đặc biệt là trong các ngôn ngữ kế thừa đơn). Bạn có thể gọi nó là một cách tiếp cận chức năng hơn (tôi biết nó không thực sự). Lấy tất cả điều này chỉ là một loạt các câu hỏi mà bạn nên hỏi mã của bạn và điều đó nên xác định xem nó có tốt hơn một phương thức thể hiện, một phương thức tĩnh của cùng một lớp hay một phương thức tĩnh của một lớp khác hay không.

Tôi thậm chí sẽ không nghĩ về các vấn đề về hiệu suất. Nó sẽ làm suy yếu thiết kế của bạn và sự khác biệt không thực sự lớn. Hiệu suất là quan trọng nếu bạn có vấn đề về hiệu suất.

1

Không ai tốt hơn người kia. Nó thực sự phụ thuộc vào yêu cầu của bạn. Các phương thức lớp được gọi khi bạn muốn áp dụng một thay đổi cho toàn bộ lớp. Trong khi các phương thức Instance được gọi khi bạn không áp dụng thay đổi cho lớp nhưng đối với một cá thể (đối tượng) duy nhất của lớp đó.

Vì vậy, tôi không thấy lý do tại sao một người nên tốt hơn người kia.

Các vấn đề liên quan