Các quy tắc về tính cụ thể của các loại tham số phương thức, kiểu trả về và kiểu thuộc tính


9

Cách đây một thời gian, tôi đã đọc một loại "quy tắc chung" về sự cụ thể của các loại tham số phương thức, kiểu trả về và kiểu thuộc tính, nhưng tôi không nhớ nó.

Nó nói điều gì đó về việc giữ cho các kiểu trả về của bạn cụ thể nhất có thể và các loại tham số của bạn càng trừu tượng càng tốt ... hoặc ngược lại.

Tôi không biết đó thực sự là một lời khuyên tốt hay xấu, vì vậy nếu bạn có suy nghĩ riêng về nó, xin hãy để lại nhận xét.

Chúc mừng.

Câu trả lời:



7

Có đầu vào trừu tượng và đầu ra cụ thể làm cho chức năng của bạn tổng quát hơn. Điều này có nghĩa là nó có thể được sử dụng theo nhiều cách hơn. Mặt khác, nó đặt ra các ràng buộc mạnh mẽ hơn cho phương pháp của bạn, hạn chế cách triển khai trong tương lai của nó. Vì vậy, đó là một sự đánh đổi giữa các mục tiêu khác nhau.


4

Có thể bạn đã nghe ngoại suy luật của Postel : "Hãy thận trọng trong những gì bạn gửi, tự do trong những gì bạn chấp nhận."

Chủ yếu là về tối đa hóa khả năng sử dụng lại mã. Thật dễ dàng để đưa ra các trường hợp để chứng minh tại sao nó giúp. Hãy xem xét Java Iterable<T>như một ví dụ. Nếu điều duy nhất mà phương thức của bạn thực hiện là lặp qua tất cả các Ts, thì có một Iterable<T>kiểu tham số cho phép bạn sử dụng phương thức đó với hơn 60 lớp dựng sẵn, không đề cập đến bất kỳ lớp tùy chỉnh nào thực hiện giao diện. Nếu bạn giới hạn nó, giả sử, Vector<T>thì bất kỳ mã nào gọi phương thức của bạn sẽ phải chuyển đổi thành mã Vector<T>đầu tiên.

Mặt khác, việc trả về một Iterable<T>từ một phương thức sẽ giới hạn số lượng mã có thể sử dụng giá trị trả về của bạn cho các phương thức lấy Iterable<T>tham số. Nếu bạn quay trở lại một loại rất cụ thể, như Vector<T>, sau đó giá trị trả về của bạn có thể được thông qua vào bất kỳ phương pháp mà phải mất một Serializable, Cloneable, Iterable<T>, Collection<T>, List<T>, RandomAccess, Vector<T>, AbstractList<T>, hay AbstractCollection<T>, và nó sẽ làm việc như mong đợi.


Luật của Postel khá cao trong danh sách "những lỗi kỹ thuật phần mềm lớn nhất" của tôi.
CodeInChaos
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.