Design Patterns là gì
Lập trình cũng là một phong cách sống không phải công việc thông thường. Các hiphoper hay các rapper tạo phong cách riêng của họ mà mọi người nhìn thấy. Còn các developer thực thụ cũng tạo ra nhưng style của riêng mình trên từng dòng code, apps mà thậm trí cả những comments. Họ nghĩ về công việc của mình 24/7, làm sao để mang lại những ý tưởng từ thực tế thành các application.
Việc phát triển các ứng dụng mà nhiều developer luôn bị ám ảnh bởi các task, deadline, communication không nên chút nào. Thực tế thì application là cách mà developer khoác lên application các properties và các behavior từ thế giới thực. Sau khi đã có cái mình muốn và run thành công, thì bước tiếp theo developer tìm cách nào đó để tái xử dụng, tối ưu cũng như giảm thiểu chi phí cho applicaiton. Những cách mà developer đó tìm ra để tái xử dụng trong chương trình, đoạn mã đó là Design Pattern.
Sau khi ra trường, phỏng vấn đầu tiên được hỏi là “em biết design pattern” và “xem anh đoạn mã sau là design pattern nào”, đến đi làm vài năm rồi nghĩ lại vẫn còn nhớ chứ, first kiss của em còn chẳng nhớ, nhưng em vẫn nhớ mấy câu này.
Mình giới thiệu lại design pattern để mọi người biết khái niệm này còn thực tế nếu bạn dùng framework hay code chay đi nữa cũng sẽ không đủ thời gian mà triển khai. Nguồn gốc hay thời gian xuất xứ của khái niệm này , mời bạn google.com “design pattern by eric gamma”.
Lợi ích của các design pattern mang lại, bạn phải làm nhiều và thực hành luôn sau series hoặc nhìn lại tổng thể dự án của mình xem đã dùng cái nào rồi.
- Dễ bảo trì
- Dễ đọc code hơn
- Dễ tìm giải pháp
- Dễ dàng xác định các đối tượng
- Dễ dàng triển khai dự án lớn
- Dễ dàng tái xử dụng
Trên thực tế chúng ta vẫn đang áp dụng những pattern cho cuộc sống mà chư biết khái niệm là gì. Ví dụ, ổ cắm điện phổ thông là 2 chân, nhưng phích cắm thì tồn tại cả 3 chân và 2 chân vậy làm thế nào, dùng ổ chuyển hoặc phích cắm chuyển , ,nói vui thấy mấy tay kỹ thuật viên thường bẻ luôn chân thứ 3 để cám vào ổ 2 chân còn ổ 3 chân vẫn cắm 2 chân bình thường.
Một design pattern phải thoả mãn những tiêu trí sau :
- Tên: Miêu tả rõ vấn đề nó xử lý
- Vấn đề: Miêu vấn đề gặp phải
- Giải pháp : Miêu tả chi tiết các thành phần, các mối quan hệ, khả năng đáp ứng và tính hợp tác trong giải quyết vấn đề
- Kết quả: Chi tiết rõ kết quả sau khi áp dụng pattern
Cũng không nên đâu đầu để nhớ hết các tiêu trí đó, vì chúng ta chỉ đi tìm hiểu những pattern có sẵn và số lượng nhỏ trong Laravel.
Dựa và các tiêu trí trên thì với quá nhiều pattern ta sẽ phải làm sao ? Sẽ có group cho các pattern:
- Creational patterns
- Structural patterns
- Behavioral patterns
MVC là gì
Là mô hình 3 lớp được nhắc đầu tiên vào năm 1988 tại Smalltalk-80 (năm sinh của mình). Cấu trúc của MVC xử dụng trong công nghệ phần mềm, ý tưởng là chia việc xử lý logic ứng dụng thành các phần khác nhau, cụ thể là 3 phần M(model),V(view),C(controller). Nếu biết về OOP rồi thì nắm bắt MVC sẽ dễ dàng hơn, nâng cao lên các mô hình MVVM hay HMVC sẽ không quá khó, google tiếp “ MVC structure”, để ý hình ảnh nào tượng trưng cho MVC mà có mũi tên 2 chiều thì bỏ qua. Cuộc đời nở hoa.
- View chỉ hiển thị dữ liệu mà user yêu cầu
- Controller điều hướng xem cần lấy thông tin từ Model nào
- MVC dễ dàng mở rộng các mẫu View khác nhau : API, WebView
- MVC trong Laravel
Mục đích của Model cơ bản:
- Lấy dữ liệu từ phần quản lý database driver
- Kiểm tra dữ liệu
- Lưu dữ liệu
- Xoá dữ liệu
- Toạ các relationship
- Tương tác với service thứ 3
- Xử lý cache và session
Laravel có 2 lớp để xử lý điều này : Fluent Query Builder( ví dụ DB::table(‘users’)->all()) và Eloquent ORM( ví dụ User::all()).
Design Pattern trong Laravel
1. Builder (Manager) pattern
Mục đích
Đây là loại design pattern thuộc creational pattern.
Chia nhỏ việc xây dựng các đối tượng phức tạp thành các đối tượng đơn giản hơn tuỳ theo mục đích.
Vấn đề
Application là tổ hợp của các thành phần phức tạp. Trong mỗi thành phần được xây dựng tuỳ theo mục đích khác nhau mà ta không biết nõ gồm cái gì.
Thảo luận
Việc convert một dữ liệu từ dạng này sang dạng khác cũng là một ví dụ nên nhắc đến, phần mềm convert, convert data primary chẳng hạn. Lớp Builder Convert sẽ chỉ xác định được các action cơ bản mà một Convert phải làm, nhưng tuỳ theo dữ liệu mà mỗi đối tượng sẽ làm việc khác nhau.
Cấu trúc
Thí dụ
Trong Application Laravel, mở file vendor/Illuminate/Support/Manager.php và lớp con builder của nó vendor/Illuminate/Auth/AuthManager.php. Hoặc một số repository mà tôi xây dựng cũng theo pattern này, tôi xây dựng các action trên base respository như:get, with, filter rồi các respository cho model base, model service, model transaction kế thừa sau đó tôi sẽ xây dựng các logic cho phù hợp với yêu cầu bài toán mà không làm mất tính tổng thể.
2. Factory pattern
Đây là một cái tên chung cho một số pattern : Abstract Factory, Factory Method.
Mục đích
Không giống như các design pattern khác và trong cả Laravel cũng vậy, Factory hiểu theo nghĩa là chỉnh sửa hay customizable nhiều hơn.
Vấn đề
Mỗi framework cũng như thực tế cũng thế, chính chúng ta cũng vậy , cần xây dựng cấu trúc riêng cho framework những cũng muốn cho người khác thay đổi theo mục đích của riêng họ mà không làm mất đi cấu trúc chung.
Thảo luận
Trong Framework hoặc application thường xảy ra trường hợp như sau : Một CMS chỉ cho ta content type cơ bản để tạo post, nhưng yêu cầu dự án thì trong một bài post đó phải có video, shopping card, điều này gây không ít khó khăn cho người mới tiếp cận. Cách giải quyết tạo một content type kế thừa từ content type gốc nhưng mở rộng thêm việc thêm datatype cho nó, bạn sẽ thấy nhiều bài post trở thành shopping card, video gallery chứ không phải thêm field type cho content type đó.
Cấu trúc
Ví dụ
Laravel có nhiều rules để validation với lớp Validation. Khi phát triển ứng dụng, chúng ta thường validate data chúng ta cần. Để làm điều này chúng ta xác định các rule đó trong controller. Nhưng một vài rule chúng ta cần thay đổi rule hoặc message cho phù hợp. Mở file "lluminate\Validation\Factory.php" bạn sẽ thấy có function addExtentions(), phương thức này sẽ định nghĩa những mở rộng cần thiết để tạo lên một Validor mở rộng mới. Nếu không làm việc với Laravel thì có thể theo cấu trúc trên để tạo các class mở rộng cho linh hoạt.
3. Repository pattern
Mục đích
Repository thường được xử dụng để liên lạc giữa 2 lớp (lớp xử lý logic và lớp lưu trữ dữ liệu) duy nhất của ứng dụng.
Vấn đề
Có nhưng logic trong yêu cầu cần tương tác giữa nhiều đối tượng khác nhau, cách cũ vẫn mà tôi thường thấy là : xử lý logic các đối tượng đó ngay trong Controller hoặc Model để đạt được kết quả mong muốn. Nhưng khi maintain hoặc testing, refactor code thì thật thảm hại (maintance == dọn shit). Có thể tham khảo link dưới sẽ rõ mục đích Using Repository Pattern in Laravel 5
Thảo luận
Repository giúp chúng ta thực hiện query từ data và map chúng tới những logic cũng như thay đổi logic cơ bản : get,find, where, theo yêu cầu bài toán.
Cấu trúc
Ví dụ
Thông qua respository trên bosnadev bạn có thể tạo cho mình một structure riêng.
4. Strategy pattern
Mục đích
Strategy định nghĩa một tập hợp các giải thuật khác nhau, mỗi giải thuật được triển khai bởi một class cụ thể và chúng được xử dụng theo các cách khác nhau theo mục đích riêng.
Strategy giúp các giải thuật khác nhau độc lập với client sử dụng nó.
Vấn đề
Một trong những chiến lược chủ đạo của thiết kế hướng đối tượng là "SOLID". Cùng một chức năng nhưng được thực hiện cho nhiều đối tượng khác nhau, sẽ dẫn tới việc tạo quá nhiều đối tượng khác nhau có chức năng giống nhau, tạo ra sự dưa thừa và khó kiểm soát.
Thảo luận
Pattern này hơi trừu tượng, nhưng phần cấu trúc sau sẽ cho thấy nó đơn giản như thế nào cho việc xử lý bài toán cộng, trừ, nhân cũng như chia.
Cấu trúc
Ví dụ
IIlluminate\Cache\StoreInterface
hoặc
Illuminate\Config\LoaderInterface
5. Provider pattern
Thảo luận
Pattern này được đưa ra bởi Microsoft, nhưng mục đích lại giống hoàn toàn Strategy. Dù có nhiều bàn luận nó vẫn được coi là một design pattern
Ví dụ
IIlluminate\Auth\AuthServiceProvider hoặc Illuminate\Hash\HashServiceProvider
6. Facade pattern
Thảo luận
Facade cho phép developer tổng hợp hoặc chuyển một class thành một interface. Pattern này triển khai rất dễ, chắc cái này đơn giản nhất mình thấy. Bạn sẽ gặp các Input::has(), URL::route(), View::make().
Ví dụ
Chi tiết những facade trong laravel facade
Xong phần 2, hẹn gặp lại các bạn tại Best Practices
Laravel Design Patterns và Best Practices Phần 2
Nhận xét
Đăng nhận xét