Tại sao nó được coi là một cách thực hành tốt nhất để đóng gói mã chương trình và mã giao diện đồ họa trong các lớp khác nhau?

Vì vậy, giáo viên của tôi nói với tôi rằng điều rất quan trọng là không gói gọn mã chương trình và mã giao diện đồ họa trong cùng một lớp, nhưng để giữ chúng hoàn toàn độc lập. Tôi hiện đang viết một trò chơi iphone với một lưới trong đó. với tôi nó có ý nghĩa hơn nhiều khi tạo cả lưới đồ họa và mã kỹ thuật trong cùng một lớp "Lưới". Lập trình viên khác sẽ nhăn mặt vì điều này? Có thực sự rất quan trọng để giữ cho giao diện đồ họa và mã độc lập. Vấn đề gì sẽ phát sinh nếu tôi không?

Cảm ơn bạn!

EDIT: cảm ơn các bạn! Tôi có thể viết ra dự án trước và sau đó sao chép mã xung quanh để tạo thành sự tách biệt giữa thiết kế. Tôi biết rằng điều này hoàn toàn có thể đánh bại mục đích, nhưng cũng giống như thực tế ... Vậy lần sau tôi có thể áp dụng mẫu thiết kế này từ đầu không?

Khái niệm mà giáo viên của bạn đang đề cập đến là một cái gì đó gọi là Tách biệt các mối quan tâm.

Để minh họa nó trong ngữ cảnh của bạn, nếu bạn hoàn thành chương trình của mình và sau đó quyết định bạn muốn chuyển nó sang Android; bạn sẽ phải viết lại nhiều mã hơn nếu bạn giữ logic lưới riêng biệt.

Một điều khiển giao diện chỉ nên quan tâm đến việc vẽ những gì nó đã nói, logic lưới chỉ nên quan tâm đến những gì trong lưới chứ không phải làm thế nào để vẽ nó.

Không giúp đỡ à ?

Để làm cho nó dễ dàng hơn để thay đổi mã của bạn . Điều gì sẽ xảy ra nếu ngày mai bạn không muốn sử dụng lưới nhưng một danh sách? Khi GUI của bạn được tách ra khỏi logic của bạn, điều đó thật dễ dàng.

Bên cạnh đó, bạn sẽ viết mã có thể tái sử dụng nhiều hơn . Nếu GUI của bạn không chứa mã kỹ thuật, bạn cũng có thể sử dụng lại nó. Tạo một lưới ưa thích với tất cả các tùy chọn một lần và bạn có thể sử dụng nó trong các dự án khác. Trộn GUI và mã kỹ thuật của bạn sẽ ngăn bạn làm điều này.

Nó cũng cung cấp cho bạn mã dễ đọc hơn. Nếu lưới của bạn chỉ thực hiện chức năng GUI, việc hiểu hoặc thay đổi mã của bạn sẽ dễ dàng hơn .

Cách tiếp cận chung của lập trình hướng đối tượng đến một sự tách biệt các mối quan tâm , trong đó mã được tách thành các nhiệm vụ logic. Ban đầu, điều này có vẻ như nhiều công việc hơn. Nhưng khi dự án của bạn phát triển, nó giúp việc theo dõi và quản lý mã của bạn dễ dàng hơn.

Vì lý do đó, tốt hơn là nên tách mã chịu trách nhiệm hiển thị lưới và mã liên quan đến dữ liệu có thể được hiển thị trong lưới đó.

Khi Phân tách mối quan tâm được áp dụng cho cấu trúc ứng dụng, kết quả là kiến trúc nhiều tầng (hoặc kiến trúc N-Tier) http://en.wikipedia.org/wiki/Multitier_arch architecture .

Để xây dựng các câu trả lời khác và đưa ra một ví dụ, bằng cách nào đó bạn nên cho phép bản thân đưa logic / dữ liệu của bạn vào lưới hoặc ngược lại.

Kiểm soát lưới của bạn có thể phơi bày một Renderphương pháp hoặc một DataBindphương pháp.

class GridControl
{
    public Render(GridData data) { ... }
}

hoặc là

class GridControl
{
    public DataBind(GridData data) { ... }
}

Sau đó, đơn vị logic của bạn có thể lấy GridControl và liên kết một đối tượng dữ liệu với nó hoặc gọi thủ công kết xuất với đối tượng dữ liệu mỗi khi có bất cứ điều gì thay đổi.

GridLogic của bạn cũng nên có một tham chiếu đến GridControl để nó có thể liên kết với bất kỳ đầu vào / sự kiện nào xảy ra.

Ý tưởng đằng sau ràng buộc dữ liệu là điều khiển lưới của bạn theo dõi dữ liệu cho bất kỳ thay đổi nào và tự hiển thị lại khi hiển thị chức năng kết xuất nghĩa là đơn vị logic của bạn sẽ hiển thị lại điều khiển theo cách thủ công.

Dù bằng cách phân tách logic của bạn và chia lưới như thế này cho phép bạn dễ dàng thay đổi một trong những cách khác mà không phá vỡ bất cứ điều gì. Bạn cũng có thể viết một điều khiển mới như ListControlđể hiển thị dữ liệu của bạn dưới dạng danh sách thay vì lưới mà không phải viết lại tất cả logic của bạn.

Tôi thực sự khuyên bạn nên xem kiến trúc MVC .

Đó là một sàng lọc của khái niệm bạn đã đề cập (phân tách mã chương trình và giao diện đồ họa). MVC là viết tắt của Model-View-Controller. Ở đây Model là dữ liệu, View là mã giao diện đồ họa và COntoder là mã xử lý dữ liệu.

Bằng cách này, bạn đã tạo ra ba phần của chương trình của bạn. Mỗi phần có thể được thay thế mà không yêu cầu thay đổi trong hai phần khác.

Nó phụ thuộc vào các loại thay đổi trong tương lai bạn có thể mong đợi xảy ra. Những gì bạn muốn giảm thiểu là số lượng thay đổi mã thủ công cần thiết để thực hiện chính xác từng thay đổi chức năng.

Trường hợp MVC thắng là nếu các thay đổi được giới hạn ở phần V hoặc "Xem".

Theo kinh nghiệm của tôi, nhiều khả năng các thay đổi ảnh hưởng đến cả ba phần, vì vậy sẽ tốt hơn nếu chúng không bị tách rời. Để thể hiện điều tôi muốn nói, từ lâu tôi đã sử dụng một kỹ thuật mà tôi đã phát triển được gọi là Hộp thoại động , trong đó một yêu cầu mới, chẳng hạn như "cho phép người dùng chỉnh sửa tên và khi hoàn thành XYZ" được nhập vào mã nguồn dưới dạng một khối duy nhất bản văn:

if(deTextEdit(&sName)){
  // do XYZ
}

thay vì nhiều chỉnh sửa riêng biệt, để xác định rằng trường chỉnh sửa tồn tại, tạo một mã định danh duy nhất cho nó, để liên kết nó với biến mô hình và liên kết nó với trình xử lý sự kiện tiêu điểm bị mất.

Nếu bạn đi đến liên kết đó, bạn sẽ thấy một ví dụ phức tạp hơn.

Về cơ bản, ý tưởng là biến mã thành một ngôn ngữ cụ thể của miền, để giảm thiểu số lần chỉnh sửa để thực hiện mục đích. Lý do bạn muốn làm điều đó không chỉ để giảm nỗ lực mà còn giảm cơ hội giới thiệu các lỗi, bằng cách quên hoặc mã hóa sai một hoặc nhiều chỉnh sửa. Nó cũng làm giảm kích thước của mã nguồn khoảng một bậc độ lớn.

Nó không miễn phí. Nó giới thiệu một đường cong học tập một lần cho các lập trình viên.

Giao diện đồ họa phụ thuộc vào sytem, ​​trong khi lõi trò chơi là một thuật toán hoàn toàn độc lập với hệ thống mà nó chạy. Giữ hai appart sẽ giúp chương trình dễ bảo trì, kiểm tra và gỡ lỗi hơn vì các thay đổi trong một hệ thống con không ảnh hưởng đến cách thức hoạt động của các hệ thống khác. Ngay cả khi bạn không quan tâm đến tính di động, tôi cá là bạn quan tâm đến mạnh mẽ và khả năng duy trì chương trình của bạn.