Các quy tắc quan trọng trong Thiết kế Mô hình Đối tượng

Question

Chúng tôi đang phát triển một phần mở rộng (trong C# .NET env.) Cho ứng dụng GIS, có các loại được xác định trước để lập mô hình các đối tượng thế giới thực, bắt đầu từ GenericObject và chuyển đến các loại cụ thể hơn như Ống và Đường với các thuộc tính và phương pháp chi tiết của chúng như BottomOfPipe, Diameter và vân vân.

Chắc chắn, sẽ có một Object Model, Interface s, Inheritance và rất nhiều bộ phận thiết yếu khác trong typelibrary, và bây giờ chúng tôi cố định một số trong số họ. Nhưng như bạn có thể biết, thiết kế một mô hình đối tượng là một công việc rất mơ hồ, và (tôi biết nhiều nhất), có thể được thực hiện theo nhiều cách khác nhau và nhiều kết quả và điểm yếu khác nhau.

Có quy tắc riêng biệt nào trong việc thiết kế O.M.: các Hierarchy, cách xác định Interface s, trừu tượng và coclasse s enum s?

Bất kỳ đề xuất, tham chiếu hoặc thực hành nào?

Answer 1

Một vài người tốt:

RẮN

S Ingle nguyên tắc trách nhiệm
O bút/đóng nguyên tắc L nguyên tắc thay thế iskoff nguyên tắc phân biệt

tôi nterface
D ependency nguyên tắc đảo ngược

biết thêm thông tin và nhiều hơn nữa nguyên tắc ở đây: http://mmiika.wordpress.com/oo-design-principles/

Answer 2

Kiểm tra "nguyên tắc" của thiết kế hướng đối tượng. Những hướng dẫn này có tất cả các câu hỏi mà bạn yêu cầu.

Tài liệu tham khảo:

• "hướng đối tượng xây dựng phần mềm" bởi Robert Martin
• http://www.objectmentor.com/resources/publishedArticles.html

Thanh toán các "nguyên tắc thiết kế" bài báo tại địa điểm trên. Họ là những tài liệu tham khảo tốt nhất có sẵn.

Answer 3

"BottomOfPipe"? Đó có phải là một cách khác để nói chiều sâu của đường ống bên dưới đường không?

Bất kỳ loại thiết kế nào cũng khó và có thể được thực hiện theo nhiều cách khác nhau. Không có gì đảm bảo rằng thiết kế của bạn sẽ hoạt động khi bạn tạo ra nó.

Lợi thế mà những người thiết kế vòng bi và như vậy có nhiều năm kinh nghiệm và dữ liệu hơn để xác định những gì hiệu quả và những gì không. Phần mềm không có nhiều thời gian hoặc dữ liệu cứng.

Dưới đây là một số lời khuyên:

1. thừa kế có nghĩa là IS-A. Nếu điều đó không giữ, không sử dụng thừa kế.
2. Phân cấp sâu có thể là dấu hiệu của sự cố.
3. Từ Scott Meyers: Tạo giao diện lớp không phải lá hoặc trừu tượng.
4. Ưu tiên thành phần thừa kế.

Answer 4

Kiểm tra Domain-Driven Design: Tackling Complexity in the Heart of Software. Tôi nghĩ rằng nó sẽ trả lời câu hỏi của bạn.

Answer 5

họ nói gì, cộng với nó trông giống như bạn đang mô hình hóa các đối tượng thực tế, vì vậy:

• hạn chế mô hình đối tượng của bạn để phù hợp chính xác các đối tượng thực tế.

Bạn có thể sử dụng thừa kế và thành phần để giảm mã/mô hình, nhưng chỉ theo những cách có ý nghĩa với miền cơ bản.

Ví dụ: Lớp ống có thuộc tính Đường kính sẽ có ý nghĩa, trong khi lớp DiameterizedObject (có thuộc tính Đường kính) có thuộc tính GeometryType của GeometryType.Pipe thì không. Cả hai mô hình có thể được thực hiện để làm việc, nhưng trước đây rõ ràng tương ứng với miền vấn đề, trong khi mô hình thứ hai thực hiện quan điểm nhân tạo (phi thực tế).

Một đầu mối bổ sung: bạn biết bạn đã có mô hình đúng khi bạn thấy mình khám phá các tính năng mới trong mã mà bạn không có kế hoạch ngay từ đầu - chúng chỉ 'tự nhiên' rơi ra khỏi mô hình. Ví dụ, mô hình của bạn có thể có các lớp Pipe và Junction (như bộ điều hợp kết nối) đủ để giải quyết vấn đề ngay lập tức (nói) tham gia các đường kính khác nhau và tính tốc độ dòng chảy, áp suất tối đa và tính toàn vẹn cấu trúc. Sau đó bạn nhận ra rằng vì bạn đã mô hình hóa các đặc tính cấu trúc và kết nối của các đường ống và mối nối chính xác (trong các yêu cầu của miền), bạn cũng có thể tạo đối tượng JungleGym từ các đường ống được kết nối và tính toán chính xác lượng tải cấu trúc sẽ chịu.

Đây là một ví dụ cực đoan, nhưng nó sẽ nhận được điểm qua: các mô hình đối tượng chính xác hỗ trợ phần mở rộng và thường biểu thị các đặc tính và tính năng không mong muốn (không phải lỗi!).

Answer 6

Liskov Substitution Principle, thường được thể hiện dưới dạng "is-a". Nhiều ví dụ về OOP sẽ khấm khá hơn cách sử dụng "có-một" (trong C++ thừa kế riêng hoặc thành phần rõ ràng) chứ không phải là thừa kế công cộng ("is-a")

Bắt Inheritance đúng là cứng. Làm như vậy với các giao diện (các lớp ảo thuần túy) thường dễ dàng hơn các lớp cơ sở/phụ