Mọi đối tượng nên biết cách trình bày / vẽ chính mình?

David West trong cuốn sách Tư duy đối tượng (chương 10, phần 1, tiểu mục 2) đã đề xuất rằng trong một môi trường OO lý tưởng, mọi đối tượng nên có khả năng trình bày theo yêu cầu; có thể là con người (dưới dạng GUI), các thành phần không phải là nguồn gốc (như JSON và / hoặc XML) hoặc bất kỳ bên nào quan tâm khác:

Suy nghĩ đối tượng nói rằng một khung nhìn (đôi khi được gọi là một giao diện), hay còn gọi là cách khác là một phương tiện để một đối tượng giao tiếp với một đối tượng khác và không có gì khác. Nhu cầu về chế độ xem xuất hiện khi một đối tượng cần thể hiện chính nó dưới dạng một người không phải là người bản địa của một nhóm đối với một đối tượng khác (thường là con người) hoặc ứng dụng (ví dụ: chế độ xem XML cho các đối tượng dữ liệu được chia sẻ trên các nền tảng).

Khám phá về nhu cầu và các tham số phải được thỏa mãn bởi một khung nhìn được biểu hiện trong các tình huống mà đối tượng tham gia. Bất cứ khi nào một đối tượng được yêu cầu hiển thị chính nó, nó phải sử dụng chế độ xem một biểu tượng phù hợp cho người gửi tin nhắn hiển thị đó. Ví dụ, nếu một đối tượng đang cố gắng tự khởi tạo (lấy một giá trị cho chính nó), thì nó phải đưa ra một quan điểm về chính nó như một yêu cầu ngầm đối với một con người (hoặc đối tượng cung cấp dịch vụ khác) cho một giá trị. Nếu chúng ta đang xây dựng một GUI sẽ đóng vai trò trung gian giữa một đối tượng phần mềm và đối tượng người, chúng ta sẽ sử dụng glyphs cho mục đích hiển thị và các widget cho mục đích tương tác.

Nhưng glyphs và widget nào cần được đưa vào GUI? Chỉ những người cần thiết để hoàn thành kịch bản hoặc kịch bản 4 quan tâm ngay lập tức khi ứng dụng chạy. Viễn cảnh này là phản trực giác đối với hầu hết các nhà phát triển vì nó gợi ý rằng GUI được xác định từ ứng dụng.

Ví dụ, xem xét một nhà máy bia. Tắt sang một bên là những thùng đầy bia. Tại một dây chuyền sản xuất phức tạp bao gồm máy rửa chai, trạm nạp, máy đóng nắp và máy lắp ráp gói. Trên hết là một trạm điều khiển giám sát nhà máy bia và thông báo cho các nhà quản lý con người về tình trạng và vấn đề. Các nhà phát triển truyền thống có khả năng bắt đầu phân tích và thiết kế hệ thống quản lý nhà máy bia của họ theo quan điểm của bảng điều khiển. Điều này tương tự như thiết kế từ giao diện trong.

Thay vào đó, tư duy đối tượng sẽ đề xuất rằng bạn xem xét đối tượng nào là khách hàng chính của nhà máy bia và tất cả các máy móc của nó. Nhân danh thiết bị phức tạp tồn tại thay mặt cho ai? Tất nhiên, câu trả lời đúng cho doanh nghiệp là khách hàng. Nhưng một câu trả lời phản ánh rõ hơn về suy nghĩ của đối tượng là, Bia. Tất cả các kịch bản được viết từ quan điểm của bia, cố gắng tự chui vào một cái chai, có nắp, được đặt trong một gói, và cư trú trong một chiếc xe tải. Bảng điều khiển là một người quan sát thụ động 5 về tình trạng của nhà máy bia. Nếu bia gặp phải sự cố tại một số điểm, thì trách nhiệm của bia là yêu cầu sự can thiệp của người vận hành con người bằng cách gửi tin nhắn đến bảng điều khiển (hoặc bảng điều khiển dành riêng cho máy) yêu cầu dịch vụ can thiệp.

Phối cảnh này sẽ đơn giản hóa thiết kế GUI và quan trọng hơn là loại bỏ máy chủ của các đối tượng trình quản lý và trình điều khiển dường như phát sinh chắc chắn khi thiết kế từ phối cảnh của bảng điều khiển (GUI).

Đến từ một người mới bắt đầu trong thế giới OO: điều này thực sự có nên xảy ra không?

Có những đối tượng biết cách tự đại diện chắc chắn có thể giảm số lượng đối tượng điều khiển / quản lý mà West liên tục nói trong cuốn sách của mình, một Nhà tư tưởng đối tượng được cho là nên cố gắng tránh bằng mọi giá. Nhưng sẽ không tuân thủ "quy tắc" này phá vỡ SRP ?

Ngoài ra (nếu nó trở thành trường hợp), được đưa ra một triển khai điển hình trong một ứng dụng Android: Làm thế nào một người có thể đạt được loại mục tiêu này? Có phải mọi đối tượng chúng ta tạo ra đều biết cách thể hiện bản thân như một View?

Tôi nghĩ rằng đây là một trong những điều khó hiểu nhất về thiết kế OO và thành thật mà nói, tôi nghĩ rằng rất nhiều tác giả đã sai về nó và / hoặc không giải thích nó rất tốt. Rất nhiều người mắc phải sai lầm này và không bao giờ thực sự hiểu được. Hãy lấy một ví dụ không dựa trên GUI nhưng gặp phải một cạm bẫy tương tự.

Trong Java, mọi đối tượng đều có phương thức bằng. Sau đó, bạn có các loại bộ sưu tập như tập hợp và bản đồ phụ thuộc vào phương thức này để xác định khi nào các đối tượng sẽ được thêm vào bộ sưu tập hoặc khi chúng trùng lặp. Điều này có vẻ như OO tốt cho rất nhiều người. Vấn đề là những gì bạn kết thúc là một đối tượng (bộ sưu tập) có hành vi không được xác định bởi nó mà bởi các đối tượng mà nó chứa. Điều này hơi giống với việc đưa hành khách đi xe buýt trực tiếp đến nơi cần đến. Nếu họ không đồng ý thì sao? Đây không phải là một vấn đề lý thuyết, nó thực sự là một vấn đề nhức nhối khi bạn về cơ bản phải phá vỡ sự kế thừa để ngăn chặn các lỗi trong chương trình của bạn. Lấy một hình dạng và một màu sắc. Là một hình vuông 2x2 bằng với một hình vuông màu xanh 2x2? Shape nói 'có' và ColoringShape nói 'không'. WHO' phải không Câu trả lời phụ thuộc vào những gì bạn muốn xảy ra trong bộ sưu tập của bạn. Nó có thể không phụ thuộc vào những gì bạn đang cố gắng làm.

Bạn sẽ thấy điều này xuất hiện như một vấn đề hết lần này đến lần khác. Điều buồn cười là có một giải pháp và nó ở ngay bên cạnh tại So sánh. Các đối tượng triển khai so sánh có cùng câu hỏi hóc búa này nhưng bây giờ chúng không chỉ xác định xem chúng có bằng nhau không mà còn lớn hơn đối tượng khác hay không. Nó thực sự khó hiểu bên ngoài phạm vi sử dụng rất hẹp. Vì vậy, chúng ta có một thứ khác gọi là So sánh. Công việc của chúng ta là nhìn vào hai vật thể và cho biết bộ sưu tập cái nào lớn hơn. Tất cả các vấn đề mà bạn đã cố gắng thực hiện trong đối tượng So sánh sẽ biến mất.

Tôi không biết cuốn sách này và tôi không biết tác giả nhưng ví dụ với bia có vẻ không hữu ích chút nào. Làm thế nào để bia biết liệu nó nên được trong một chai hoặc trong một thùng và tại sao nó sẽ được đưa ra quyết định? Công việc là thưởng thức hương vị và đưa rượu vào máu của người dùng. Chúng ta có thực sự nghĩ rằng nhà máy bia làm việc theo cách này? "OK bia, bạn nên ở trong một chai hoặc trong một thùng và nếu đó là một chai, nó nên là một chai 25 ounce hoặc một chai 12 ounce?" Bia gì trong trường hợp này (không có ý định chơi chữ) nào? Có phải là một giọt bia? Có thể điều này nằm ngoài ngữ cảnh nhưng tôi nghĩ điều này đã sai hoặc ít nhất là nó không thêm bất kỳ sự chiếu sáng nào vào khái niệm này.

Như đã nói, có một cách tiếp cận để xây dựng các giao diện mà tôi đã sử dụng có thể đơn giản hóa mọi thứ và làm cho nó trở nên OO hơn. Về cơ bản, bạn tạo một giao diện xác định các hành động trừu tượng mà bạn có thể thực hiện để hiển thị đối tượng. Bạn có thể có một giao diện được gọi là Displaycác phương thức như setTitlehoặc setDescriptionnếu bạn đang sử dụng mẫu đặt tên Java tiêu chuẩn. Sau đó, đối tượng của bạn sẽ có một phương thứcdisplay(Display display)(bởi vì ba lần là sự quyến rũ!) Trong cách tiếp cận này, đối tượng không cần hiểu giao diện là gì, nó có thể là văn bản, nhị phân, svg, bitmap, bất cứ điều gì và giao diện không cần biết về đối tượng . Theo cách này, một đối tượng có thể "hiển thị chính nó" mà không cần biết về cách hoạt động của màn hình. Cách tiếp cận này có thể làm giảm đáng kể số lượng các lớp bao bọc cần thiết nhưng nó có thể cồng kềnh nếu bạn có các yêu cầu hiển thị phức tạp khác nhau tùy theo đối tượng. Bạn có thể kết hợp nó với các cách tiếp cận kiểu MVC tiêu chuẩn để có hiệu quả tốt.

Nguyên tắc trách nhiệm duy nhất không có nghĩa là một lớp chỉ làm một việc. Nó có nghĩa là một lớp có một lý do duy nhất để thay đổi.

Có lẽ bạn đang nghĩ về một phương pháp , mà thực sự chỉ làm một việc.

Theo kết luận hợp lý, phiên bản SRP của bạn có nghĩa là bạn sẽ không bao giờ có thể đăng nhập bất cứ điều gì, vì đăng nhập là một trách nhiệm riêng biệt.

Tốt hơn nên nghĩ về một lớp học như là một chủ đề duy nhất, được xác định rõ . Bạn có thể có một số phương pháp hỗ trợ chủ đề đó và tất cả chúng có thể làm những việc khác nhau.

Phương thức "hiển thị tôi" cơ bản nhất là ToString, luôn luôn là một phương thức trên đối tượng.

Tất cả những gì đã nói, khi chúng tôi tạo UI, chúng tôi thường khuyến khích Tách mối quan tâm bằng cách cung cấp các đối tượng có mục đích duy nhất là hiển thị dữ liệu từ các đối tượng khác (ví dụ: Lượt xem).

Có lẽ một ví dụ là theo thứ tự. Hãy xem xét một trang web PHP, sử dụng View. Một cái nhìn đơn giản có thể trông như thế này:

<?php
class View
{
    private $model;
    private $controller;

    public function __construct($controller,$model) {
        $this->controller = $controller;
        $this->model = $model;
    }

    public function output(){
        return "<p>" . $this->model->string . "</p>";
    }
}

Trong PHP, View luôn chứa một output()hàm. Để có được đại diện trực quan của chế độ xem, tất cả những gì bạn phải làm là gọi output()và bạn sẽ nhận được một chuỗi phù hợp để hiển thị trong bất kỳ trình duyệt hiện đại nào.

Nếu bạn sẽ chú ý, View sẽ tham chiếu một đối tượng được gọi model. Đây là đối tượng chứa dữ liệu thực tế. Khung nhìn và Mô hình nằm trong các đối tượng riêng biệt; đây là những gì thiết lập sự tách biệt mối quan tâm.

Tách các mối quan tâm là rất quan trọng đối với các trang web, bởi vì đó là những gì cho phép một nhà thiết kế làm việc trên một thiết kế trang web ngoài các lập trình viên.

Đọc thêm
Mô hình MVC và PHP

Đánh giá từ các trích dẫn bạn đã dán, bạn đang hiểu sai văn bản.

Tác giả không nói rằng mọi đối tượng sẽ có thể tự trình bày trong một giao diện người dùng. Điều này là không thể, vì một đối tượng không thể biết nó sẽ được hiển thị trong giao diện người dùng nào (trong ứng dụng WinForms, ứng dụng linux sử dụng XServer, dưới dạng chuỗi JSON, dưới dạng XML, dưới dạng hình ảnh PNG, v.v.).

Vấn đề được đưa ra là bạn nên viết các khung nhìn chuyên biệt với trách nhiệm duy nhất là hiển thị một thực thể nhất định. Ví dụ, bạn có thể viết một khung nhìn hiển thị một đối tượng dưới dạng HTML (như được thực hiện bởi các khung nhìn trong các ứng dụng MVC). Bạn có thể tạo một bộ tuần tự hóa JSON có thể biến một đối tượng thành một chuỗi JSON. Bạn có thể tạo một đối tượng biến các loại đối tượng khác thành báo cáo PDF. Tất cả phụ thuộc vào.

Vấn đề là, tách thực thể kinh doanh khỏi đại diện trực quan (hoặc nối tiếp). Chúng là những thứ khác nhau và thay đổi vì những lý do khác nhau.