Từ quan điểm nguyên tắc RẮN câu trả lời của jgauffin có ý nghĩa. Tuy nhiên, bạn không nên quên các nguyên tắc thiết kế chung, ví dụ như ẩn thông tin .
Tôi thấy một số vấn đề với cách tiếp cận nhất định:
- Như bạn đã chỉ ra, mọi người không mong đợi sử dụng từ khóa 'mới', khi đối tượng được tạo không quản lý bất kỳ trạng thái nào . Thiết kế của bạn phản ánh ý định của nó. Những người sử dụng lớp của bạn có thể bị nhầm lẫn về trạng thái mà nó quản lý và liệu các cuộc gọi tiếp theo đến phương thức có thể dẫn đến hành vi khác nhau hay không.
- Từ quan điểm của người sử dụng lớp, trạng thái bên trong được ẩn giấu tốt, nhưng khi muốn sửa đổi lớp hoặc chỉ đơn giản là hiểu nó, bạn đang làm mọi thứ trở nên phức tạp hơn. Tôi đã viết rất nhiều về các vấn đề tôi thấy với các phương thức phân tách chỉ để làm cho chúng nhỏ hơn , đặc biệt là khi chuyển trạng thái sang phạm vi lớp. Bạn đang sửa đổi cách sử dụng API của mình để có các chức năng nhỏ hơn! Điều đó theo tôi chắc chắn là đưa nó đi quá xa.
Một số tài liệu tham khảo liên quan
Có thể một điểm chính của tranh luận nằm ở việc kéo dài bao xa Nguyên tắc Trách nhiệm duy nhất . "Nếu bạn đưa nó đến mức cực đoan đó và xây dựng các lớp có một lý do tồn tại, bạn có thể sẽ chỉ có một phương thức cho mỗi lớp. Điều này sẽ gây ra một lượng lớn các lớp cho ngay cả các quy trình đơn giản nhất, khiến hệ thống bị khó hiểu và khó thay đổi. "
Một tài liệu tham khảo có liên quan khác liên quan đến chủ đề này: "Chia các chương trình của bạn thành các phương thức thực hiện một nhiệm vụ có thể xác định được. Giữ tất cả các hoạt động trong một phương thức ở cùng một mức độ trừu tượng ." - Kent Beck Key ở đây là "cùng một mức độ trừu tượng". Điều đó không có nghĩa là "một điều", vì nó thường được giải thích. Mức độ trừu tượng này hoàn toàn tùy thuộc vào bối cảnh mà bạn đang thiết kế.
Vậy cách tiếp cận phù hợp là gì?
Nếu không biết trường hợp sử dụng cụ thể của bạn, thật khó để nói. Có một kịch bản trong đó đôi khi tôi (không thường xuyên) sử dụng một cách tiếp cận tương tự. Khi tôi muốn xử lý một tập dữ liệu, mà không muốn làm cho chức năng này có sẵn cho toàn bộ phạm vi lớp. Tôi đã viết một bài đăng trên blog về nó, làm thế nào lambdas thậm chí có thể cải thiện hơn nữa việc đóng gói . Tôi cũng bắt đầu một câu hỏi về chủ đề ở đây trên Lập trình viên . Sau đây là một ví dụ mới nhất về nơi tôi đã sử dụng kỹ thuật này.
new TupleList<Key, int>
{
{ Key.NumPad1, 1 },
...
{ Key.NumPad3, 16 },
{ Key.NumPad4, 17 },
}
.ForEach( t =>
{
var trigger = new IC.Trigger.EventTrigger(
new KeyInputCondition( t.Item1, KeyInputCondition.KeyState.Down ) );
trigger.ConditionsMet += () => AddMarker( t.Item2 );
_inputController.AddTrigger( trigger );
} );
Vì mã rất 'cục bộ' trong phạm vi ForEachkhông được sử dụng lại ở bất kỳ nơi nào khác, tôi chỉ có thể giữ nó ở vị trí chính xác nơi có liên quan. Phác thảo mã theo cách mà mã dựa vào nhau được nhóm mạnh mẽ với nhau làm cho nó dễ đọc hơn theo quan điểm của tôi.
Các lựa chọn thay thế có thể
- Trong C #, bạn có thể sử dụng các phương thức mở rộng thay thế. Vì vậy, hoạt động dựa trên đối số trực tiếp mà bạn chuyển sang phương pháp 'một điều' này.
- Xem liệu hàm này thực sự không thuộc về lớp khác.
- Làm cho nó một hàm tĩnh trong một lớp tĩnh . Đây rất có thể là cách tiếp cận phù hợp nhất, cũng được phản ánh trong các API chung mà bạn đã đề cập.
bool arrayContainsSomestring = new List<string>(stringArray).Contains("somestring");khi tất cả những gì tôi quan tâm là phần thông tin cụ thể đó và các phương thức mở rộng LINQ không có sẵn. Hoạt động tốt, và phù hợp với mộtif()điều kiện mà không cần phải nhảy qua vòng. Tất nhiên, bạn muốn có một ngôn ngữ được thu gom rác nếu bạn viết mã như thế.