Nếu bạn có một đồng nghiệp không hiểu lợi ích của Tách biệt mối quan tâm hoặc không hiểu nó đủ để áp dụng nhất quán trong công việc hàng ngày của họ, bạn sẽ giải thích điều đó với họ như thế nào?
Câu trả lời:
Hãy tưởng tượng bạn có một chương trình đã được phát hành. Một khách hàng xuất hiện và đề nghị trả tiền cho bạn để cải tiến một trong những tính năng của nó. Để có được tiền, bạn sẽ cần thay đổi chương trình của mình để thêm tính năng mới. Một số điều sẽ ảnh hưởng đến tỷ suất lợi nhuận của bạn là:
Tách biệt mối quan tâm giúp bạn có được câu trả lời tích cực hơn cho những câu hỏi này.
Nhìn vào một bệnh viện, và suy nghĩ về tất cả các vai trò khác nhau có liên quan đến việc chăm sóc bệnh nhân: y tá, bác sĩ, trợ lý y tế, kỹ thuật viên, nhân viên văn thư, nhà ăn, v.v.
Có ai biết làm thế nào tất cả những người đó hoàn thành công việc của họ không? Không, bởi vì nó sẽ áp đảo. Họ phải tách các trách nhiệm khác nhau thành các vai trò riêng biệt và các điểm tiếp xúc giữa các vai trò đó rất cụ thể.
Nếu anh ấy / cô ấy làm việc trong một văn phòng, hãy lấy nó làm ví dụ, giải thích vai trò của từng nhân viên trong văn phòng đó và hỏi anh ấy, chuyện gì sẽ xảy ra, nếu những nhân viên đó không chia theo công việc của họ?
Tôi sẽ xem xét cách anh ta thất bại trong việc áp dụng SoC trong mã / thiết kế của mình và biến điều đó thành một ví dụ thực tế mà anh ta có thể liên quan và điều đó rõ ràng là không mong muốn.
Ví dụ: nếu anh ta có một lớp mà khách hàng cần cung cấp một số thông tin không phù hợp với những khách hàng đó, thì tôi sẽ sử dụng sự tương tự của một tiệm bánh nơi bạn phải mang theo ngũ cốc và men của riêng mình nếu bạn muốn mua một cái bánh mì
Một ví dụ có thể là nhà phát triển html có thể muốn tách html, css và javascript thành các tệp riêng biệt. Bằng cách này, bạn có thể thay đổi giao diện của một cái gì đó bằng cách sửa đổi css hoặc hành vi của một cái gì đó bằng cách thay đổi tệp javascript được tải riêng. Nếu bạn có một trang web đáp ứng hoặc thích ứng, mô hình này hoạt động tốt vì bạn có thể tải các css hoặc javascript khác nhau tùy thuộc vào chế độ xem người dùng hoặc tác nhân người dùng. Tuy nhiên, nếu bạn sửa đổi html hoặc mẫu, rất có thể css hoặc javascript có thể bị hỏng. Những mối quan tâm riêng biệt cũng có thể phụ thuộc.
Một cách tiếp cận khác là gói tất cả javascript và html css của bạn vào một nhóm các thành phần hoặc mô-đun. Điều này có nghĩa là bạn có thể thay đổi một mô-đun và nó sẽ không ảnh hưởng đến các thành phần hoặc mô-đun khác trên trang mà nó chạy dọc theo đó không liên quan. Ở đây các tập tin css, js và html được hợp nhất thành một thành phần duy nhất có thể được kiểm tra đơn vị. Vì vậy, việc phân tách các mối quan tâm đến dưới dạng các thành phần nguyên tử riêng lẻ có thể được kiểm tra đơn vị thay vì tách các yếu tố đánh dấu, kiểu dáng và hành vi. Cách tiếp cận thứ hai này phù hợp hơn để tạo các ứng dụng web phức tạp hơn.
chỉnh sửa. Vì tôi đã nhận được phản hồi tiêu cực cho nhận xét này, tôi nghĩ rằng tôi sẽ xem lại nó và cố gắng để đủ điều kiện một số POV của tôi. Thật không may, bất kỳ phản hồi nào ở đây không đặc biệt mang tính xây dựng nhưng tôi đã thấy một cuộc thảo luận thú vị ở nơi khác nhìn vào React, công nghệ nóng hiện tại trong phát triển web, một ví dụ trong thế giới thực và hỏi liệu nó có phá vỡ mối quan tâm hay cụ thể là nếu nó phá vỡ một trong những nguyên lý của phương pháp thiết kế hướng đối tượng RẮN của Feather.
Phối cảnh nhà phát triển JavaScript kỹ thuật
NO, because JSX is a view language. That's one responsibility.
BUT, this implies that the JS developer is self-enforcing SoC/SRP on his own architecture by not mixing ViewModel concerns in his JSX. This type of vigilance "in the wild" is highly suspect because JSX involves the full JavaScript dialect.
Phối cảnh thiết kế UX / UI
YES, because JSX mixes Semantic Content (Model) with Behavior (Controller)
YES, because the intrusion, specifically of JavaScript, into the Semantic Model makes it difficult or impossible for me to play my role and leverage my expertese and skills.
Quan điểm của đội
NO, if both...
Separate files are used for the View (JSX) and ViewModel (JS).
Either there aren't UI/UX/Designers involved, or they are productive working directly with JSX (not very common).
YES, if either...
Everything is in the same file, causing problems for version control or productive use of modern editors.
Members of the team who are comfortable with HTML/CSS but less capable with JavaScript are excluded because of mixture or roles.
Ngoài ra trên trang còn có liên kết đến một bài thuyết trình thú vị từ Pete Hunt, của Facebook, nơi anh nói về các thành phần không phải là mẫu và tách biệt các mối quan tâm trong ứng dụng ngôn ngữ thay vì tách biệt các mối quan tâm của khung, ví dụ như mẫu, css và javascript v.v.
Liên quan đến việc tách các mối quan tâm của bạn bằng ngôn ngữ của ứng dụng của bạn, điều này có thể liên quan đến việc sử dụng các mẫu khác nhau để tách hoặc tách mã của bạn thành dạng mô-đun có thể được kiểm tra đơn vị, v.v.
Vì vậy, để tóm tắt, tách biệt mối quan tâm có thể phụ thuộc vào vai trò hoặc quan điểm của bạn, như đã đề cập ở nơi khác.