Làm thế nào để bạn tiếp cận thiết kế lớp trong OOP?

Khi tôi cố gắng thiết kế một giải pháp OO, tôi thường sử dụng mô hình CRC trong đó tôi liệt kê tên lớp (danh từ), những gì họ làm (động từ) và cách họ cộng tác với các lớp khác.

Đây diễn đàn có điều dưới đây để nói về cách tiếp cận danh động từ này

   ...This approach, which I will call “noun and verb,” is so limited 
   I’ll dare to call it brain damaged....

Câu hỏi của tôi là, có tồn tại một kỹ thuật mô hình tốt hơn để sử dụng phương pháp OO không?

Công bằng mà nói, anh ta đã thêm "Trong niềm vui" vào yêu sách đó.

Cho đến ngày nay, tôi có xu hướng bắt đầu bằng cách mô hình hóa các hệ thống bằng cách sử dụng phương pháp "danh từ và động từ", nhưng tôi đã phát hiện ra trong nhiều năm qua TDD dạy chúng ta rằng cách tiếp cận này khiến bạn tập trung vào điều sai. Theo nghĩa này, các blogger có một điểm. Tuy nhiên, tôi không chắc chắn rằng đó là cách tiếp cận có lỗi, hơn là cách mà tâm trí của chúng ta hoạt động.

Nếu bạn muốn thử một chút thử thách ở đây, hãy ngừng đọc và thử mô hình hóa trò chơi Monopoly, sử dụng ngôn ngữ tiếng Anh, sau đó quay lại đây.

Tôi nghi ngờ sự cám dỗ sẽ là ngay lập tức nhìn vào các vật thể mà chúng ta tương tác với nhiều thứ - bảng, không gian, thẻ, súc sắc, các mảnh - nhưng đó không phải là nơi mà phần lớn logic đi. Hầu hết các đối tượng này là hoàn toàn ngu ngốc. Dữ liệu, nếu bạn muốn.

Nhưng ngay khi bạn bắt đầu viết bài kiểm tra, bạn sẽ nhận ra đối tượng nào là quan trọng nhất trong bất kỳ trò chơi nào: các quy tắc.

Hãy nhớ rằng mảnh giấy nhỏ mà bạn đã đọc một lần khi bạn mới chơi trò chơi và không tương tác lại cho đến khi có tranh chấp? Phiên bản trên máy vi tính không hoạt động theo cách đó. Mỗi một điều người chơi cố gắng thực hiện, một máy tính sẽ tham khảo các quy tắc và xem liệu họ có được phép làm điều đó hay không.

Khi bạn nghĩ về nó, bạn cũng làm điều tương tự nhưng vì cần có thời gian để đọc các quy tắc dựa trên giấy và bộ não của bạn có một hệ thống bộ nhớ đệm hợp lý, bạn tham khảo các quy tắc trong đầu. Một máy tính có thể sẽ tìm thấy nó dễ dàng để đọc lại các quy tắc - trừ khi chúng được lưu trữ trong cơ sở dữ liệu, trong trường hợp đó nó cũng có thể lưu trữ chúng.

Và đây là lý do tại sao TDD rất phổ biến cho thiết kế lái xe thực sự. Bởi vì nó có xu hướng thúc đẩy quá trình suy nghĩ của bạn nhanh chóng đến đúng nơi:

Khi tôi nghĩ rằng tôi sẽ viết một số bài kiểm tra cho trò chơi Monopoly của mình. Tôi có thể nhìn vào bộ của mình và cố gắng tìm các đối tượng. Vì vậy, chúng tôi đã có những mảnh này. Tôi sẽ viết một số bài kiểm tra cho những người đó.

Có lẽ tôi sẽ có một lớp MonopolyPiece cơ sở và mỗi loại mảnh sẽ xuất phát từ những thứ đó. Tôi sẽ bắt đầu với DogPiece. Thử nghiệm đầu tiên ... à. Trên thực tế, không có logic ở đây. Vâng, mỗi tác phẩm sẽ được vẽ khác nhau, vì vậy tôi có thể cần DogDrawer, nhưng trong khi tôi đang tìm hiểu về trò chơi, tôi chỉ muốn viết "D" trên màn hình. Tôi sẽ thêm gia vị vào cuối UI.

Hãy tìm một số logic thực tế để kiểm tra. Có rất nhiều những ngôi nhà và khách sạn này, nhưng họ không cần thử nghiệm. Tiền, không. Thẻ tài sản, không. Và như thế. Ngay cả bảng cũng không có gì ngoài một máy trạng thái, nó không chứa bất kỳ logic nào.

Bạn sẽ nhanh chóng thấy bạn có ba thứ còn lại trong tay. Thẻ Chance và Community Chest, một cặp súc sắc và một bộ quy tắc. Đây sẽ là những phần quan trọng để thiết kế và thử nghiệm.

Bạn có thấy điều đó đến khi bạn viết ra các danh từ và động từ không?

Trên thực tế, có một ví dụ tuyệt vời trong Các mô hình và nguyên tắc Agile Nguyên tắc Agile của Robert Martin khi họ cố gắng đưa ra ứng dụng Thẻ Bowling bằng TDD và tìm thấy tất cả những điều họ nghĩ là những lớp rõ ràng không đáng bận tâm.

Tôi chưa bao giờ thấy các phương pháp như vậy hữu ích cho tôi. Trong thực tế, tôi thấy rằng việc sử dụng chúng chỉ làm tôi bối rối hơn. Hãy xem Máy pha cà phê của Robert C. Martin , tôi cũng không nghĩ anh ấy sử dụng kiểu tiếp cận này.

Một điều làm tôi bực mình là giải pháp mà người đó tìm đến trong bài viết CRC mà bạn liên kết đến. Sự hợp tác của Khách hàng / Đơn hàng không phải là thứ tôi cho là đáng giá, dù sao cũng không được viết. Không có gì đặc biệt thú vị trong mô hình đó về một Khách hàng xứng đáng với vị thế của lớp. Điều duy nhất thú vị khi trở thành "khách hàng" là có một hoặc nhiều đơn hàng liên quan đến Người đó .

Mô hình đại học cũng vậy. Có rất nhiều điều có thể, và có lẽ nên được chia sẻ giữa Sinh viên và Giáo sư. Hơn nữa, điều gì xảy ra khi bạn có một Giáo sư tham gia một lớp học, như thường được phép miễn phí trong các trường đại học?

Tôi cho rằng nó có thể là một thực tiễn đáng giá, một yếu tố trong bộ công cụ thiết kế. Tôi không nghĩ rằng đó là cách duy nhất bạn tiếp cận thiết kế ít nhất. Thành thật mà nói, tôi thấy cách tiếp cận phân tích phổ biến / biến thể hữu ích hơn. Tôi dường như mô hình rất chặt chẽ những gì chúng ta làm trong việc phân loại trừu tượng trong cuộc sống hàng ngày.

Chỉnh sửa: Chỉ cần đọc một nửa blog thứ hai và tôi phải nói rằng tôi đồng ý với nó khá nhiều. Tôi sẽ phải đọc phần còn lại và xem những gì nó cung cấp về mặt học tập.

Ý kiến ​​của tôi là các lớp nên thêm (và loại bỏ) khi bạn viết mã để tách các mối quan tâm và giảm sự phụ thuộc. Thông thạo các mẫu thiết kế có lẽ là một lựa chọn tốt để xem các khả năng tái cấu trúc và đơn giản hóa.

Các lớp nói chung, theo kinh nghiệm của tôi, không rơi vào các danh từ / động từ một cách gọn gàng mà thay vào đó bạn sẽ kết hợp với các lớp danh từ / động từ cùng với các lớp mẫu khác nhau (nhà máy, singletons, mẫu chiến lược, v.v.) và các lớp quản lý khác giải quyết một khía cạnh của ứng dụng của bạn.

Điều quan trọng là mục tiêu của bạn là có thể nhìn vào một lớp và suy ra những gì nó làm và sửa đổi điều đó bằng cách chỉ thay đổi lớp đó. Càng nhiều mã cho một khía cạnh của ứng dụng của bạn được trải đều giữa các lớp thì càng khó theo dõi, quản lý và mở rộng nó.