Le Quang Duy

Đôi khi cho dù bạn thiết kế code của mình tốt đến đâu, chúng vẫn sẽ luôn có những thay đổi cần thực hiện. Thật khó khăn, nếu không thể code được nó ngay lần đầu tiên, đó là nơi tái cấu trúc xuất hiện. Tái cấu trúc (refactoring) là quá trình thực hiện thay đổi code của bạn để hành vi bên ngoài code không thay đổi, nhưng cấu trúc bên trong được cải thiện, điểu này được thực hiện bằng cách thực hiện các thay đổi nhỏ, tăng dần với cấu trúc code và kiểm tra thường xuyên để đảm bảo những hành vi này không làm thay đổi hành vi của code. Lý tưởng nhất là bạn không muốn tiến hành tái cấu trúc khi code của bạn đã hoàn tất. Điều này có thể tổn thời gian và điều này có thể gây ra nhiều vấn đề hơn là đang sửa chữa. Bạn muốn thực hiện các thay đổi tái cấu trúc này khi bạn thêm tính năng, tái cấu trúc mã tại thời điểm này có thê làm cho việc bổ sung dễ dàng hơn để đạt được, và tiết kiệm cho bạn khỏi cần phải đại tu hoàn toàn. Vì vậy, những thay đổi bạn cần phải thực hiện là gì ? Tương tự như cá

Để quản lý sự phức tạp, một ý tưởng là một lớp nên được thiết kế sao cho nó không cần thiết và phụ thuộc vào lớp khác trong hệ thống. Điều đó sẽ tăng khớp nối và làm cho hệ thống của bạn khó bảo trì hơn. Điều này tự nhiên dẫn đến một khái niệm rằng các lớp nên có một cái nhìn hạn hẹp về những gì của các lớp khác mà nó biết. Bằng cách giới hạn các lớp giao tiếp với nhau, bạn có thể thực thi Principle of Least Knowledge. Nguyên tắc này cũng được thực hiện hóa trong một quy tắc gọi là The Law of Demeter. Ỷ tưởng cơ bản của luật này là các lớp nên biết và tương tác với nhau càng ít lớp khác càng tốt, điều này có nghĩa là bất kỳ lớp nào cũng chỉ nên giao tiếp với bạn bè ngay trực tiếp của nó. Khái niệm này hơi trừu tượng một chút so với các nguyên tắc thiết kế khác, nhưng nó cũng quan trọng không kém vì nó giúp giảm khớp nối và cung cấp sự ổn định cho hệ thống của bạn. The Law ò Demeter thực sự bao gồm các quy tắc khác nhau mà chúng ta sẽ xem xét, cũng như cách The Law of Demeter có thể v

Nhiều mẫu thiết kế mà chúng ta đã phám phá sử dụng khái quát hóa lớp cụ thể, các khái quát này được trình bày dưới dạng interface cho phép các lớp client sử dụng để gián tiếp gọi các hành vi của các lớp cụ thể. Các mẫu thiết kế làm điều này để các lớp client trở nên ít phụ thuộc hơn vào các lớp cụ thể, cho phép thay đổi được thực hiện dễ dàng hơn. Các giao diện đóng vai trò quan trọng trong lập trình hướng đối tượng, đến mức bạn nên cố gắng lập trình giao diện thay vì các lớp cụ thể. Tuy nhiên, có một vấn đề có thể phát sinh nếu một interface chứa quá nhiều. Bạn có thể nghĩ về bất cứ những vấn đề mà điều này có thể gây ra ? Hãy xem xét ví dụ này. Hãy tưởng tượng việc tạo ra một hệ thống đại diện cho khu vực thanh toán tại một cửa hàng tạp hóa. Ở các nước Bắc Mỹ, có hai cách khách hàng có thể trả tiền cho mặt hàng của họ. Sử dụng nhân viên thu ngân hoặc máy bán hàng tự động, mục đích đó có thể khái quát hóa thành một giao diện. Cả hai đều quét các mặt hàng mà khách hàng muốn mua, chấp

Một vấn đề phổ biến trong hệ thống thiết kế hướng đối tượng mà các mẫu thiết kế cố gắng giải quyết là làm thế nào để giảm lượng khớp nối chặt chẽ ? Các nguyên tắc thiết kế được sử dụng bởi tất cả các mẫu thiết kế xác định các cách khác nhau trong đó khớp nỗi có thể được quản lý. Ít kết nối trong hệ thống của bạn có nghĩa là hệ thống của bạn có thể linh hoạt hơn và có khả năng sử lý các thay đổi đối với cơ sở mã hiện có của nó, chẳng hạn như tích hợp tính năng mới. Các mẫu thiết kế mà chúng ta đã khám phá sử dụng rất nhiều khái quát hóa, trừu tượng hóa và đa hình như là phương tiện của sự gián tiếp. Mặc dù kế thừa là một cách tuyệt vời để đạt được số lượng tái sử dụng mã cao, nhưng nó đi kém với phí kết hợp chặt chẽ giữa siêu lớp và các lớp con của nó. Vì vậy, tại sao có khớp nối ? Hãy suy nghĩ về những gì kế thừa làm trong lâp trình hướng đối tượng ? Khi một lớp con kế thừa từ một superclass, lớp con có được kiến thức và quyền truy cập của chúng những gì không private. Điều này có ng

Một vấn đề phổ biển mà bạn sẽ cần giải quyết khi thiết kế hệ thống của mình đó là sự phụ thuộc (dependency). Có một số câu hỏi sẽ xuất hiện khi nói đến chủ đề này, chẳng hạn như điểm phụ thuộc ở đâu ? Sự phụ thuộc phần mềm về cơ bản là khớp nối xác định mức độ phụ thuộc giữa các thành phần khác nhau của phần mềm. Nếu một phần trong hệ thống của bạn được ghép nối cao, thì mức độ mà chúng dựa vào nhau được coi là cao, trong khi mức độ phụ thuộc thấp có nghĩa là hệ thống của bạn có mức độ khớp nối thấp hơn ? Sự phụ thuộc là một chủ đề quan trọng vì nó sẽ xác định mức độ bạn có thể dễ dàng thực hiện các thay đổi cho hệ thống của mình. Hãy nghĩ về nó theo cách này, nếu bạn phụ thuộc vào một loại thực phẩm cụ thể để sinh tồn, thì bạn sẽ không thể thay thế nó bằng thứ khác. Trong một ví dụ thực tế, cơ thể chúng ta phụ thuộc vào nước để sinh tồn. Chúng ta không thể thay thế nước bằng bánh mì và hi vọng sẽ có được kết quả tương tự như một khi chúng ta uống nước. Bạn sẽ phải đối mặt với cùng

Là một nhà phát triển phần mềm, bạn nên cố gắng tạo ra các hệ thống linh hoạt (flexible) và tái sử dụng (reusable). Cơ sở code linh hoạt cho phép mở rộng hệ thống dễ dàng hơn, Reusable code có nghĩa là bạn không cần phải thực hiện cái gì đó mà đã được thực hiện. Đạt được mục tiêu này sẽ giúp cho code của bạn dễ bảo trì hơn. Các mẫu thiết kế là tất cả các kỹ thuật khác nhau mà bạn có thể sử dụng để giúp bạn viết mã linh hoạt và có thể sử dụng lại. Tất cả các mẫu thiết kế tuân theo một nguyên tắc thiết kế cơ bàn, giải quyết các vấn đề như tính linh hoạt và khả năng sử dụng lại, một trong những nguyên tắc đó là Open/Closed Principle. Nguyên tắc này nêu rõ, các lớp nên được mở rộng, nhưng đóng để thay đổi. Vậy giờ thì điều đó có nghĩa là gì ? Như tên của nguyên tắc này cho thấy, có hai phần với nó, open với close. Bạn nên xem xét một lớp là close để chỉnh sửa, một khi nó đã được kiểm tra hoạt động đúng, tất cả thuộc tính và hành vi được gói gọn và được chứng minh là ổn định trong hệ th

Chào mừng bạn đã đồng hành cùng mình đến bài viết này, cho đến nay, chúng ta đã tìm hiểu các mẫu thiết kế Creational, Structurall và Behavioral. Trong bài viết này, bạn sẽ tìm hiểu về MCV Pattern. Đây là một mẫu được xây dựng dựa trên các mẫu thiết kế mà bạn đã tìm hiểu trong các bài viết vừa qua, từ giờ, bạn cũng sẽ tìm hiểu về một số nguyên tắc thiết kế chung dựa trên các mẫu thiết kế để đạt được phần mềm có thể tái sử dụng, linh hoạt và có thể bảo trì. Sau đó, bạn sẽ tìm hiểu sang cách phân tích và phê bình mã của bạn cho thiết kế Bad Design, bạn sẽ tìm hiểu về nhiều sơ xuất phổ biến khiến lý do vì sao chúng dẫn đến thiết kế xấu, trong ngành Công nghệ phần mềm, những thứ này được gọi là AntiPattern, hoặc Code Smells. Mình thường bắt đầu buổi sáng với bài River flow in you . Còn bạn ? Hãy bắt đầu nào. Hãy tưởng tượng bạn được thuê một cửa hàng tạp hóa nhỏ trong khu phố của bạn. Nhân viên thu ngân của họ đang phàn nàn về các hệ thống tiền mặt kiểu cũ, nơi họ phải gõ giá vào của

Hãy tưởng tượng bạn có một blog yêu thích. Mỗi ngày, bạn truy cập vào nó nhiều lần để kiểm tra các bài đăng blog mới, sau một thời gian, bạn ngán với thói quen này. Bạn nghĩ phải có một cách tốt hơn cho chính mình, giải pháp đầu tiên trong đầu bạn là viết một kịch bản để kiểm tra các bài đăng mới mỗi giây. Nhưng khi xem xét thêm, bạn sẽ thấy rằng hầu hết các trang web sẽ không đánh giá cao hàng loạt yêu cầu của bạn và sẽ chặn IP của bạn như thể bạn là mối nguy hiểm cho một đợt tấn công từ chối dịch vụ của họ thay vì là một độc giả yêu thích. Để tránh điều này, thay vào đó, bạn viết một kịch bản để kiểm tra các bài đăng với mỗi giờ một lần. Nhưng phải chấp nhận một sự thất vọng, điều này có nghĩa là bạn đang phải bỏ các bài đăng cung cấp các thay đổi trực tiếp, chẳng hạn như các bài đăng live về chương trình yêu thích của bạn, một giải pháp tốt hơn cho bạn là để blog thông báo cho bạn mỗi khi bài viết mới được thêm vào, bạn sẽ nhấn nút đăng ký blog, mỗi khi bài đăng mới được xuất bả

Command Pattern đóng gói yêu cầu như một đối tượng của chính nó, thông thường, khi một đối tượng đưa ra yêu cầu cho một đối tượng thứ hai thực hiện hành động, đối tượng thứ nhất sẽ gọi một phương thức của đối tượng thứ hai và đối tượng thứ hai hoàn thành nhiệm vụ. Trong tình huốn này, đối tượng người gửi (sender) trực tiếp phải giao tiếp với đối tượng người nhận. Thay vì để các đối tượng này giao tiếp trực tiếp với nhau, Command Pattern tạo một đối tượng command ở giữa người gửi và người nhận. Bằng cách này, người gửi không cần biết về người nhận và các phương thức cần phải gọi. Hãy nghĩ về nó khi các ông chủ trong công ty sử dụng các schedule để thực hiện các nhiệm vụ, ví dụ, nếu sếp cần một công nhân lên lịch họp và cũng cần một công nhân khác nói chuyện với khách hàng về kinh doanh, sếp có thể sử dụng các mentos (bản ghi nhớ). Nhưng là một người rất bận rộn, Sếp không có thời gian để nhớ công nhân  nào phải làm gì và sẽ không có thời gian đi bộ đến các công nhân khác nhau để

Hãy suy nghĩ về cái gì bạn làm rất xen kẽ. Có thể bạn đang xem bài viết này, nhưng có lẽ bạn đang làm thêm điều gì khác nữa ? Bạn đang ngồi, đứng, hay nằm ? Giả sử tôi yêu cầu bạn thực hiện một điệu nhảy nhưng bạn vẫn đang ở trạng thái cũ, nếu bạn đang ngồi xuống, điệu nhảy của bạn có thể liên quan đến việc bạn vẫy tay vai và lắc đầu, nếu bạn đang đứng, bạn sẽ dùng thêm chân vào điệu nhảy của mình, nếu bạn đang nằm, bạn có thể giơ tay lên và ngọ nguậy cơ thể. Tất cả những điều tôi bảo bạn phải làm là nhảy, và bạn đã chọn một điệu nhảy phù hợp với trạng thái của bạn, và tôi không phải xác định điệu nhảy của bạn sẽ trông như thế nào. Vì các đối tượng trong code của bạn biết về trạng thái hiện tại của chúng, nó có thể chọn hành vi phù hợp dựa trên trạng thái của họ. Khi trạng thái của nó thay đổi, hành vi này có thể được thay đổi. Đây chính là State Pattern, mẫu trạng thái chủ yếu được sử dụng khi bạn cần thay đổi hành vi của một đối tượng dựa trên trạng thái mà nó đang hoạt động. H

Chain of reponsibility pattern là một chuỗi các đối tượng chịu trách nhiệm xử lý các yêu cầu. Hãy nghĩ về nó như một yêu cầu giúp đỡ về vấn đề sức khỏe, vì vậy, bạn thử đến gặp bác sĩ nhưng vì sức khỏe có vấn đề, bác sĩ lại giới thiệu bạn đến gặp một chuyên gia, nhưng chuyên gia đó đang nghỉ phép và không thể làm việc vì vậy bạn được giới thiệu đi gặp một chuyên gia khác, và cuối cùng, chuyên gia này là người giải quyết vấn đề của bạn, nhưng thực sự bạn không quan tâm ai trong chuỗi chuyên gia y tế này giúp đỡ bạn, bạn chỉ quan tâm rằng vấn đề của bạn sẽ được giải quyết bởi ai đó. Khi một đối tượng client gửi yêu cầu, trình xử lý đầu tiên trong chuỗi sẽ cố giải quyết nó, nếu không thể giải quyết, nó sẽ gửi yêu cầu đến trình xử lý tiếp theo, việc chuyển yêu cầu này tiếp tục cho đến khi một trình xử lý có thể giải quyết được yêu cầu, nếu yêu cầu đi qua toàn bộ trình xử lý mà không thể giải quyết thì đó là một yêu cầu không thỏa mãn. Tiếp một ví dụ về điều này, giả sữ bạn đang sửa

Lại là mình, trong những bài viết trước kia, chúng ta đã tìm hiểu một loạt các mẫu thiết kế thuộc Creational và Structural. Bây giờ, sẽ tìm hiểu loại nhóm cuối cùng của Desing Pattern, các mẫu này tập trung vào việc các đối tượng riêng lẻ cộng tác để đạt được hành vi chung, người ta gọi là nhóm Behavial Pattern. Bắt đầu ở đây nào. Khi thiết kế phần mềm, điều quan trọng là nhận ra các đối tượng khác nhau của bạn phối hợp hướng đến một mục tiêu chung. Mỗi đối tượng bạn thực hiện là một phần của một giải pháp lớn hơn. Để mỗi người thực hiện công việc của mình một cách hiệu quả, nó cần phải có một mục đích đề ra. Hãy nghĩ về nó giống như mỗi người làm việc tại một công ty, nếu người của công ty không có bất kỳ một vai trò được xác định trước nào, sẽ không có cách nào để đảm bảo rằng một người đang làm một việc mang lại lợi ích cho công ty. Tình huống này giống với Behavior Pattern, nó tập trung vào các đối tượng hướng tới mục tiêu chung. Có nhiều cách mà đối tượng có thể xác định hành vi