Laravel Design Patterns và Best Practices Phần 3

Quay trở lại với series Laravel Design Patterns và Best Practices , phần cuối này tôi sẽ tập trung vào sử dụng và chỉ ra những design pattern đã dùng trong laravel cũng như trong dự án tôi đã làm.


Để tiếp cận những design pattern này thì lời khuyên của tôi bạn lên làm tốt những tiêu chuẩn sau trong khi code, để code dễ đọc hơn và nhìn thoáng đãng, lãng tử hơn 

  1. No Abbreviations
  2. Dont Use Else
  3. One Level of Indentation
  4. Limit Your Instance Variables
  5. Wrap Primitives (Sometimes)
Series này của Jeffrey mất phí nhưng tôi có thể tóm tắt như sau:

1. Không viết tắt : tức tến biến, tên class cũng lên viết rõ ràng theo mục đích sử dụng, dù dài cũng được (ví dụ : function getDataWithRelationCommentAtHomePage(){}).

2. Hạn chế xử dụng điều kiện else: vì trong một function hoặc logic chúng ta xử dụng else nghĩa là đang xử lý 2 chức năng cho một hàm, như khi validate data vẫn hay làm, nếu dữ liệu đúng cho qua còn không đúng sẽ báo lỗi, xử lý kiểu như vậy sau đó có nhiều logic thì phốt nhiều, ko rõ sẽ chạy vào đâu nữa .


 3. Lồi lõm một cấp là đủ

sau khi format

4. Giới hạn việc dùng quá nhiều biến, nên giao nó cho một class khác quản lý, đây cũng là một code smell cần lưu tâm.
Đây là một constructor cồng kềnh


Sau đó tôi refactor lại 


Về sau tôi cần khai báo thêm service cho class chỉ vào UserService khai báo và trong controller User tôi gọi các service đó qua $userSerice bằng get() nhìn nhẹ nhàng hơn.

5. Hạn chế xử lý logic trong constructor hoặc function cơ bản.



Quay trở lại với best practices, một số class, services sử dụng các pattern tôi đã giới thiệu trong mục Ví dụ hoặc Bàn Luận của phần 2 nên trong phần 3 này tôi sẽ chi tiết các ứng dụng tôi đã làm theo các pattern đã giới thiệu.

Factory Pattern

Hay đây, bài toán về multi product cho shopping cart, khi tạo một sản phẩm cho shop, một flexible product chỉ gồm giá cả và miêu tả, nhưng mỗi sản phẩm lại có những miêu tả khác nhau, cùng định nghĩa một field type thì ... gọi là attribute, nên quyết định dùng Factory cho bài toán.


Builder Pattern

Tôi gặp phải bài toán về ngày tháng năm, khi mà user truyền vào các tham số trên, việc khó khăn là tôi sẽ dùng Carbon hay DateTime để định dạng ngày tháng, mà cái khoản strtotime, timestamp làm tôi đau đầu vì exception, nên tôi build một class DateBuild().

nhìn giống Java bl, với đầu vào như kia tôi cũng không sợ user sẽ đưa tôi date time theo US format hay Asia format nữa, class DateBuilder của tôi còn là sự kết hợp của Carbon, Datetime thật phức tạp.

 Repository pattern

 Bạn vào bosnadev xem chi tiết.

Strategy Pattern

Pattern này tôi gặp khi làm việc với collection của laravel, dữ liệu đầu vào phức tạp có thể là một kết quả của paging, đôi lúc là import data tôi format lại data trước khi insert database. Bạn có thể chỉ cần setComparator một lần tuỳ theo bài toán, dưới đây là mọt ví dụ, trong đó tôi phải sort và format 2 loại data khác nhau.


 Tổng kết: Design pattern giúp lập trình viên dễ dàng refactoring và thực thi những chức năng khó cho hệ thống lớn. Tôi cũng mò mẫm mãi mới ngẫm được vài pattern. Khi làm việc với Laravel, tôi gặp lại lần nữa những pattern quen thuộc và pattern mới. Cảm ơn các bạn đã đọc series này, mọi thắc mắc có thể contact với mình qua skype:smagic39.

Laravel Design Patterns và Best Practices Phần 3

Nhận xét

Bài đăng phổ biến từ blog này

Skill - Tập tành ghi chép Bullet Journal

Laravel Design Patterns và Best Practices Phần 2

Lộ trình học magento 2