thảo luận OOP hay FP

lam vung lau lam · 6/10/20

rosario_1 đã nói:
Và như thế này thì ko bị Monkey Forest problem nữa?

Về ngây ngô, đúng, tôi ngây ngô nên tôi mới hỏi anh tại sao?

anh hãy nghĩ con khỉ là 1 hàm. trong FP con khỉ có thể tồn tại độc lập, trong OOP con khỉ phải nằm trong 1 khu rừng (class).
giả sử anh phụ thuộc vào con khỉ (dependency injection). trong FP anh chỉ cần inject con khỉ là xong, nhưng trong OOP anh phải inject cả khu rừng. và đặc biệt là trong khu rừng này không chỉ có 1 con khỉ mà có hàng tá con khỉ khác đang dùng chung internal state.

lam vung lau lam · 6/10/20

Thích Màu Hường đã nói:
Anh show code ra đi rồi tôi hỏi tiếp, câu hỏi rất cụ thể nếu không kế thừa bên OOP thì viết kiểu FP anh làm sao?

Mã:

let print cus =
    match cus with
    | Customer c ->
        let data = sprintf "name: %s, age: %i" c.name c.age
        println data
    | Below18Customer c ->
        let data = sprintf "name: %s, age: %i, grade: %i" c.name c.age c.grade
        println data
    | // tự suy ra nha

Thích Màu Hường · 6/10/20

lam vung lau lam đã nói:
anh hãy nghĩ con khỉ là 1 hàm. trong FP con khỉ có thể tồn tại độc lập, trong OOP con khỉ phải nằm trong 1 khu rừng (class).
giả sử anh phụ thuộc vào con khỉ (dependency injection). trong FP anh chỉ cần inject con khỉ là xong, nhưng trong OOP anh phải inject cả khu rừng. và đặc biệt là trong khu rừng này không chỉ có 1 con khỉ mà có hàng tá con khỉ khác đang dùng chung internal state.

1. Anh không code được thì anh nói thẳng là anh không code đươc. Dân Dev thì show code ra không nói chuyện dài dòng.

2. Anh trả lời như vậy thì tôi nghi ngờ kiến thức của anh về OOP và design patterns Nói thật anh chẳng hiểu gì về OOP, cụ thể là polymorphism (đa hình) trong trường hợp này.

lam vung lau lam · 6/10/20

Thích Màu Hường đã nói:
2. Anh trả lời như vậy thì tôi nghi ngờ kiến thức của anh về OOP và design patterns Nói thật anh chẳng hiểu gì về OOP, cụ thể là polymorphism (đa hình) trong trường hợp này.

mỗi class anh override hàm ToString chứ tôi lạ gì. sao anh không đọc pattern matching trước khi bắt bẻ. tiện thể thì c# 8 cũng có pattern matching rồi đó. đọc thêm đi nhé.

lyokha114 · 6/10/20

drnoxxx đã nói:
Sao lại không có verb ở đây nhỉ?

Bản chất của OOP xoay quanh việc dispatch message giữa các object, mà object thì bao gồm state + behavior thì verb nó vẫn nằm ở đấy chứ mất đi đâu?

Đúng rồi, chả hiểu bác kia lậm cái noun/verb gì ở đây :confused:

Field/state là noun còn method/behavior là verb thì chết ai hay ai cấm nhỉ ? :confused:

lyokha114 · 6/10/20

lam vung lau lam đã nói:
anh hãy nghĩ con khỉ là 1 hàm. trong FP con khỉ có thể tồn tại độc lập, trong OOP con khỉ phải nằm trong 1 khu rừng (class).
giả sử anh phụ thuộc vào con khỉ (dependency injection). trong FP anh chỉ cần inject con khỉ là xong, nhưng trong OOP anh phải inject cả khu rừng. và đặc biệt là trong khu rừng này không chỉ có 1 con khỉ mà có hàng tá con khỉ khác đang dùng chung internal state.

Tại sao ? Class Monkey, Class Forest là 2 class riêng biệt, lý do gì inject instance m1 lại phải inject cả f1 vậy bác ??

Thích Màu Hường · 6/10/20

lam vung lau lam đã nói:

Mã:

let print cus =
    match cus with
    | Customer c ->
        let data = sprintf "name: %s, age: %i" c.name c.age
        println data
    | Below18Customer c ->
        let data = sprintf "name: %s, age: %i, grade: %i" c.name c.age c.grade
        println data
    | // tự suy ra nha

OK. Thì ra cách anh làm như switch case, if else từng trương hợp. cái pattern matching của anh là vậy đó hả :LOL:

. Ừ thì a show code thì tôi hỏi tiếp đây:

1. Cái phần tô đậm sprintf name, age bị trùng lặp cho tất cả các type customer. Nếu có 10 dạng customer lúc cần sửa phải nhảy vào sửa 10 chổ. Nếu vậy FP ưu việt hơn OOP chổ nào? Hay anh lại lôi nó vào 1 function riêng rồi gọi function đó 10 chổ? :LOL:

2. Câu này quan trọng nè: Ví dụ cài hàm print này trong một module khác tạm gọi là VisualizeCustomer mà anh không có quyền sửa code (giả sử đã build ra binary, dll, deploy cho khách hàng rồi) thì bây giờ requirement có thêm 1 type mới là InternalCustomer, giờ vẫn muốn khi lắp thêm cái InternalCustomer này vào thì cái hàm Print kia vẫn print được thông tin InternalCustomer thì làm sao? Lưu ý là cái Print kia nằm trong VisualizeCustomer anh không được sửa code. :shame:

Thích Màu Hường · 6/10/20

lyokha114 đã nói:
Tại sao ? Class Monkey, Class Forest là 2 class riêng biệt, lý do gì inject instance m1 lại phải inject cả f1 vậy bác ??

Bởi vậy mới nói dek hiểu gì về polymorphism, nó kế thừa cả cây nhưng inject 1 object chỉ là 1 instance của 1 class cụ thể thôi.

lam vung lau lam · 6/10/20

lyokha114 đã nói:
Tại sao ? Class Monkey, Class Forest là 2 class riêng biệt, lý do gì inject instance m1 lại phải inject cả f1 vậy bác ??

đọc lại đi, tôi bảo giả sử con khỉ là 1 hàm, không phải 1 class.

Thích Màu Hường đã nói:
Cái phần tô đậm sprintf name, age bị trùng lặp cho tất cả các type customer. Nếu có 10 dạng customer lúc cần sửa phải nhảy vào sửa 10 chổ. Nếu vậy FP ưu việt hơn OOP chổ nào? Hay anh lại lôi nó vào 1 function riêng rồi gọi function đó 10 chổ?

explicit is better than implicit

Thích Màu Hường đã nói:
Câu này quan trọng nè: Ví dụ cài hàm print này trong một module khác tạm gọi là VisualizeCustomer mà anh không có quyền sửa code (giả sử đã build ra binary, dll, deploy cho khách hàng rồi) thì bây giờ requirement có thêm 1 type mới là InternalCustomer, giờ vẫn muốn khi lắp thêm cái InternalCustomer này vào thì cái hàm Print kia vẫn print được thông tin InternalCustomer thì làm sao? Lưu ý là cái Print kia nằm trong VisualizeCustomer anh không được sửa code.

trần đời tôi chưa thấy cái yêu cầu nào vô lý như này. anh sửa code thì anh release 1 cái dll mới đi. hay tại sao InternalCustomer là của riêng anh mà anh lại muốn sử dụng hàm của 1 dll khác.

lam vung lau lam · 6/10/20

tôi dừng ở đây nha.
ai thích thì tự tìm hiểu và so sánh.
tôi cũng không phải code FP 100%. ví dụ với thuật toán thì tôi vẫn code theo kiểu imperative thôi.

In mathematics and computer science, an algorithm (/ˈælɡərɪðəm/ (About this soundlisten)) is a finite sequence of well-defined, computer-implementable instructions, typically to solve a class of problems or to perform a computation

Thích Màu Hường · 6/10/20

lam vung lau lam đã nói:
đọc lại đi, tôi bảo giả sử con khỉ là 1 hàm, không phải 1 class.

explicit is better than implicit

trần đời tôi chưa thấy cái yêu cầu nào vô lý như này. anh sửa code thì anh release 1 cái dll mới đi.

1. explicit is better than implicit
Ý anh là việc lặp lại code nhiều chổ thì tốt hơn. Anh trả lời vậy thì thôi tôi hiểu level của anh mức nào rồi. Nhảy vào tranh luận với anh đúng là sai lầm thật.

2. "trần đời tôi chưa thấy cái yêu cầu nào vô lý như này. anh sửa code thì anh release 1 cái dll mới đi."
Đây là yêu cầu thực tế và gặp rất nhiều. Người ta làm ra cả đống Design Patterns, OOAD để cho những trường hợp này. Anh có thể release dll mới để lắp thêm InternalCustomer nhưng phần core là VisualizeCustomer là module của 3rd party. Vấn đề là cái moulde VisualizeCustomer này anh không có source để sửa thì sao. OOP nó ra interface, kế thừa là để cho những trường hợp này còn FP expert như anh giải quyết thế nào thì anh chưa trả lời được mà chê OOP.

lam vung lau lam · 6/10/20

Thích Màu Hường đã nói:
1. explicit is better than implicit
Ý anh là việc lặp lại code nhiều chổ thì tốt hơn. Anh trả lời vậy thì thôi tôi hiểu level của anh mức nào rồi. Nhảy vào tranh luận với anh đúng là sai lầm thật.

2. "trần đời tôi chưa thấy cái yêu cầu nào vô lý như này. anh sửa code thì anh release 1 cái dll mới đi."
Đây là yêu cầu thực tế và gặp rất nhiều. Người ta làm ra cả đống Design Patterns, OOAD để cho những trường hợp này. Anh có thể release dll mới để lắp thêm InternalCustomer nhưng phần core là VisualizeCustomer là module của 3rd party. Vấn đề là cái moulde VisualizeCustomer này anh không có source để sửa thì sao. OOP nó ra interface, kế thừa là để cho những trường hợp này còn FP expert như anh giải quyết thế nào thì anh chưa trả lời được mà chê OOP.

1. ý tôi là khi anh sửa code thì compiler ném error vào mặt anh chứ không ngầm ngầm mà chạy.
anh bị ám ảnh về DRY à. FP khuyến khích anh tách phần logic chung thành hàm riêng thì có gì mà lặp.
2. thích thì cái VisualizeCustomer anh code theo kiểu plugin, hook, higher order function. lúc ấy anh thích inject code gì vào thì inject, chứ có gì mà không làm được.

Thích Màu Hường · 6/10/20

lam vung lau lam đã nói:
1. ý tôi là khi anh sửa code thì compiler ném error vào mặt anh chứ không ngầm ngầm mà chạy.
2. thích thì cái VisualizeCustomer anh code theo kiểu plugin, hook, higher order function. lúc ấy anh thích inject code gì vào thì inject, chứ có gì mà không làm được.

Ở đây tôi đưa ví dụ ra để hỏi anh cách làm bằng FP như thế nào chứ ko hỏi anh làm được hay là không. Anh nâng bi FP mà đè OOP xuống thì giỏi trả lời nếu không dùng OOP.

Cái plugin, hook anh đưa ra là ví dụ điển hình của OOP đó. Anh nói FP ưu việt hơn sao không giải quyết được mà phải lôi plugin, hook vào trong khi cái này vốn là nhờ các tính chất của OOP.

lyokha114 · 6/10/20

lam vung lau lam đã nói:
đọc lại đi, tôi bảo giả sử con khỉ là 1 hàm, không phải 1 class.

Nói cái nọ lại xọ cái kia, nếu thích sử dụng method thì viết như Helper class rồi static method đi ? Lôi cả instance ra làm gì rồi kêu chung internal state ? Viết method không xài global state không được à :confused:

Ngay cả đặt tên ví dụ đã có vấn đề, class forest lại có method monkey xong đòi lấy monkey ra xài, liên quan nhau thì gọi, không lq thì inject nó vào làm gì rồi la

lam vung lau lam · 6/10/20

Thích Màu Hường đã nói:
Cái plugin, hook anh đưa ra là ví dụ điển hình của OOP đó. Anh nói FP ưu việt hơn sao không giải quyết được mà phải lôi plugin, hook vào trong khi cái này vốn là nhờ các tính chất của OOP.

tôi đang đọc cái đéo gì thế này.

Thích Màu Hường · 6/10/20

lam vung lau lam đã nói:
tôi đang đọc cái đéo gì thế này.

Thêm ví dụ cho rõ, nhìn xem người ta có cần interface, kế thừa không...

https://martinfowler.com/eaaCatalog/plugin.html
http://stevenblack.com/articles/hooks-and-anchors/

naiveryan · 6/10/20

^
Cái câu print_info trên kia dùng Derive (with Trait/Typeclass) và Generic nhé ai lại đi if else, do cách ông lam vung lau nam impl ban đầu cũng ko tốt thôi.

meohen2109 · 6/10/20

rosario_1 đã nói:
Sau khi tìm hiểu và đọc trên mạng các bài về FP và OOP thì tớ quyết định

1) Từ bỏ OOP. Rất chân thành cảm ơn các bạn đã chửi tớ trong topic này. Ít ra tớ đã thông não được tại sao lại phải immutable. Cho những bạn nào từng như tớ thì có thể ngắn gọn thế này, mọi thứ là value thay vì pointer giúp cho composition là cái hay gặp nhất nó trở nên đơn giản đi rất rất nhiều, thay vì cả 1 đống interface chỉ với mỗi tách mục đích tách method ra.

2) Nếu bây giờ theo FP thì nên học ngôn ngữ gì, kiếm sách nào để đọc?

Cảm ơn các bạn 1 lần nữa.

cua khét thế nhỉ

tornado · 6/10/20

Đọc mấy bác tranh luận hay, mặc dù chả hiểu mấy.

Nipin · 6/10/20

lyokha114 đã nói:
Tại sao ? Class Monkey, Class Forest là 2 class riêng biệt, lý do gì inject instance m1 lại phải inject cả f1 vậy bác ??

có biết cái câu nói ấy là của ai không mà đã vội bình luận =))

)

để tôi trích nguyên văn câu đó ra cho mà đi tìm hiểu:

The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana and the entire jungle.

thảo luận OOP hay FP

Các Voz Dev thuộc trường phái nào ?

OOP class ông đẻ ra class cha, class cha đẻ ra class con, class con đẻ ra class cháu....

FP cần kết quả ? => gọi Function A. Cần lọc kết quả ? => Gọi Function B trong Function A.

OOP với FP là cái quái gì ???

Freestyle, ra kết quả là đc.

Junior Member

Junior Member

Member

Junior Member

Junior Member

Junior Member

Member

Member

Junior Member

Junior Member

Member

Junior Member

Member

Junior Member

Junior Member

Member

Đã tốn tiền

Member

Member

Member

Chủ đề tương tự

Thống kê chủ đề

Chia sẻ trang này