Khi nào nên viết mã trừu tượng và khi nào cụ thể hơn?

Tôi đang làm việc trên một công cụ nhỏ như một dự án đồ chơi để hiển thị sự khác biệt giữa hai thư mục, cho thấy tệp / thư mục nào đã được thêm, xóa, sửa đổi, v.v.

Tôi đã cố gắng biểu diễn những thay đổi này chỉ đơn giản là các đối tượng 'ChangeItem', không phân biệt giữa nó là tệp hay thư mục. Tuy nhiên, điều đó tạo ra rất nhiều vấn đề, ví dụ như làm thế nào để hiển thị chúng trên cây, làm thế nào để biết cha mẹ của đứa trẻ là ai, v.v. Và nó cũng rất không trực quan.

Sau đó tôi chia các thay đổi giữa thay đổi thư mục và thay đổi tập tin. Điều đó ngay lập tức làm cho nó rất dễ dàng để mã hóa và để hiểu những gì đang xảy ra. Bây giờ đơn giản hơn nhiều để chọn tất cả các tệp trong một thư mục, v.v.

Câu hỏi của tôi là, làm thế nào người ta có thể biết nên sử dụng sự trừu tượng hóa hay để có được cụ thể hơn trong mã của họ? Làm thế nào bạn có thể biết nếu bạn có quá nhiều hoặc quá ít trừu tượng?

Làm thế nào để một họa sĩ biết liệu nó có quá nhiều hay quá ít màu tím?

Anh ấy pha trộn màu sắc, thử một nét, tạo một vài bản phác thảo và xem những gì sẽ xảy ra. Sau đó, anh ta điều chỉnh tỷ lệ cho đến khi toàn bộ bản vẽ trông đẹp và tỏa ra sự hài hòa.

Chúng tôi làm tương tự với mã. Chúng tôi có một ý tưởng thực hiện lần đầu tiên, phản ánh về nó, phân tích các mặt mạnh và tuần của nó sau đó thử để xem nó có hoạt động không. Sau đó, chúng tôi điều chỉnh ý tưởng trong một quy trình lặp để điều chỉnh tỷ lệ trừu tượng hóa, đóng gói, đa hình và bất cứ điều gì cho đến khi nó có vẻ đúng và hoạt động khi cần thiết.

Bạn viết mã cụ thể trước.

Bạn viết mã trừu tượng khi bạn phải bởi vì nó đơn giản hóa mã cụ thể.

Dễ dàng nhất để bắt đầu với cụ thể và tìm thấy sự trừu tượng sau khi nghiên cứu những gì tương tự và khác nhau về cụ thể.

Bạn viết mã trừu tượng khi bạn đang viết thư viện và phải khái quát hóa chức năng để nó hoạt động trong nhiều điều kiện khác nhau.

Nhưng viết thư viện theo cách này là khó. Trong một ứng dụng thông thường (giả sử, một dòng ứng dụng kinh doanh), loại khái quát hóa này được coi là một hình thức "tối ưu hóa sớm", thường có đặc điểm là "Bạn sẽ không cần nó" (YAGNI).

Có một điểm bùng phát trong đó mã lặp đi lặp lại đòi hỏi một giải pháp tổng quát hơn được thiết kế. Nhưng thông thường, kiểu tái cấu trúc này để loại bỏ sự dư thừa đơn giản hơn nhiều so với việc viết một thư viện tổng quát.

Cuối cùng, sự phức tạp bổ sung cần thiết để thực hiện các giải pháp trừu tượng phải được chứng minh bằng sự linh hoạt mà họ cung cấp.

Quy tắc ngón tay cái mà tôi tuân theo, khá phổ biến, là bạn không nên cố gắng trừu tượng hóa một cái gì đó cho đến khi bạn thấy mình viết nó lần thứ ba.

Lần đầu tiên bạn chỉ đơn giản là không hiểu miền vấn đề và sẽ kết thúc việc kiến ​​trúc quá mức tất cả các phần sai. Lần thứ hai bạn được định vị hoàn hảo để xây dựng giải pháp lý tưởng cho vấn đề cuối cùng của bạn. Lần thứ ba, bạn cuối cùng ở một vị trí tốt để đưa ra những tóm tắt phù hợp sẽ giúp bạn về những điều cần thay đổi, và không cản trở bạn hoàn thành công việc đơn giản.

Bằng cách đọc câu hỏi tôi sẽ nói rằng bạn có thể vừa trừu tượng vừa cụ thể. Chỉ là một vấn đề của bối cảnh, sử dụng đại diện trừu tượng nhất có thể trong mỗi bối cảnh.

Đối với ứng dụng đồ chơi cụ thể của bạn, ChangeItemlà đại diện trừu tượng nhất của những thay đổi. Sau đó, bạn có được cụ thể hơn với DirectoryChangeItemvà FileChangeItem, thông qua thừa kế. Bạn có thể sử dụng một mô hình tổng hợp để mô hình cây. Khi bạn muốn hiển thị nó, bạn có thể sử dụng các biểu diễn cụ thể và khi duyệt qua nó, bạn có thể sử dụng biểu diễn trừu tượng.

Và để đưa ra một câu trả lời cụ thể cho câu hỏi: hãy càng cụ thể càng tốt cho đến khi bạn cảm thấy rằng bạn cần một lớp khác bên dưới đó.

Thông thường sự trừu tượng là hữu ích để chống lại những thứ như Độ phức tạp, Entropy, để làm cho mã của bạn từ tính, và thậm chí ở mức độ dễ đọc. Tôi sẽ hardcode trước - CHỈ nếu sự trừu tượng không rõ ràng ở phía trước. Hầu hết sự trừu tượng xảy ra khi có nhiều hơn một triển khai chia sẻ cùng một mẫu.

Hãy nghĩ về sự trừu tượng là sự đồng nhất hoặc thống nhất của 2 hoặc nhiều Bộ. Lấy sơ đồ Venn làm mô hình đơn giản: Phần mà các vòng tròn chồng lên nhau, hay nói cách khác, Bộ hợp nhất.

Nếu tôi có hai bộ: A: {a, b, c, d, e} và B: {d, e, f, g, h}. Điểm mà tôi sẽ bắt đầu tìm cách trừu tượng là sự thống nhất của A + B; {d, e} là nơi trừu tượng. Tương tự, nếu những điểm khác biệt của A & B (AB hoặc BA) là đẳng cấu với nhau, nghĩa là chi phí thấp để tạo a, b hoặc c từ f, g hoặc h (và ngược lại), thì tôi sẽ tiếp tục trừu tượng hóa Trong tâm trí của tôi.