10 điều mọi nhà phát triển ứng dụng Android nên biết về kiến trúc Architecture
Người dịch: Dương Đình Tuấn Architecture trong hướng đối tượng cho ứng dụng có thể được mô tả đơn giản là cách sắp xếp các lớp trong hệ thống và cách thức chúng giao tiếp với nhau. Chúng ta tìm thấy cái nhìn tổng quan về vai trò và nhiệm vụ của các lớp này trong khi tạo ra chúng. ...
Người dịch: Dương Đình Tuấn
Architecture trong hướng đối tượng cho ứng dụng có thể được mô tả đơn giản là cách sắp xếp các lớp trong hệ thống và cách thức chúng giao tiếp với nhau. Chúng ta tìm thấy cái nhìn tổng quan về vai trò và nhiệm vụ của các lớp này trong khi tạo ra chúng.
Dưới đây là một số điều có thể giúp chúng ta hiểu về kiến trúc này:
- Architecture là ngôn ngữ và là nền tảng bất khả tri: Architecture dựa trên các nguyên tắc lập trình. Những nguyên tắc hướng dẫn này có thể là nguyên tắc SOLID hoặc các mẫu thiết kế / architecture ổn định và architecture có thể được áp dụng trên các ngôn ngữ và nền tảng. Nên đầu tư thời gian vào architecture. Nó không chỉ giúp chúng ta thiết kế architecture tốt hơn mà còn cải thiện kỹ năng coding.
- Sự mơ hồ về MVP / MVVM: Nhiệm vụ của MVP (Model-View-Presenter) / MVVM (Model-View-ViewModel) là tách UI khỏi code. Chúng ta sử dụng Presenter / ViewModel để loại bỏ hết code logic ra khỏi View (Activity/Fragment). Việc phân tách này liên quan đến VP / VVM nhằm tách ra Model (M), M có nhiệm vụ cung cấp dữ liệu tới Presenter / ViewModel.
Những gì tôi thường thấy là Presenter và ViewModel được implement một cách chuẩn với các interface và observer nhưng ngoài ra nó còn khá rối. Tôi nghĩ rằng điều này có thể đổ lỗi cho việc sử dụng VP / VVM cho toàn bộ architecture của một ứng dụng và không thể định hình được Model (M). MVP / MVVM đóng một vai trò quan trọng như một mẫu kiến trúc nhưng kiến trúc của một ứng dụng vượt xa sự phân tách UI.
- Architecture rất quan trọng nhưng không cần thiết: Việc học Architecture đến ở giai đoạn sau trong quá trình phát triển của một dev Android. Một trong những lý do là các ứng dụng của chúng ta có thể hoạt động tốt hơn ngay cả khi không có architecture nào, vậy tại sao phải mất thêm thời gian? Làm thế nào chúng ta sẽ thuyết phục sếp / khách hàng của mình rằng cần thêm thời gian để chúng ta dành cho việc này và có thể không có bất kỳ lợi ích nào ngay lập tức?
Chỉ sau một vài phiên bản, chúng tôi nhận ra sự lộn xộn nhưng sau đó đã quá muộn. Khi chúng ta tiếp tục gặp rắc rối hết lần này đến lần khác, chúng ta mới bắt đầu hiểu được sự cần thiết của architecture.
- Architecture cải thiện khả năng thay đổi: Architecture sẽ rất quan trọng nếu chỉ có một phiên bản được phát hành cho ứng dụng. Trong thực tế, đây là cách tiếp cận mà nhiều người trong chúng ta thực hiện, đó là điều thiển cận khi phát triển ứng dụng.
Nếu tôi phải chỉ ra lợi ích lớn nhất của việc có một Architecture phù hợp thì đó sẽ là sự dễ dàng sửa đổi và hiệu quả của nó mang lại.
Sự thật là chúng ta không thể thấy trước mọi thứ mà ứng dụng có thể phát triển trong tương lai nhưng một Architecture tốt có đủ sự linh hoạt để điều chỉnh theo những thay đổi chưa biết này đấy.
- Architecture không đòi hỏi kiến thức đặc biệt: Đối với một dev giỏi, thiết kế Architecture xuất hiện một cách tự nhiên. Điều này hơi liên quan ở luận điểm #1 nhưng nó rất quan trọng vì vậy tôi nghĩ nên sửa nó một chút và trình bày lại