thảo luận Có nên học OOP Design Patterns?

Lý thuyết về OOP Design Patterns vô cùng phổ biến trong ngành dev. Kể cả 1 thằng chưa từng học qua như mình khi review lại cũng phát hiện bản thân thường sử dụng khoảng 30% Design Patterns một cách tự nhiên mà ko hề hay biết. Vậy thì theo bạn sinh viên IT có nên học Design Patterns?

Cá nhân mình câu trả lời là không, có thể đọc sơ qua để tham khảo nhưng ko nên học nhớ quá sâu.

Lý do:

- Ảnh hưởng tới tư duy sáng tạo: Thay vì tập trung suy nghĩ để giải quyết các vấn đề, sau đó tạo ra bản design thích hợp dựa trên các yếu tố liên quan đến sản phẩm, bạn sẽ bị ảnh hưởng bởi các khuôn mẫu trong design pattern, thậm chí cố gắng suy nghĩ để đưa các design patterns vào trong thiết kế.

- Thường tạo ra sự dư thừa không cần thiết (Over-Engineering/Abstraction) nhưng nhiều khi cần thì lại thiếu: Rất nhiều tính năng của sản phẩm là unique, những tính năng như vậy phần lớn đều dẫn đến hiện tượng thừa-thiếu khi đưa vào design patterns. Ví dụ như bạn cần phải tạo ra 1 đống interface cho 1 class vô cùng đơn giản, rồi khi cần có sự thay đổi trong thiết kế thì cũng phải thay cả 1 đống mất thời gian gấp 5-10 lần so với bình thường.

- Fresher/Junior thường không đủ kinh nghiệm để sử dụng design patterns 1 cách hợp lý: nhưng vẫn cố sử dụng và kết quả thường là copy-paste hoặc 1 đống bùi nhùi.

- DP khiến thinkflow bị branching/corrupt nhiều hơn: branching sẽ nhanh chóng tạo ra sự mệt mỏi cho não. Trong khi rule (simple, minimal, flexible) tựa như memcached có thể truy xuất gần như zero cost để phục vụ cho việc thiết kế thì việc lựa chọn giữa phương án A, B, C giống như là inefficiently memory use.

- DP là khái niệm trừu tượng: chính vì trừu tượng nó sẽ khiến bạn bị hấp dẫn và suy nghĩ về nó khá nhiều. Trong khi sự cần thiết và tính thực dụng của nó trên effort bỏ ra thường là rất thấp. Kể cả good case là nó phù hợp và bạn nghĩ chỉ apply vào là xong nhưng thực tế khi đưa vào vẫn phải tốn nhiều năng lượng não.

--------

Mặc định như tấm chiếu mới thì ai chả Tight Coupling
Ăn củ hành đầu tiên trong đời Oop, xếp bảo lag thế, sẽ biết đến Singleton
Còn mấy cái khác tự nhiên làm ra có mà Godlike

Không, cứ nắm vững các tính năng của ngôn ngữ mình sử dụng, cứ viết tuần tự nhiều vào, thấy lặp thì hẵng bắt tay vào xem xét có cần phải tách ra thành abstraction mới hay không, tạo abstraction thì ráng bám sát theo cái business logic của mình, đừng tạo abstraction bừa bãi.

Design pattern thì học như nước đổ lá môn, trừ khi tự thân vận động, suy nghĩ về vấn đề rồi thử áp dụng thành công thì mới nhớ, còn chỉ đọc lý thuyết thì vào mắt này bay ra mắt nọ thôi.

Đọc cho biết chứ bình thường cũng không nhớ để áp dụng đâu.
Cái cần nhất là nắm chắc SOLID, một số nguyên lý như KISS, DRY, Law of Demete... là được.
Trong quá trình làm sẽ tự nhiên ngộ ra

Thực ra tất cả các pattern đều theo SOLID. Nếu hiểu rõ solid thì sẽ tư có pattern riêng

có nếu công việc yêu cầu, nếu ngôn ngữ chính là những ngôn ngữ già nua như java,ruby hoặc .net
không nếu muốn mở rộng tầm nhìn ,làm mọi thứ một cách sáng tạo hơn nhanh hơn, ít phụ thuộc hơn , làm việc với các ngôn ngữ mới như go, typescript, kolin,...
mấy ngôn ngữ mới đẻ ra chẳng có thằng nào hỗ trợ OOP một cách tự nhiên như java hay .net

foreveralone said:

Không, cứ nắm vững các tính năng của ngôn ngữ mình sử dụng, cứ viết tuần tự nhiều vào, thấy lặp thì hẵng bắt tay vào xem xét có cần phải tách ra thành abstraction mới hay không, tạo abstraction thì ráng bám sát theo cái business logic của mình, đừng tạo abstraction bừa bãi.

Click to expand...

Cách code của bác rất giống mình, bởi vì thường xuyên nghiên cứu và test các tính năng mới trực tiếp vào sp nên mình rất ngại tạo ra abstraction ko cần thiết. Mọi thứ nên cân bằng ở mức vừa đủ mà đi theo design pattern hầu như đều là overkill => cho nên 1 design gọi là tối ưu thường ko sử dụng design patterns, nếu có chỉ là trùng hợp.

Học để đọc code người ta có thể hiểu được. Nhất là các bác làm maintainence.

Standing on the shoulders of giants

muốn sáng tạo cái mới thì phải nắm cái cũ, không thì lại reinvent the wheel.
à nếu mà làm thợ code thì không cần

mấy cái design pattern của OOP thực ra chỉ hợp với OOP của java dotnet thôi, mấy cái khác (kể cả c++) cố áp vào sẽ thấy mùi thum thủm.

nhưng mà nếu muốn tham khảo học tập thì cứ nên đọc, dù nó có lỗi thời thì mấy cái phát triển sau này cũng đều dựa theo mấy cái trước đó cả, rảnh đọc hết để biết tại sao lại thế này thế kia cũng ổn.

// nói thế thôi chứ tôi chũng đíu thèm đọc tử tế bao giờ.

Design pattern ko phải là vạn năng.

DP nói nôm na là một hướng giải quyết cho một bài toán cụ thể, một vấn đề cụ thể, nó giống như ngày xưa ông đi học thầy dạy công thức tính diện tích hình vuông vậy, gặp hình vuông thì ông cứ áp vào chứ gặp hình chữ nhật hoặc hình thoi là ăn kít.

Vì thế nên ông cần phải xác định xem bài toán của ông là gì, for see những vấn đề mà có thể ông sẽ gặp phải trong quá trình phát triển, sau đó xem có DP nào giải quyết được những vấn đề đó không thì apply vào, nó giống như là thuốc vậy, có bệnh thì uống chứ ko có bệnh thì đừng động vào làm gì cho mệt.

Tuy nhiên vẫn cần phải biết là có thuốc nào để chữa bệnh nào, hoặc ít nhất là biết các loại bệnh rồi sau còn đi tìm thuốc nhé. Không đến lúc ốm lăn quay ra rồi, product sắp release rồi mới đòi apply DP vào thì team nó đấm cho tím mắt.

gbvn1 said:

Lý thuyết về OOP Design Patterns vô cùng phổ biến trong ngành dev. Kể cả 1 thằng chưa từng học qua như mình khi review lại cũng phát hiện bản thân thường sử dụng khoảng 30% Design Patterns một cách tự nhiên mà ko hề hay biết. Vậy thì theo bạn sinh viên IT có nên học Design Patterns?

Cá nhân mình câu trả lời là không, có thể đọc sơ qua để tham khảo nhưng ko nên học nhớ quá sâu.

Lý do:

- Ảnh hưởng tới tư duy sáng tạo: Thay vì tập trung suy nghĩ để giải quyết các vấn đề, sau đó tạo ra bản design thích hợp dựa trên các yếu tố liên quan đến sản phẩm, bạn sẽ bị ảnh hưởng bởi các khuôn mẫu trong design pattern, thậm chí cố gắng suy nghĩ để đưa các design patterns vào trong thiết kế.

- Thường tạo ra sự dư thừa không cần thiết (Over-Engineering/Abstraction) nhưng nhiều khi cần thì lại thiếu: Rất nhiều tính năng của sản phẩm là unique, những tính năng như vậy phần lớn đều dẫn đến hiện tượng thừa-thiếu khi đưa vào design patterns. Ví dụ như bạn cần phải tạo ra 1 đống interface cho 1 class vô cùng đơn giản, rồi khi cần có sự thay đổi trong thiết kế thì cũng phải thay cả 1 đống mất thời gian gấp 5-10 lần so với bình thường.

- Fresher/Junior thường không đủ kinh nghiệm để sử dụng design patterns 1 cách hợp lý: nhưng vẫn cố sử dụng và kết quả thường là copy-paste hoặc 1 đống bùi nhùi.

--------

Click to expand...

Vậy đố fen mấy cái lib fen đang dùng có sử dụng OOP hay DP ko?

làm FP riết chả buồn để mắt tới OOP luôn

học để đi phỏng vấn

Projects với mindset không sử dụng DP => simple, minimal, flexible
Projects với mindset sử dụng DP => professional, safe, top down heavy

Hiện tại mình đang maintenance 2 dự án 4 & 6 năm đều đang đi theo hướng simple, minimal, flexible. Cả 2 dự án đều có những thay đổi, nâng cấp vô cùng lớn so với first release, nhưng mọi thứ vẫn clear & fast, mỗi lần thêm tính năng mới chỉ cần refactoring lại ko mất quá nhiều effort.

Với mindset DP mình tính là phải đập đi xây lại khoảng 2 lần.

Mình update thêm 2 problems

DP khiến thinkflow bị branching/corrupt nhiều hơn: branching sẽ nhanh chóng tạo ra sự mệt mỏi cho não. Trong khi rule (simple, minimal, flexible) tựa như memcached có thể truy xuất gần như zero cost để phục vụ cho việc thiết kế thì việc lựa chọn giữa phương án A, B, C giống như là inefficiently memory use.

DP là khái niệm trừu tượng: chính vì trừu tượng nó sẽ khiến bạn bị hấp dẫn và suy nghĩ về nó khá nhiều. Trong khi sự cần thiết và tính thực dụng của nó trên effort bỏ ra thường là rất thấp. Kể cả good case là nó phù hợp và bạn nghĩ chỉ apply vào là xong nhưng thực tế khi đưa vào vẫn phải tốn nhiều năng lượng não.

Mới nghĩ ra thêm 1 problem

Top Down là dự báo tương lai, re-design hay no-future: nếu là dự báo tương lai thì dev có cần theo học 1 khóa chiêm tinh của vanga hay ko?
Mà thực tế phần lớn các dự án DP top down đang hoạt động hiệu quả đều là re-design

Không thấy chủ thớt nhắc đến vấn đề cost of knowledge transfer. Nếu không follow design pattern thì cost of knowledge transfer sẽ lớn vì:

• Document phải fully covered every object/class/function.
• New member joining phải read tất cả các component để understand codebase.

Ví dụ:

• nếu không sử dụng separation of concerns aka API design pattern thì để debug sẽ phải hiểu tất cả logic của các component thay vì chỉ cần hiểu what APIs do
• nếu không sử dụng OOP thì sẽ có code duplication, logic duplication, limited of extendability.

Tất nhiên nếu như bạn maintain project 1 mình hoặc 1 team in long term không có người in hay out thì việc đập đi xây lại là không cần thiết. Tuy nhiên, trong môi trường khá dynamic như bây giờ, sử dụng DP là 1 cách để đảm bảo công ty không phụ thuộc vào 1 cá nhân hay giảm thời gian onboarding

Cái dùng nhiều nhất chắc singleton còn 1 cái nữa mà giờ chả nhớ. Mấy năm nay maintain 1,2 dự án và phát triển 1,2 cái pj cỏn con mới nên cũng chả áp dụng mấy.

BetterNextTime said:

Không thấy chủ thớt nhắc đến vấn đề cost of knowledge transfer. Nếu không follow design pattern thì cost of knowledge transfer sẽ lớn vì:

• Document phải fully covered every object/class/function.
• New member joining phải read tất cả các component để understand codebase.

Ví dụ:

• nếu không sử dụng separation of concerns aka API design pattern thì để debug sẽ phải hiểu tất cả logic của các component thay vì chỉ cần hiểu what APIs do
• nếu không sử dụng OOP thì sẽ có code duplication, logic duplication, limited of extendability.

Tất nhiên nếu như bạn maintain project 1 mình hoặc 1 team in long term không có người in hay out thì việc đập đi xây lại là không cần thiết. Tuy nhiên, trong môi trường khá dynamic như bây giờ, sử dụng DP là 1 cách để đảm bảo công ty không phụ thuộc vào 1 cá nhân hay giảm thời gian onboarding

Click to expand...

Bold 1 - Separation of concerns là 1 trong những nguyên tắc cơ bản của design, ko phải design pattern.
Bold 2 - có hai vấn đề

• Mình vẫn xài OOP
• Nhưng mình ko chắc là không sử dụng OOP thì sẽ có code duplication, logic duplication, limited of extendability. Bởi vì case quá rộng nhưng dựa theo mình biết thì ko sử dụng OOP vẫn ko gặp những vấn đề trên

New member joining phải read tất cả các component để understand codebase => 1 project được design simple, minimal thì sẽ dễ đọc code hơn chứ? Hơn nữa cần gì phải đọc toàn bộ mới theo kịp