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

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.

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.

--------

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

• 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.

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

• 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

BetterNextTime said:

• nếu không sử dụng OOP thì sẽ có code duplication, logic duplication, limited of extendability.

gbvn1 said:

Mình đưa ra chỉ là kinh nghiệm của bản thân, Cho nên mới tạo ra thread pool.

Nhiều người không đồng ý vậy chắc là do mình đưa ra vấn đề ko đúng rồi

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.

- 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.

--------