Gần đây tôi gặp phải tình huống sau.
class A{
public:
void calculate(T inputs);
}Thứ nhất, Ađại diện cho một đối tượng trong thế giới vật lý, đó là một lập luận mạnh mẽ cho việc không tách lớp lên. Bây giờ, calculate()hóa ra là một chức năng khá dài và phức tạp. Tôi nhận thấy ba cấu trúc có thể cho nó:
- viết nó như một bức tường của văn bản - lợi thế - tất cả thông tin đều ở một nơi
- viết
privatecác hàm tiện ích trong lớp và sử dụng chúng trongcalculatecác nhược điểm của cơ thể - phần còn lại của lớp không biết / quan tâm / hiểu về các phương thức đó viết
calculatetheo cách sau:void A::calculate(T inputs){ auto lambda1 = () [] {}; auto lambda2 = () [] {}; auto lambda3 = () [] {}; lambda1(inputs.first_logical_chunk); lambda2(inputs.second_logical_chunk); lambda3(inputs.third_logical_chunk); }
Điều này có thể được coi là một thực hành tốt hay xấu? Liệu phương pháp này tiết lộ bất kỳ vấn đề? Nói chung, tôi có nên coi đây là một cách tiếp cận tốt khi tôi lại phải đối mặt với tình huống tương tự không?
BIÊN TẬP:
class A{
...
public:
// Reconfiguration of the algorithm.
void set_colour(double colour);
void set_density(double density);
void set_predelay(unsigned long microseconds);
void set_reverb_time(double reverb_time, double room_size);
void set_drywet(double left, double right);
void set_room_size(double value);;
private:
// Sub-model objects.
...
}Tất cả những phương pháp đó:
- nhận được một giá trị
- tính toán một số giá trị khác mà không sử dụng trạng thái
- gọi một số "đối tượng mô hình phụ" để thay đổi trạng thái của chúng.
Nó chỉ ra rằng, ngoại trừ set_room_size(), các phương thức đó chỉ đơn giản chuyển giá trị được yêu cầu cho các đối tượng phụ. set_room_size()mặt khác, một vài màn hình của các công thức tối nghĩa và sau đó (2) thực hiện một nửa màn hình gọi setters đối tượng phụ để áp dụng các kết quả thu được khác nhau. Do đó, tôi đã tách chức năng thành hai lambdas và gọi chúng ở cuối chức năng. Nếu tôi có thể chia nó thành nhiều phần hợp lý hơn, tôi sẽ tách được nhiều lambdas hơn.
Bất kể, mục tiêu của câu hỏi hiện tại là xác định xem cách suy nghĩ đó có nên tồn tại hay không, tốt nhất là không thêm giá trị (khả năng đọc, khả năng duy trì, khả năng gỡ lỗi, v.v.).
Firstly, A represents an object in the physical world, which is a strong argument for not splitting the class up.Chắc chắn Ađại diện cho dữ liệu về một đối tượng có thể tồn tại trong thế giới vật lý. Bạn có thể có một trường hợp Akhông có đối tượng thực và đối tượng thực mà không có đối tượng A, vì vậy đối xử với họ như họ là một và giống nhau là vô nghĩa.
calculate()biết nhưng sẽ biết về các chức năng phụ đó.
A, điều đó sẽ làm cho nó trở nên cực kỳ.
Ađại diện cho một đối tượng trong thế giới vật lý, đó là một lập luận mạnh mẽ cho việc không tách lớp lên." Thật không may, tôi đã nói điều này khi tôi bắt đầu lập trình. Phải mất nhiều năm tôi mới nhận ra rằng đó là một khúc côn cầu ngựa. Đó là một lý do khủng khiếp để nhóm các thứ. Tôi không thể nói rõ những gì là lý do tốt để điều nhóm (ít nhất là sự hài lòng của tôi), nhưng điều đó một là một, bạn nên loại bỏ ngay bây giờ. Cuối cùng, tất cả là "mã tốt" là nó hoạt động đúng, tương đối dễ hiểu và tương đối dễ thay đổi (nghĩa là những thay đổi không có tác dụng phụ kỳ lạ).