Tôi là một nhà phát triển lâu năm (tôi 49 tuổi) nhưng khá mới đối với phát triển hướng đối tượng. Tôi đã đọc về OO kể từ Eiffel của Bertrand Meyer, nhưng đã thực hiện rất ít lập trình OO.
Vấn đề là mọi cuốn sách về thiết kế OO đều bắt đầu bằng một ví dụ về thuyền, ô tô hoặc bất kỳ đối tượng phổ biến nào chúng ta sử dụng rất thường xuyên, và họ bắt đầu thêm các thuộc tính và phương thức, và giải thích cách họ mô hình hóa trạng thái của đối tượng và những gì có thể được thực hiện với nó
Vì vậy, họ thường đi một cái gì đó như "mô hình càng tốt thì nó đại diện cho đối tượng trong ứng dụng càng tốt và tất cả đều xuất hiện tốt hơn".
Cho đến nay thì rất tốt, nhưng, mặt khác, tôi đã tìm thấy một số tác giả đưa ra các công thức nấu ăn như một lớp học chỉ phù hợp với một trang duy nhất (Tôi sẽ thêm vào trên kích thước màn hình nào? "Bây giờ chúng tôi không thử để in mã!).
Lấy ví dụ một PurchaseOrderlớp, có một máy trạng thái hữu hạn kiểm soát hành vi của nó và một tập hợp PurchaseOrderItem, một trong những đối số ở đây là chúng ta nên sử dụng một PurchaseOrderlớp đơn giản, với một số phương thức (ít hơn một lớp dữ liệu) và có một PurchaseOrderFSMlớp chuyên gia của người Viking, xử lý bộ máy trạng thái hữu hạn cho PurchaseOrder.
Tôi có thể nói rằng rơi vào Phân loại tính năng Envy Cảnh hoặc Phân loại thân mật không phù hợp của bài viết về mùi của Code của Jeff Atwood trên Mã hóa kinh dị. Tôi chỉ gọi đó là lẽ thường. Nếu tôi có thể phát hành, phê duyệt hoặc hủy bỏ đơn đặt hàng thật của tôi, sau đó các PurchaseOrderlớp nên có issuePO, approvePOvà cancelPOphương pháp.
Có phải điều đó không phù hợp với sự tối đa hóa sự gắn kết và tối thiểu hóa việc ghép nối các nguyên tắc cũ của tuổi mà tôi hiểu là nền tảng của OO?
Bên cạnh đó, điều đó có giúp gì cho khả năng duy trì của lớp không?
PurchaseOrder, bạn chỉ có thể đặt tên cho phương pháp của bạnissue,approvevàcancel. CácPOhậu tố cho biết thêm chỉ giá trị âm.