thảo luận OOP hay FP | theNEXTvoz…

xshatter said:

FP nhanh gọn lẹ, cơ mà code hơi dơ xíu, chịu khó thì vẫn ổn.

Sent using vozFApp

buonnguqua said:

Thằng nào kế thừa mớ này sau khi các ông nghỉ chán muốn đập đầu vào tường

xshatter said:

FP nhanh gọn lẹ, cơ mà code hơi dơ xíu, chịu khó thì vẫn ổn.

Sent using vozFApp

xshatter said:

FP nhanh gọn lẹ, cơ mà code hơi dơ xíu, chịu khó thì vẫn ổn.

Sent using vozFApp

Quynh 123 said:

Dơ hay không thì do leader tổ chức dự án chia tree có logic hay không thôi mà. Nếu viết Docs để lại cho mấy người sau vào thì cũng khoẻ cho mấy ông đó.

VietNamVoDichAFF said:

cái gì cũng đỗ tại leader thế

soihoang said:

TLDR: functional core, imperative shell

xshatter said:

FP nhanh gọn lẹ, cơ mà code hơi dơ xíu, chịu khó thì vẫn ổn.

Sent using vozFApp

cugiametruyen85 said:

Sounds good, doesn't work

Quynh 123 said:

Dơ hay không thì do leader tổ chức dự án chia tree có logic hay không thôi mà. Nếu viết Docs để lại cho mấy người sau vào thì cũng khoẻ cho mấy ông đó.

hoangbaovu said:

Chắc cái core React dơ lắm, core team bỏ OOP convert sang FP rồi mà

naiveryan said:

"Dơ" là sao nhỉ, cho cái ví dụ đi bạn

naiveryan said:

^
Phân hoạch là sao? Là extract một đoạn logic ra rất nhiều đoạn code nhỏ ấy hả?

Nipin said:

lol hôm nọ thằng bạn dùng react làm ví dụ cho FP đã bị tôi chửi cho thối mặt, vào đây lại thấy các ý kiến tương tự =)

dùng FP của js vốn nát như cứt rồi suy ra "FP hoá ra cũng chỉ thế" thì khác kẹc gì thầy bói xem voi. Muốn xem nó có hiệu quả hay không thì dùng thử elixir, F# cho biết mùi, khá dễ học mà thực dụng.

Quynh 123 said:

Giờ vào làm thực tập đụng phải project mà cỡ chục người viết, éo ai thống nhất, quản lý gì cả nên giờ đống shitcode nó nhìn vô là mún ỉa chảy.

Nhưng biết thế nào giờ, refactor thì không đủ lv. Mà càng viết thêm thì lại khác nào ị thêm dòng shit code đó.

nickdabiband said:

Vãi bác kia bảo fp dơ. Bác thử tham gia các pj mà code thuần fp thử đi (không có for loop, không có side effect), code bằng scala/haskel mình thấy đẹp hơn cả OOP. Hình như nhiều bác ở đây k phân biệt được FP và imperative programming thì phải. Code FP đúng cực, dài, đẹp chứ k phải ngắn và dơ đâu

cugiametruyen85 said:

Chính vì vậy mới thấy cái hay của statically typed language, càng explicitly càng tốt. Project tầm 4 người trở lên mà không có type thì kiểu gì cũng nát. BE cứ Java, C#, FE cứ Typescript thì project bao nhiêu người cũng cân hết

.
Còn anh nào bảo "quan trọng người code" chứ ngôn ngữ nào cũng như nhau thì hoặc là chưa vào dự án nhiều người, hoặc chưa code 1 ngôn ngữ static đủ lâu bao giờ

xshatter said:

FP nhanh gọn lẹ, cơ mà code hơi dơ xíu, chịu khó thì vẫn ổn.

Sent using vozFApp

staedtler said:

Dơ hay không do bản thân đép đó thôi bạn.

staedtler said:

Dơ hay không do bản thân đép đó thôi bạn.

staedtler said:

Dơ hay không do bản thân đép đó thôi bạn.

tornado said:

Java với Python có code FP được không các thầy?

cugiametruyen85 said:

Thôi bạn bớt bớt đi, cái lập luận này nghe riết nhàm luôn, làm dev mà tư duy self attribution vkl. Do dev là thế nào, mỗi ngôn ngữ có điểm yếu điểm mạnh khác nhau, ecosystem khác nhau , convention khác nhau, văn hóa cũng khác nhau. Dev chỉ là 1 trong các yếu tố thôi bạn ơi, làm dev thì tư duy nhiều biến vào

.

Supersoyx said:

OOp thì tận dụng được cái kế thừa. Nhưng reuse khó, sửa thì impact ra nhiều thứ.

honeyfox said:

Có viết nhầm chỗ nào ko vậy, mục đích chính của kế thừa là để reuse mà

Supersoyx said:

Thì nó phải quảng cáo vậy người ta mới sài chứ. Có thằng nào chê sp của mình đâu. Bạn tìm hiểu khái niệm monkey hold banada and forest sẽ hiểu oop ko phải để reuse

honeyfox said:

Ý là vụ "“you don’t have to set up a stateful gorilla to hold the banana first.” đó hả?

honeyfox said:

Có viết nhầm chỗ nào ko vậy, mục đích chính của kế thừa là để reuse mà

ngolebaotrung said:

Mục đích chính của kế thừa ko phải là reuse

nickdabiband said:

Vãi bác kia bảo fp dơ. Bác thử tham gia các pj mà code thuần fp thử đi (không có for loop, không có side effect), code bằng scala/haskel mình thấy đẹp hơn cả OOP. Hình như nhiều bác ở đây k phân biệt được FP và imperative programming thì phải. Code FP đúng cực, dài, đẹp chứ k phải ngắn và dơ đâu

naiveryan said:

Sai rồi bạn ơi, FP = ngắn + đẹp cơ.

Mà FP vs imperative là sao đây nữa bạn, pure FP nó là declarative.

naiveryan said:

Sai rồi bạn ơi, FP = ngắn + đẹp cơ.

Mà FP vs imperative là sao đây nữa bạn, pure FP nó là declarative.

tthixk said:

tôi đoán thím chỉ coi clip chưa đụng proj fp bao giờ. Mấy cái clip nhìn thì hay chứ làm thật thì khá mệt đó.

fp thì function ngắn nhưng nhiều, code dài hơn. Immutable cũng làm code dài hơn, no early return cũng làm code dài hơn. Follow monad cũng làm code dài hơn (nếu ko có lib hỗ trợ tận răng). Không for loop mà phải recursive cũng làm code dài hơn.

Ví dụ đoạn code đơn giản: func A(n). Nếu n là 0 thì return 0, nếu n%2==0 thì result là 2n, nếu n%3==0 thì result là 5n, nếu cả 2 thì là 10n. Code bình thường chỉ 5 dòng, thím code kiểu immutable - no early return xem có dài ko.

fizzBuzz a
    | a == 0 = 0
    | mod2 == 0 = 2*a
    | mod3 == 0 = 5*a
    | mod2 == 0 && mod3 == 0 = 10*a
    | otherwise = a
    where mod2 = a `mod` 2
          mod3 = a `mod` 3

T.Dark said:

Thế này có được không nhỉ

Code:

fizzBuzz a
    | a == 0 = 0
    | mod2 == 0 = 2*a
    | mod3 == 0 = 5*a
    | mod2 == 0 && mod3 == 0 = 10*a
    | otherwise = a
    where mod2 = a `mod` 2
          mod3 = a `mod` 3

tthixk said:

tôi đoán thím chỉ coi clip chưa đụng proj fp bao giờ. Mấy cái clip nhìn thì hay chứ làm thật thì khá mệt đó.

fp thì function ngắn nhưng nhiều, code dài hơn. Immutable cũng làm code dài hơn, no early return cũng làm code dài hơn. Follow monad cũng làm code dài hơn (nếu ko có lib hỗ trợ tận răng). Không for loop mà phải recursive cũng làm code dài hơn.

Ví dụ đoạn code đơn giản: func A(n). Nếu n là 0 thì return 0, nếu n%2==0 thì result là 2n, nếu n%3==0 thì result là 5n, nếu cả 2 thì là 10n. Code bình thường chỉ 5 dòng, thím code kiểu immutable - no early return xem có dài ko.

nickdabiband said:

Đẹp thôi. Còn mình không thấy ngắn, so với kiểu code tự do, code có thêm ràng buộc thì nó phải dài hơn thôi.

Mình có nói FP là imperative à ?

tthixk said:

tôi đoán thím chỉ coi clip chưa đụng proj fp bao giờ. Mấy cái clip nhìn thì hay chứ làm thật thì khá mệt đó.

fp thì function ngắn nhưng nhiều, code dài hơn. Immutable cũng làm code dài hơn, no early return cũng làm code dài hơn. Follow monad cũng làm code dài hơn (nếu ko có lib hỗ trợ tận răng). Không for loop mà phải recursive cũng làm code dài hơn.

Ví dụ đoạn code đơn giản: func A(n). Nếu n là 0 thì return 0, nếu n%2==0 thì result là 2n, nếu n%3==0 thì result là 5n, nếu cả 2 thì là 10n. Code bình thường chỉ 5 dòng, thím code kiểu immutable - no early return xem có dài ko.

naiveryan said:

Lol cái đề bài này rơi vào đúng điểm mạnh của FP là pure function mà b lại bảo code fp ko ngắn k đẹp á? Tôi tắt máy lên giương r mà code haskell thì sẽ ngắn hơn bạn trên kia, conditional matching luôn ko cần where.

T code fp năm 2018 rồi, hiện tại k dùng 100% fp nhưng nếu được thì vẫn ap vào code.

Ko lại bảo tôi code bằng youtube

tthixk said:

Ví dụ đoạn code đơn giản: func A(n). Nếu n là 0 thì return 0, nếu n%2==0 thì result là 2n, nếu n%3==0 thì result là 5n, nếu cả 2 thì là 10n. Code bình thường chỉ 5 dòng, thím code kiểu immutable - no early return xem có dài ko.

a 0 = 0; a n | n `mod` 6 == 0 = 10*n | n `mod` 2 == 0 = 2 *n | n `mod` 3 == 0 = 5*n; a n = n

nguyenna said:

haskell cheat thành 1 dòng nè.

Code:

a 0 = 0; a n | n `mod` 6 == 0 = 10*n | n `mod` 2 == 0 = 2 *n | n `mod` 3 == 0 = 5*n; a n = n

naiveryan said:

Thì bạn bảo phân biệt fp với imperative, tưởng bạn nghĩ 2 đứa này chung đường ). Ý bạn là do immutable nên phải code dài hay gì? Chứ t thấy ngắn, đã từng code java, haskell, rust. Ko biết bạn bảo ntnao thì ngắn?

nguyenna said:

haskell cheat thành 1 dòng nè.

Code:

a 0 = 0; a n | n `mod` 6 == 0 = 10*n | n `mod` 2 == 0 = 2 *n | n `mod` 3 == 0 = 5*n; a n = n

tthixk said:

chắc mấy thím ko hiểu ý tôi.
If n == 0 then return 0
r := n
If n % 2 == 0 then r *= 2
If n % 3 == 0 then r *= 5
If n % 5 == 0 then r *= 11
Return r

tthixk said:

hiện tôi phải nhét hết vào map rồi reduce (fold) cái map đó, code reviewer nhìn vào thấy khó hiểu, cuối cùng convert thành mutable luôn cho dễ hiểu.

tthixk said:

Code này chuyển qua fp immuta làm sao để ngắn + đẹp.

ahw n | n == 0             = 0
      | n `mod` 2 == 0     = 2*n
      | n `mod` 3 == 0     = 5*n
      | n `mod` 5 == 0     = 11*n

nguyenna said:

Ừ đúng là không hiểu thật vì
i) cái mô tả ban đầu của thím không khớp với cái
pseudo code thím minh hoạ
ii) hàm này có vấn đề là nó không xác định ở các giá trị n bội của 7, 13, ...
iii) thứ ba là
??


Nếu thím đặt tên hàm này là ahw (another homework), code này chuyển qua FP

Code:

ahw n | n == 0             = 0
      | n `mod` 2 == 0     = 2*n
      | n `mod` 3 == 0     = 5*n
      | n `mod` 5 == 0     = 11*n

Nipin said:

Code:

defmodule A do
  def a(x) do
    cond do
      x == 0 -> 0
      rem(x, 6) == 0 -> x * 10
      rem(x, 3) == 0 -> x * 5
      rem(x, 2) == 0 -> x * 2
      true -> x
    end
  end
end
IO.puts A.a(2)

cũng bình thường có gì khó khăn đâu nhỉ? cái dòng x == 0 -> 0 kia thừa cơ mà để vào sợ requirement của bạn thay đổi =)

à mà đọc xuống dưới thì thấy đã sửa đề =)
mời bạn trên viết lại cho tử tế. tôi đéo rảnh ngồi "hiểu ý bạn".

edit: à mà lâu không code elixir quên mẹ luôn pattern + guard, đáng lẽ phải viết thế này:

Ruby:

defmodule A do
  def a(x) when rem(x, 6) == 0, do: x * 10
  def a(x) when rem(x, 2) == 0, do: x * 2
  def a(x) when rem(x, 3) == 0, do: x * 5
  def a(x), do: x
end
IO.puts A.a(2)

Nipin said:

mẹ kiếp tưởng nói là loop các kiểu còn nghĩ là thằng tranh luận tử tế, hoá ra là thằng noob nghĩ FP không có assigment, bó tay

cái kia thì viết js cũng được cóc cần đổi ngôn ngữ:

Code:

r = n
r = n % 2 == 0 ? r * 2 : r
r = n % 3 == 0 ? r * 5 : r
r = n % 5 == 0 ? r * 11 : r

elixir thì verbose hơn tí, phải viết kiểu x = if x % 2 == 0, do: x * 2, else: x nhưng về cơ bản thì không khác gì

mấy thằng khác không có rebinding thì vất vả hơn phải đặt tên khác (nhiều thằng đặt là x', x'')

Code:

x1 = x % 2 == 0 ? x * 2 : x
x2 = x % 3 ==0 ? x1 * 5 : x1
...

vậy thôi có kẹc gì mà phải hỏi.

mà cậu làm người ta ghét vì vừa kéo xuống một đoạn đã đổi mẹ đề (thông số đã khác), đúng kiểu lươn lẹo, đéo tự nhận lỗi lại đi bảo người khác đéo hiểu ý mình.

nói chung tôi ghét kiểu mấy con lợn như thế, cho nên xin phép tôi miễn phản hồi tiếp.

nguyenna said:

Ừ đúng là không hiểu thật vì
i) cái mô tả ban đầu của thím không khớp với cái
pseudo code thím minh hoạ
ii) hàm này có vấn đề là nó không xác định ở các giá trị n bội của 7, 13, ...
iii) thứ ba là
??


Nếu thím đặt tên hàm này là ahw (another homework), code này chuyển qua FP

Code:

ahw n | n == 0             = 0
      | n `mod` 2 == 0     = 2*n
      | n `mod` 3 == 0     = 5*n
      | n `mod` 5 == 0     = 11*n

Nipin said:

mẹ kiếp tưởng nói là loop các kiểu còn nghĩ là thằng tranh luận tử tế, hoá ra là thằng noob nghĩ FP không có assigment, bó tay

cái kia thì viết js cũng được cóc cần đổi ngôn ngữ:

Code:

r = n
r = n % 2 == 0 ? r * 2 : r
r = n % 3 == 0 ? r * 5 : r
r = n % 5 == 0 ? r * 11 : r

elixir thì verbose hơn tí, phải viết kiểu x = if x % 2 == 0, do: x * 2, else: x nhưng về cơ bản thì không khác gì

mấy thằng khác không có rebinding thì vất vả hơn phải đặt tên khác (nhiều thằng đặt là x', x'')

Code:

x1 = x % 2 == 0 ? x * 2 : x
x2 = x % 3 ==0 ? x1 * 5 : x1
...

vậy thôi có kẹc gì mà phải hỏi.

mà cậu làm người ta ghét vì vừa kéo xuống một đoạn đã đổi mẹ đề (thông số đã khác), đúng kiểu lươn lẹo, đéo tự nhận lỗi lại đi bảo người khác đéo hiểu ý mình.

nói chung tôi ghét kiểu mấy con lợn như thế, cho nên xin phép tôi miễn phản hồi tiếp.

zulu said:

Ơ nhưng tính ra code này có khác j ý tưởng xài kiểu thông thường? Chưa thể hiện đc fp rõ lắm.

via nextVOZ for iPhone

tthixk said:

tôi ko biết haskell, thím cho keyword cách thím làm đc ko? Khi input n = 10 thì kq là bn?

pseudo code sẽ ra 10*2*11=220

xshatter said:

chịu khó viết bớt dơ lại xíu, cơ mà lên github xem mấy dự án của bọn FP thì phê khỏi nói

nickdabiband said:

Ví dụ bạn có mảng a gồm 100 phần tử , bạn muốn thay đổi phần tử thứ 23, nếu muốn code immutable mà performance tốt thì sẽ rất cực, trong khi code bt chỉ cần a[23]=... là được.
Java mình thấy dài chủ yếu do cách đặt tên của nó, kotlin tương tự java nhưng khá ngắn. Rust cũng ngắn, chỉ có cái ownership của nó hơi rắc rối chứ cũng k dài.

Supersoyx said:

OOp thì tận dụng được cái kế thừa. Nhưng reuse khó, sửa thì impact ra nhiều thứ.

FP thì đơn giản hơn, dễ debug, unittest, reuse code. FP thể hiện đúng cái bản chất của vạn vât. Mọi thứ trên đời này đều vận hành theo hàm. Ví dụ p=mv, e=mc2...OOp được ưa thích bởi tư duy người hơn

naiveryan said:

Cái này thì tôi công nhận, muốn thay đổi phần tử kiểu này thì code immutable sẽ dài hơn. Chấp nhận tradeoff thôi. Nhưng tổng thể lại thì fp/haskell tôi thấy vẫn ngắn, nếu ko phải hạng 1 thì phải là top 5. Riêng mấy cái higher order đã làm code ngắn gọn và dễ hiểu hơn rất nhiều rồi (so với bọn nn ko có).

rosario_1 said:

Ví dụ nếu định nghĩa đầu bao gồm mắt, mũi, mồm, miệng chẳng hạn, thì ở OOP giao cho bạn mắt chẳng hạn thì bạn phải lắp đúng nó vào cái đầu thì mới ok, chứ lắp vào chân thì không được. Trong khi FP thì mắt lắp vào chân vô tư.

Đến câu FP thể hiện đúng bản chất vạn vật tớ chỉ cười thôi. Với tớ OOP mới là thể hiện đúng bản chất của vạn vật. Ví dụ 1 người chẳng hạn, ở FP chỉ đơn giản là mấy cái bộ phận chân tay mặt mũi. Nhưng với OOP thì người không chỉ là các bộ phận rời rạc như thế mà còn bao gồm cả những tương tác ràng buộc giữa các bộ phận ấy với nhau nữa. Đó là lý do người ta thấy FP không đủ nên mới phải nghĩ ra OOP. Chờ nghe phản biện của bạn.

Pianist said:

Các pro FP cho hỏi, làm thế nào để ngôn ngữ thuần FP đạt hiệu quả tốt.
Ví dụ đơn giản là tính fibonaci thứ n: f(n) = f(n-1) + f(n-2)
Với ngôn ngữ ko thuần FP, thì việc dùng đệ quy thay cho for (theo nguyên tắc immutable var) sẽ:
1. Luôn tạo thêm biến tham chiếu mới, nhồi vào stack -> dùng nhiều mem hơn.
2. Khi tính f(n) thì f(n-2) được tính, khi tính f(n-1) thì f(n-2) lại tính tiếp -> chậm hơn.
Cần được khai sáng.

rosario_1 said:

Tớ không nghĩ là OOP làm ra để tận dụng cái kế thừa. OOP nâng cao sự chặt chẽ, dễ đọc dễ hiểu, mọi thứ phải vào đúng chỗ của nó mới vận hành được.

Ví dụ nếu định nghĩa đầu bao gồm mắt, mũi, mồm, miệng chẳng hạn, thì ở OOP giao cho bạn mắt chẳng hạn thì bạn phải lắp đúng nó vào cái đầu thì mới ok, chứ lắp vào chân thì không được. Trong khi FP thì mắt lắp vào chân vô tư.

Monkey Banana and Forest, thực ra design tốt thì sẽ không bị tình trạng đấy. Bạn hoàn toàn có thể làm y chang FP với OOP, có gì là khó.

Đến câu FP thể hiện đúng bản chất vạn vật tớ chỉ cười thôi. Với tớ OOP mới là thể hiện đúng bản chất của vạn vật. Ví dụ 1 người chẳng hạn, ở FP chỉ đơn giản là mấy cái bộ phận chân tay mặt mũi. Nhưng với OOP thì người không chỉ là các bộ phận rời rạc như thế mà còn bao gồm cả những tương tác ràng buộc giữa các bộ phận ấy với nhau nữa. Đó là lý do người ta thấy FP không đủ nên mới phải nghĩ ra OOP. Chờ nghe phản biện của bạn.

naiveryan said:

Cái này thì liên quan với OOP đây bạn?
Bạn có biết Typeclass của Haskell, Trait của Rust cũng cho phép bạn design by contract được ko?
Nó còn làm tốt hơn cả mớ bùi nhùi abstract class với cả interface trong OOP.

Còn cái kế thừa chính là 1 cái nguyên nhân dẫn tới cái meme ngta hay chê bana in jungle của OOP đó.

Public Class Monkey
{
    //Monkey Properties Only
    ...
}

Public Class Jungle
{
    //Jungle Properties Only
    ...
}

Public Class JungleMonkey : Monkey
{
    Public Jungle MonkeyJungle {get;set;}
}

rosario_1 said:

Làm sao mà nó làm tốt hơn được. Như tớ đã nói, để làm được đúng mắt chỉ có thể lắp được vào đầu mà không phải vào chân, thì mắt cần phải có thông tin về đầu. Bất kể bạn dùng cái khỉ gì đi chăng nữa thì nó cũng phải là như thế.

Tớ đọc ví dụ về Monkey in Jungle thấy rất buồn cười khi các bạn đổ tại nguyên nhân là do kế thừa. Cá nhân tớ cho rằng nguyên nhân không phải như vậy. Nếu bạn muốn dùng Monkey độc lập, cũng như Monkey thuộc về Jungle nào đấy, thì cách làm đúng phải là

C#:

Public Class Monkey
{
    //Monkey Properties Only
    ...
}

C#:

Public Class Jungle
{
    //Jungle Properties Only
    ...
}

C#:

Public Class JungleMonkey : Monkey
{
    Public Jungle MonkeyJungle {get;set;}
}

Nhưng ví dụ về Monkey Jungle bạn nói thì nó đặt tên Monkey thay vì JungleMonkey và muốn chỉ sử dụng 1 cái class bản chất là class Monkey trong ví dụ của tớ. Thế thì làm gì mà chả nát, và nguyên nhân nát là do người modelling data làm sai. OOP rất chặt chẽ, mọi thứ đòi hỏi phải chính xác.

Bạn bảo FP tốt hơn thì minh họa cụ thể như ví dụ của tớ đi, làm thế nào để thể hiện chuẩn xác quan hệ JungleMonkey là Monkey + thông tin về Jungle?

naiveryan said:

Cái việc mô phỏng của OOP ở trên có bạn giải thích rồi, ngta cố trừu tượng hoá bài toán cụ thể cùng input output function bằng mô hình object, cái này ngay từ đầu đã ko đúng với bản chất của Software Program rồi, bạn tin vào OOP như con vẹt ấy rồi tưởng nó là vạn vật gì đó -)).

hikaruu said:

Fp gần với tự nhiên , vì nó gần với tính bất biến của toán học, opp sinh ra do suy nghĩ lệch lac của con người thuở mới lập trình vote fn

naiveryan said:

Cái việc mô phỏng của OOP ở trên có bạn giải thích rồi, ngta cố trừu tượng hoá bài toán cụ thể cùng input output function bằng mô hình object, cái này ngay từ đầu đã ko đúng với bản chất của Software Program rồi, bạn tin vào OOP như con vẹt ấy rồi tưởng nó là vạn vật gì đó -)).

Pianist said:

Các pro FP cho hỏi, làm thế nào để ngôn ngữ thuần FP đạt hiệu quả tốt.
Ví dụ đơn giản là tính fibonaci thứ n: f(n) = f(n-1) + f(n-2)
Với ngôn ngữ ko thuần FP, thì việc dùng đệ quy thay cho for (theo nguyên tắc immutable var) sẽ:
1. Luôn tạo thêm biến tham chiếu mới, nhồi vào stack -> dùng nhiều mem hơn.
2. Khi tính f(n) thì f(n-2) được tính, khi tính f(n-1) thì f(n-2) lại tính tiếp -> chậm hơn.
Cần được khai sáng.

naiveryan said:

Tôi đang nói đến cái câu châm biếm " Bạn muốn một con khỉ, nhưng OOP sẽ đưa cho bạn một con khỉ đang cẩm quả chuối kèm cả khu rừng mà nó đang đứng trong đó". Lúc bạn muốn re-use cái gì trong OOP bạn sẽ gặp trường hợp tương tự phải mang cả class cha class con class chú theo.

Còn cái ví dụ của bạn tôi còn chẳng biết mục đích bạn viết ra để làm cái gì nữa bạn bảo tôi minh hoạ cái gì nhể. Bạn đưa ví dụ hay muốn tìm hiểu thì đưa bài cụ thể ra đây, đưa dăm ba cái class define vớ vẩn làm gì.

Nipin said:

https://rosettacode.org/wiki/Fibonacci_sequence#Elixir

thực ra thì nếu các bạn học quy hoạch động các kiểu rồi sẽ không bao giờ còn thắc mắc cái (2), thêm nữa thường FP nó có hỗ trợ tail cail optimization, chỉ cần bạn viết function hợp lý nó sẽ biến cái recursion thành loop. Đấy là tôi còn chưa nói vì FP phần lớn là immutable cho nên compiler có nhiều cách optimize hiệu quả hơn, mấy cái trivial example dạng này nó replace function call thành constant hết.

tất nhiên constant folding thì cái nontrivial compiler nào cũng làm, bàn về optimization thì mấy thằng ít tài nguyên như haskell các kiểu còn lâu mới so được c/c++ có mấy cái compiler như gcc hay clang đã được đầu tư vài triệu giờ phát triển vào.

btw, về chuyện tại sao mấy thằng dùng FP lại cocky hơn mấy thằng dùng OOP, thì ngay cả câu thắc mắc này đã làm tôi coi thường các bạn rồi. Bởi vì thực ra nó đơn giản vãi ra: thằng đíu nào dùng FP cũng đã từng dùng OOP, thấy không thoả mãn với công cụ mình dùng mới chuyển sang dùng các công cụ khác nó thấy hợp hơn. Ngược lại thì mấy thằng khen OOP phần lớn là được học sẵn OOP ở trường, ra ngoài đời làm code monkey mấy chục năm đéo phát triển, đéo tự học được cái gì, nếu có học thì cũng là do công ty ép học, hoặc là vì miếng ăn.

Tất nhiên bỏ miếng ăn vào mồm được là không sai, thâm niên OOP đúng là lương cao hơn mấy thằng chơi FP nhiều, cơ mà đến rosettacode các kiểu cũng đéo biết thì xin phép cho tôi khinh bỉ các bạn tiếp.

Nipin said:

https://rosettacode.org/wiki/Fibonacci_sequence#Elixir

thực ra thì nếu các bạn học quy hoạch động các kiểu rồi sẽ không bao giờ còn thắc mắc cái (2), thêm nữa thường FP nó có hỗ trợ tail cail optimization, chỉ cần bạn viết function hợp lý nó sẽ biến cái recursion thành loop. Đấy là tôi còn chưa nói vì FP phần lớn là immutable cho nên compiler có nhiều cách optimize hiệu quả hơn, mấy cái trivial example dạng này nó replace function call thành constant hết.

tất nhiên constant folding thì cái nontrivial compiler nào cũng làm, bàn về optimization thì mấy thằng ít tài nguyên như haskell các kiểu còn lâu mới so được c/c++ có mấy cái compiler như gcc hay clang đã được đầu tư vài triệu giờ phát triển vào.

btw, về chuyện tại sao mấy thằng dùng FP lại cocky hơn mấy thằng dùng OOP, thì ngay cả câu thắc mắc này đã làm tôi coi thường các bạn rồi. Bởi vì thực ra nó đơn giản vãi ra: thằng đíu nào dùng FP cũng đã từng dùng OOP, thấy không thoả mãn với công cụ mình dùng mới chuyển sang dùng các công cụ khác nó thấy hợp hơn. Ngược lại thì mấy thằng khen OOP phần lớn là được học sẵn OOP ở trường, ra ngoài đời làm code monkey mấy chục năm đéo phát triển, đéo tự học được cái gì, nếu có học thì cũng là do công ty ép học, hoặc là vì miếng ăn.

Tất nhiên bỏ miếng ăn vào mồm được là không sai, thâm niên OOP đúng là lương cao hơn mấy thằng chơi FP nhiều, cơ mà đến rosettacode các kiểu cũng đéo biết thì xin phép cho tôi khinh bỉ các bạn tiếp.

Pianist said:

Bạn gay gắt quá rồi đó, đừng cố tranh luận theo kiểu mỉa mai công kích như vậy. Thay vì chỉ nói chung chung thì hãy cho 1 ví dụ bằng coding thật sự tạo ra sự khác biệt khiến bạn "OOP vẹt" tâm phục đi.

Bạn chê người khác tin OOP như con vẹt. Nhưng chính bạn cũng đang tin vào FP mù quáng. Chê bôi theo kiểu, ồ à đọc được vài bài anti OOP xong lên đỉnh với FP, nghĩ OOP như rác rưởi. Hiện có rất nhiều trào lưu kiểu phá cách như vậy, lật đổ nền móng cũ. Dù bạn có chửi như thế nào, thì ngoài kia hàng tỉ project design theo OOP vẫn đang vận hành tốt, nhiều hơn FP rất nhiều. Nếu nó thực sự tệ, thì đã sụp đổ từ lâu rồi.

Cái vấn đề banana money, tại sao phải reuse code theo kiểu clone từ project cũ sang project mới vậy ? Chứng tỏ proj cũ tệ đến mức ko thể reuse theo kiểu dependency, người viết cũ ko đủ khả năng. Tôi tin là với FP, người viết ko thuần thục thì kiểu gì cũng sẽ gặp rắc rôi mà thôi.

Nhân tiện, bạn có thể nói rõ hơn về " bản chất của Software Program" là gì không ?

zulu said:

Tranh luận nhưng bạn nói mồm ko à. Chưa thấy đưa dẫn chứng cụ thể như bác oop kia.

via nextVOZ for iPhone

Nipin said:

https://rosettacode.org/wiki/Fibonacci_sequence#Elixir


tất nhiên constant folding thì cái nontrivial compiler nào cũng làm, bàn về optimization thì mấy thằng ít tài nguyên như haskell các kiểu còn lâu mới so được c/c++ có mấy cái compiler như gcc hay clang đã được đầu tư vài triệu giờ phát triển vào.


Tất nhiên bỏ miếng ăn vào mồm được là không sai, thâm niên OOP đúng là lương cao hơn mấy thằng chơi FP nhiều, cơ mà đến rosettacode các kiểu cũng đéo biết thì xin phép cho tôi khinh bỉ các bạn tiếp.

rosario_1 said:

Vấn đề ở chỗ tớ thấy bạn nói không đúng. Chuyện muốn 1 con khỉ nhưng nhận lại là 1 con khỉ cầm quả chuối kèm cả khu rừng tớ chửi hoài à. Nhưng chửi là phải chửi đúng, nguyên nhân không ở kế thừa. Nguyên nhân là do cái thằng code đầu tiên thay vì việc chia ra làm nhiều thành phần nhỏ rồi tổ hợp lại với nhau thì nó lại làm 1 cái bự dính vào nhau để rồi sau đó nếu chỉ cần 1 bộ phận nhỏ ở trong đấy thì không reuse lại được.

Minh họa là minh họa cho việc biểu diễn mọi thứ của vũ trụ tự nhiên dễ hiểu với OOP và hoàn toàn không bị vấn đề cần khỉ được khỉ với cả khu rừng. Ví dụ là bài toán cụ thể để từ từ tớ nghĩ đã.

naiveryan said:

Dẫn chứng đek gì define cái class với signature?

Thích vọc code thì đưa hẳn đề bài.
Như cái đề gì tôi có trả lời trên kia kìa, đọc code FP có phải dễ hiểu dễ nắm hơn code immutable chưa? Chưa kể còn ngắn + đẹp nha.

calc 0 = 0
calc n
| n mod 6 == 0 = 10 * n
| n mod 3 == 0 = 5 * n
| n mod 2 == 0 = 2 * n
| otherwise = n

zulu said:

It ra ngta còn có cái để dẫn chứng. Còn anh chê đủ thứ nhưng nói mồm chửi đổng ko à.


Còn cái bài anh nói dẫn chứng ngắn gọn kia là bài này ở mấy page trước á hả? Thôi chứ hài vkl. Bài đó nhảm nhí có nói đc thế mạnh hay rõ ràng chỉ thuộc về fp đâu. Vì bài này mà anh anti mù quáng OOP luônn hở? Cực đoan vkl.

Công nhận là nó ngắn gọn , tôi cũng thích. Tôi vẫn xài FP bình thường, chỉ ko anti OOP cực đoan như anh thôi.

naiveryan said:

Thích thì chê thôi.

Cái bài trên kia tôi code để cm với bạn kia là code fp ngắn + đẹp (và expressiveness cao chưa kể vào). Cái tôi muốn nói là cho đề bài cụ thể mới nói ch đc chứ cho 3 cái class define bảo tôi phản biện cái gì trong đó -))

Mà bạn ko hiểu ý tôi cứ quote lạc đề làm gì?

zulu said:

Riêng bài đó ngắn nhưng nó đủ để anh anti cực đoan thì khác nào có thằng như anh, nó cuồng OOP rồi anti cực đoan FP.

Quay về vấn đề lúc đầu a mang: cần con khỉ mà nó đưa con khi cầm chuối vs rừng j j đó. Ông kia ít ra manng 1 luân điểm thiết kế và cách xài sai . Chưa bàn đến đúng sai, nhưng ít ra ngta có ý. Anh có ý j nói lại thì nói ra để thảo luận, chứ chửi đổng thích thì chê ai mà ko làm đc.

naiveryan said:

Cái việc mô phỏng của OOP ở trên có bạn giải thích rồi, ngta cố trừu tượng hoá bài toán cụ thể cùng input output function bằng mô hình object, cái này ngay từ đầu đã ko đúng với bản chất của Software Program rồi, bạn tin vào OOP như con vẹt ấy rồi tưởng nó là vạn vật gì đó -)).

naiveryan said:

"Dơ" là sao nhỉ, cho cái ví dụ đi bạn

naiveryan said:

^
Phân hoạch là sao? Là extract một đoạn logic ra rất nhiều đoạn code nhỏ ấy hả?

naiveryan said:

Sai rồi bạn ơi, FP = ngắn + đẹp cơ.

Mà FP vs imperative là sao đây nữa bạn, pure FP nó là declarative.

naiveryan said:

Lol cái đề bài này rơi vào đúng điểm mạnh của FP là pure function mà b lại bảo code fp ko ngắn k đẹp á? Tôi tắt máy lên giương r mà code haskell thì sẽ ngắn hơn bạn trên kia, conditional matching luôn ko cần where.

T code fp năm 2018 rồi, hiện tại k dùng 100% fp nhưng nếu được thì vẫn ap vào code.

Ko lại bảo tôi code bằng youtube

naiveryan said:

Cái đề trên bạn rẽ nhánh thông thường mới dài chứ matching pattern là đẹp nhất rồi. Nói về khoản ngắn gọn thì haskell vô địch, nhiều khi ngắn quá đâm ra khó đọc

naiveryan said:

Thì bạn bảo phân biệt fp với imperative, tưởng bạn nghĩ 2 đứa này chung đường ). Ý bạn là do immutable nên phải code dài hay gì? Chứ t thấy ngắn, đã từng code java, haskell, rust. Ko biết bạn bảo ntnao thì ngắn?

naiveryan said:

Đề bài nhập môn thôi mà cứ phải nói dông dài. Đây code haskell

Code:

calc 0 = 0
calc n
  | n `mod` 6 == 0 = 10 * n
  | n `mod` 3 == 0 = 5 * n
  | n `mod` 2 == 0 = 2 * n
  | otherwise = n

Ở trên cũng có mấy bạn code ko đúng vì phải để case mode 6 lên trên mới chính xác (theo ý tôi hiểu đề bài).

Gì chớ mấy cái bài input là số thì fp ăn chặt rồi bạn ơi. Mấy cái pure function bạn đem assignment với cả if else vào chưa nói đến dài ngắn chứ expressiveness đã thua pattern matching rồi.

naiveryan said:

Cái này thì tôi công nhận, muốn thay đổi phần tử kiểu này thì code immutable sẽ dài hơn. Chấp nhận tradeoff thôi. Nhưng tổng thể lại thì fp/haskell tôi thấy vẫn ngắn, nếu ko phải hạng 1 thì phải là top 5. Riêng mấy cái higher order đã làm code ngắn gọn và dễ hiểu hơn rất nhiều rồi (so với bọn nn ko có).

naiveryan said:

Cái này thì liên quan với OOP đây bạn?
Bạn có biết Typeclass của Haskell, Trait của Rust cũng cho phép bạn design by contract được ko?
Nó còn làm tốt hơn cả mớ bùi nhùi abstract class với cả interface trong OOP.

Còn cái kế thừa chính là 1 cái nguyên nhân dẫn tới cái meme ngta hay chê bana in jungle của OOP đó.

naiveryan said:

Tôi đang nói đến cái câu châm biếm " Bạn muốn một con khỉ, nhưng OOP sẽ đưa cho bạn một con khỉ đang cẩm quả chuối kèm cả khu rừng mà nó đang đứng trong đó". Lúc bạn muốn re-use cái gì trong OOP bạn sẽ gặp trường hợp tương tự phải mang cả class cha class con class chú theo.

Còn cái ví dụ của bạn tôi còn chẳng biết mục đích bạn viết ra để làm cái gì nữa bạn bảo tôi minh hoạ cái gì nhể. Bạn đưa ví dụ hay muốn tìm hiểu thì đưa bài cụ thể ra đây, đưa dăm ba cái class define vớ vẩn làm gì.

naiveryan said:

Cái việc mô phỏng của OOP ở trên có bạn giải thích rồi, ngta cố trừu tượng hoá bài toán cụ thể cùng input output function bằng mô hình object, cái này ngay từ đầu đã ko đúng với bản chất của Software Program rồi, bạn tin vào OOP như con vẹt ấy rồi tưởng nó là vạn vật gì đó -)).

naiveryan said:

lol bài đó làm sao đủ để anti. Tôi ko thích viết dài dòng, cứ để mấy pro trong đây đưa từ từ vấn đề ra thoi rồi mới chê tiếp.

Cái ví dụ anh trên kia đưa nó chưa thể coi là ví dụ đc, vài ba dòng class signature.

tthixk said:

Nói làm gì vơi các thành phần cuồng. Về bản chất lập trình là giống nhau, fp và oop chỉ khác cách implement. Khỉ chuối vẫn gặp trong fp khi implement hof ngu thôi. Vấn đề khỉ chuối theo tôi hiểu nó để ví dụ cho việc over inherite trong oop chứ ko phải là paint point của oop.

fp xử lý data tốt, immutable và pure function giúp debug dễ thở hơn, tránh race data khi làm multi thread. Fp có monad để xử lý data tự nhiên, theo luồng suy nghĩ nhưng thực tế thì người mới vào nhìn mớ monad trong proj đều á ớ người.

Oop thiết kế tự nhiên hơn, gần với cuộc sống thật hơn. Đặc biệt khi làm game, tôi khá chắc kèo nếu lấy fp để làm game sẽ như cc.

Vào thớt lập trình voz mà thấy như vào box iphone tinh tế

tthixk said:

Nói làm gì vơi các thành phần cuồng. Về bản chất lập trình là giống nhau, fp và oop chỉ khác cách implement. Khỉ chuối vẫn gặp trong fp khi implement hof ngu thôi. Vấn đề khỉ chuối theo tôi hiểu nó để ví dụ cho việc over inherite trong oop chứ ko phải là pain point của oop.

fp xử lý data tốt, immutable và pure function giúp debug dễ thở hơn, tránh race data khi làm multi thread. Fp có monad để xử lý data tự nhiên, theo luồng suy nghĩ nhưng thực tế thì người mới vào nhìn mớ monad trong proj đều á ớ người.

Oop thiết kế tự nhiên hơn, gần với cuộc sống thật hơn. Đặc biệt khi làm game, tôi khá chắc kèo nếu lấy fp để làm game sẽ như cc.

Vào thớt lập trình voz mà thấy như vào box iphone tinh tế

trgiangvp3 said:

Tại sao chưa thể coi là ví dụ?
Thế anh đưa ra câu chuyện về con khỉ cầm chuối, anh đã hiểu vấn đề mà câu nói đó đề cập là gì chưa?
Tôi cũng nghĩ giống @rosario_1 : vấn đề con khỉ cầm chuối sẽ giải quyết được bằng thiết kế hợp lý.
Còn anh nói bản chất của lập trình là các phép toán thì thôi xin lỗi nhé, sai con mẹ nó rồi. Bản chất của lập trình phải là các phép xử lý bit nhé, nếu nói theo lối tư duy của anh )

naiveryan said:

Phải nhắc lại bao nhiêu lần là dăm ba cái dòng code define class + signature ra thì cái đoạn đó có cái gì để ng khác phản biện. Code thì phải có logic giải quyết problem nào hẳn hoi, anh đưa cái class define ra rồi bảo đây, OOP đây, xịn đây, ko bị bad design đây... nhưng mấy cái đó tôi ko code OOP vẫn cứ làm được.

naiveryan said:

Phải nhắc lại bao nhiêu lần là dăm ba cái dòng code define class + signature ra thì cái đoạn đó có cái gì để ng khác phản biện. Code thì phải có logic giải quyết problem nào hẳn hoi, anh đưa cái class define ra rồi bảo đây, OOP đây, xịn đây, ko bị bad design đây... nhưng mấy cái đó tôi ko code OOP vẫn cứ làm được.

naiveryan said:

Phải nhắc lại bao nhiêu lần là dăm ba cái dòng code define class + signature ra thì cái đoạn đó có cái gì để ng khác phản biện. Code thì phải có logic giải quyết problem nào hẳn hoi, anh đưa cái class define ra rồi bảo đây, OOP đây, xịn đây, ko bị bad design đây... nhưng mấy cái đó tôi ko code OOP vẫn cứ làm được.

Pianist said:

Ví dụ đơn giản là tính fibonaci thứ n: f(n) = f(n-1) + f(n-2). Với ngôn ngữ ko thuần FP, thì việc dùng đệ quy thay cho for (theo nguyên tắc immutable var) sẽ:
1. Luôn tạo thêm biến tham chiếu mới, nhồi vào stack -> dùng nhiều mem hơn.
2. Khi tính f(n) thì f(n-2) được tính, khi tính f(n-1) thì f(n-2) lại tính tiếp -> chậm hơn.
Cần được khai sáng.

nguyenna said:

FP ở khắp nơi trong các languages mà các bác còn lo thái độ bỏ cũ, nới mới các thứ . Ví dụ đâu xa list comprehension của python là khái niệm của fp, các hàm map, filter, reduce, zip là mượn từ ML/Haskell. Rồi còn lambda expressions; mà Java 8, C++ 11 mới chịu đưa vào. Tất cả chỉ để code hướng tới immutable. Có thể là đôi khi các bác cũng code FP mà không biết đấy -> nên học để thành better developer. Bác nào cực tả / cực hữu quá thì xem Scala, F# để dung hoà.

Nếu thím tính theo f(n) = f(n-1) + f(n-2) thì ngôn ngữ FP hay không FP cũng bị O(2^n) chặn rồi. Nên ví dụ như này thì viết tail recursive (với ngôn ngữ có laziness như Haskell còn có kiểu viết fancy hơn). Cái khác là với FP thuần thì mặc định theo chuẩn sẽ có tail call optimization dẫn tới stack sử dụng là constant. Thậm chí nó còn biên dịch ra for loop như thím luôn. Ngôn ngữ khác có thể có optimisation có thể không, như C khi biên dịch thêm -O2, python thì dùng third party.

lol hôm nọ thằng bạn dùng react làm ví dụ cho FP đã bị tôi chửi cho thối mặt, vào đây lại thấy các ý kiến tương tự =)

FP thể hiện đúng cái bản chất của vạn vât. Mọi thứ trên đời này đều vận hành theo hàm.

Fp gần với tự nhiên , vì nó gần với tính bất biến của toán học

When do you choose functional programming over object oriented?

• Object-oriented languages are good when you have a fixed set of operations on things, and as your code evolves, you primarily add new things. This can be accomplished by adding new classes which implement existing methods, and the existing classes are left alone.
• Functional languages are good when you have a fixed set of things, and as your code evolves, you primarily add new operations on existing things. This can be accomplished by adding new functions which compute with existing data types, and the existing functions are left alone.

• Adding a new operation to an object-oriented program may require editing many class definitions to add a new method.
• Adding a new kind of thing to a functional program may require editing many function definitions to add a new case

naiveryan said:

Phải nhắc lại bao nhiêu lần là dăm ba cái dòng code define class + signature ra thì cái đoạn đó có cái gì để ng khác phản biện. Code thì phải có logic giải quyết problem nào hẳn hoi, anh đưa cái class define ra rồi bảo đây, OOP đây, xịn đây, ko bị bad design đây... nhưng mấy cái đó tôi ko code OOP vẫn cứ làm được.

rosario_1 said:

Sorry nghe anh nói thế tôi tò mò vừa mới đang đọc thử về FP nhưng chưa thấy đâu. Tôi đang tìm hiểu cách biểu diễn kế thừa trong OOP sang FP là như thế nào. Anh bảo ví dụ thì giờ tôi nêu cụ thể, nếu anh thông não được thì xin cảm ơn anh nhiều.

Vấn đề hết sức đơn giản là thế này, tôi có base class Customer với CustomerName và 1 method in ra CustomerName và 1 class con tên là VIPCustomer (trên thực tế có thể rất nhiều nhưng cứ lấy 1 đi cho nó đơn giản), class con này có thêm VIPPoints và 1 method in ra VIPPoints.

Problem 1: Cho anh VIPCustomer, anh in ra VIPPoints như thế nào? Trong OOP thì tôi chỉ đơn giản VIPCustomer kế thừa từ Customer, thêm trường VIPPoints và method vào đấy, gọi var c = new VIPCustomer(); rồi c.PrintVIPPoints()

Problem 2: Giờ bọn nó yêu cầu khách hàng là phải có thêm thông tin về CMND, anh thay đổi thế nào để in ra số CMND của VIPCustomer?. Ở OOP tôi chỉ đơn giản là thêm CMND vào base class, rồi thì cứ hễ là class con thì tự nó có. Với FP nó sẽ là thế nào?

Cảm ơn anh trước

Quynh 123 said:

Thì thêm CMND rồi viết hàm getCMND, sau đó thì getVipCustomer.getCMND mình nghĩ đơn giản vậy thôi

rosario_1 said:

Sorry nghe anh nói thế tôi tò mò vừa mới đang đọc thử về FP nhưng chưa thấy đâu. Tôi đang tìm hiểu cách biểu diễn kế thừa trong OOP sang FP là như thế nào. Anh bảo ví dụ thì giờ tôi nêu cụ thể, nếu anh thông não được thì xin cảm ơn anh nhiều.

Vấn đề hết sức đơn giản là thế này, tôi có base class Customer với CustomerName và 1 method in ra CustomerName và 1 class con tên là VIPCustomer (trên thực tế có thể rất nhiều nhưng cứ lấy 1 đi cho nó đơn giản), class con này có thêm VIPPoints và 1 method in ra VIPPoints.

Problem 1: Cho anh VIPCustomer, anh in ra VIPPoints như thế nào? Trong OOP thì tôi chỉ đơn giản VIPCustomer kế thừa từ Customer, thêm trường VIPPoints và method vào đấy, gọi var c = new VIPCustomer(); rồi c.PrintVIPPoints()

Problem 2: Giờ bọn nó yêu cầu khách hàng là phải có thêm thông tin về CMND, anh thay đổi thế nào để in ra số CMND của VIPCustomer?. Ở OOP tôi chỉ đơn giản là thêm CMND vào base class, rồi thì cứ hễ là class con thì tự nó có. Với FP nó sẽ là thế nào?

Cảm ơn anh trước

naiveryan said:

Tôi trả lời một lượt cho 2 thanh niên trên kia quote tôi bảo chê OOP nâng FP mà nói mồm. Vâng tôi chê bằng mồm thôi, các ông tin hay ko thì tùy. Muốn biết thì đi mà tìm hiểu, t ko rảnh ngồi giãi bày từng cái so sánh ra để thông não cho ai. Tôi mà muốn chê toàn diện tôi dành hẳn 1 tuần ngồi viết blog chứ cũng ko đi nói ngược xuôi với mấy ông trên cái forum ko chuyên về dev này.

Thay vì thế tôi sẽ chỉ trả lời câu hỏi nào có code involve như ông rosario, cứ đưa code vào đây tôi xem.

Còn 1 ý nữa là tại sao FP gần ngôn ngữ tự nhiên hơn, đây nói cho ng chưa code FP thì khó mà thông cứ nhìn cái đề của rosa đi, code fp thì cứ đọc từ trên xuống trúng cái nào return cái nấy theo cách giải của tôi, tôi giải thích cho vợ tôi cũng hiểu được. Còn nếu code theo kiểu mutable với assignment, các ông phải giải thích cái biến r gán vào lúc này giá trị bao nhiêu, sau dòng code này giá trị bao nhiêu, cuối cùng đi qua if else ntnao thì return kết quả cuối là bao nhiêu. Kể cả là dev mà phải đọc xong nhớ trong đầu code đến đây là đang value gì để debug cũng đã khổ hơn rất nhiều so với immutable, once init, never change.

Đó nội nhiêu đó thôi là thấy expressiveness của FP hơn hẳn mutable code nói chung. Ko phải FP tốt hơn Imperative trên mọi mặt trận nhưng về diễn đạt thì tôi đánh giá FP hơn.

zulu said:

Chính mồm anh nối về con khỉ j j đó với cái mồm và ko có code involve mà. Đến h anh cũng chưa có code involve cho vụ đó. Ông kia đưa code về luận điểm thiết kế sai đó. Chưa bàn sai đúng nhưng có ý.
Nói về kiến thức mà mồm ko thì tất nhiên ko ai tin rồi.


Đến bài trên của ông Rosa tôi chờ implement hoàn hoàn bằng FP của ông nè. Đến đây ông bảo ko rảnh để làm hay để thông não j j đó thì thôi, chơi thế ko ai chơi lại

naiveryan said:

Oke tôi trả lời thế này.

Đầu tiên là FP ko có kế thừa, và cả một số Imperative Lang hiện đại cũng ko có kế thừa nốt (ie Rust).

Problem 01:
- Cách mọi ng hay nghĩ đến là associate method. Thì sẽ call được bằng c.name() và c.vippoint(). Cách này là favor của Imperative, OOP cũng impl theo hướng này.

- Favor của FP và các NN mới (cả Golang và Rust và cả OOP cũng có) là dùng Trait(rust), Typeclass(Haskell), Interface(go/java). Define 2 cái Interface là BasicRank và VIPRank chẳng hạn, Customer impl BasicRank, VIP impl BasicRank + VIPRank. Nếu nn hỗ trợ default implementation thì càng ngon chả phải code dài quá.

Problem 02:
Dễ dàng thêm new Interface là Identifiable và impl cái này cho cả Customer + VIP

Đấy câu trên để trả lời cho ông là ko cần dùng kế thừa ngta code được output y chang. Và cái kế thừa là cái gây ra nhiều câu chuyện banana monkey nên ko ai thích dùng nó.

naiveryan said:

Oke tôi trả lời thế này.

Đầu tiên là FP ko có kế thừa, và cả một số Imperative Lang hiện đại cũng ko có kế thừa nốt (ie Rust).

Problem 01:
- Cách mọi ng hay nghĩ đến là associate method. Thì sẽ call được bằng c.name() và c.vippoint(). Cách này là favor của Imperative, OOP cũng impl theo hướng này.

- Favor của FP và các NN mới (cả Golang và Rust và cả OOP cũng có) là dùng Trait(rust), Typeclass(Haskell), Interface(go/java). Define 2 cái Interface là BasicRank và VIPRank chẳng hạn, Customer impl BasicRank, VIP impl BasicRank + VIPRank. Nếu nn hỗ trợ default implementation thì càng ngon chả phải code dài quá.

Problem 02:
Dễ dàng thêm new Interface là Identifiable và impl cái này cho cả Customer + VIP

Đấy câu trên để trả lời cho ông là ko cần dùng kế thừa ngta code được output y chang. Và cái kế thừa là cái gây ra nhiều câu chuyện banana monkey nên ko ai thích dùng nó.

hikaruu said:

Mấy ông có biết cứ kêu viết vài dòng code chứng minh fp hơn opp nghe nó buồn cười lắm không vì nó là cả quá trinh phát triển phần mềm ,khả năng mở rộng,debug , khả năng test,etc
Oop hơn fp ở cái sống lâu với dc ide cùi bắp hồi ấy chỉ support tốt oop nên lắm tín đồ thôi. Các ngôn ngữ mới xuất toàn fp chứ có cái nào là oop đâu
https://medium.com/machine-words/the-rise-and-fall-of-object-oriented-programming-d67078f970e2

In my own programming, I prefer a “hybrid” approach that uses FP techniques in some places, and OOP techniques in others. There are some kinds of problems where FP really shines, and others where OOP is an obvious choice.

I know that a lot of FP enthusiasts are fervent advocates of “pure” functional languages, in which all objects are immutable, and can only be transformed, not modified. However, I have found that the pure approach tends to take certain relatively straightforward programming exercises and turn them into puzzles, by which I mean clever, non-obvious tricks that amuse and appeal to the kind of person who enjoys brain teasers, but which is completely inscrutable to everyone else.

naiveryan said:

Oke tôi trả lời thế này.

Đầu tiên là FP ko có kế thừa, và cả một số Imperative Lang hiện đại cũng ko có kế thừa nốt (ie Rust).

Problem 01:
- Cách mọi ng hay nghĩ đến là associate method. Thì sẽ call được bằng c.name() và c.vippoint(). Cách này là favor của Imperative, OOP cũng impl theo hướng này.

- Favor của FP và các NN mới (cả Golang và Rust và cả OOP cũng có) là dùng Trait(rust), Typeclass(Haskell), Interface(go/java). Define 2 cái Interface là BasicRank và VIPRank chẳng hạn, Customer impl BasicRank, VIP impl BasicRank + VIPRank. Nếu nn hỗ trợ default implementation thì càng ngon chả phải code dài quá.

Problem 02:
Dễ dàng thêm new Interface là Identifiable và impl cái này cho cả Customer + VIP

Đấy câu trên để trả lời cho ông là ko cần dùng kế thừa ngta code được output y chang. Và cái kế thừa là cái gây ra nhiều câu chuyện banana monkey nên ko ai thích dùng nó.

naiveryan said:

Glassgow của Haskell thua gcc như nào, tôi thấy GHC thông minh vãi r còn gì )

trgiangvp3 said:

Ngay cả ông viết bài mà anh dẫn link cũng phải thừa nhận



Chứ người ta đéo cuồng kiểu mất não "OOP là cứt đái, FP là nhất" như kiểu mấy anh ở đây. Cuối cùng thì OOP hay FP sinh ra để làm gì? Cũng chỉ là để viết code đỡ nhọc hơn và bảo trì dễ hơn. Vậy nên đừng có cực đoan tôn cái FP lên như thánh. Rõ ràng là OOP có vấn đề gì đó thì người ta mới quay lại với FP nhưng tôi thấy chỉ là để khắc phục nhược điểm của OOP trong 1 số trường hợp nào đó. Chứ còn anh mà tư duy thiết kế hệ thống không theo lối OOP xem có làm nổi không nhé.

hikaruu said:

Bạn vẫn nghĩ ko thể làm cả dự án bằng theo fn à, ai cực đoan hơn đây , the tat cả dự án react code theo oop hay fn

VImask said:

Mình đi học và đi làm chỉ dùng OOP nên không rỏ FP có các ưu điểm như của OOP không? Như dễ tổ chức, bảo trì, mở rộng, tái sử dụng code? Cần cao nhân thông não

via theNEXTvoz for iPhone

quandaso said:

React là FP =]], cười ỉa. Thà đừng lôi vào còn đỡ bị đánh giá.

hikaruu said:

Bạn vẫn nghĩ ko thể làm cả dự án bằng theo fn à, ai cực đoan hơn đây , the tat cả dự án react code theo oop hay fn

hikaruu said:

Ủa câu nào nói React là fp vậy .

hikaruu said:

the tat cả dự án react code theo oop hay fn

trgiangvp3 said:

Tôi đang nói là tư duy thiết kế hệ thống.
Cái react mà anh bảo theo tôi hiểu thì nó được xây dựng theo tư duy OOP, chỉ có code convention thì theo kiểu FP.
Nghĩa là cái FP thần thánh của các anh nó chỉ được sử dụng/phát huy trong một phạm vi hẹp nhất định, còn tổng thể hệ thống người ta vẫn phải xây dựng dựa trên OOP.

Tôi thì chẳng chê gì FP hay thần thánh OOP, tôi chỉ muốn nhét shit vào mồm các anh biết đc chút về FP xong tôn nó lên làm bố và quay lại chửi OOP đéo khác gì cứt đái.
Mỗi cái nó có ưu, nhược điểm riêng, và sẽ phát huy được hiệu quả trong từng trường hợp cụ thể. Chứ nếu FP thực sự vượt trội thì OOP nó tạch lâu rồi.

zulu said:

Tôi thấy trc khi FP nổi lên thì OOP ngta vẫn làm dạng này chứ khác j đâu.

Pianist said:

@naiveryan tôi vẫn đang chờ câu bản chất của software đây. Tranh luận đ' nói dc gì cụ thể cùn chuyển thành tin hay ko thì tùy à

Nipin said:

mà nói thật tôi cũng lười vào topic dạng này, vì việc thảo luận OOP vs FP nó là vấn đề của 10 năm trước rồi, dù là vn có đi chậm so với thế giới 5 năm thì nó cũng là vấn đề của 5 năm trước, giờ ngoài newbie ra chả ai còn thắc mắc cái này nữa.

ngay cả trong voz này tôi cá là các bạn có thể tìm được thread từ 5 năm trước về FP.
... mà không cần cá, tôi tìm thấy rồi: https://o.voz.vn/showthread.php?t=4323554

thiết nghĩ kỹ năng tìm kiếm là một kỹ năng cơ bản của lập trình viên, đề tài FP vs OOP nó chả có gì mới mẻ mà phải mất công cãi nhau hay khai sáng.

trgiangvp3 said:

Tôi vẫn chưa thấy FP có gì ưu việt qua cái ví dụ này của anh. Chắc anh biết trong OOP có khái niệm Composition over inheritance nhỉ. Cái này nó làm y chang những gì anh mô tả ở trên (tạo interface gì gì đó) và giúp giải quyết được vấn đề con khỉ cầm chuối mà anh nói.
Thế nên tôi mới bảo là vấn đề nằm ở thiết kế chứ ko phải ở cách lập trình.

naiveryan said:

Cái SIMP kia tôi cũng chưa hiểu, tìm đọc xem sao đã

rosario_1 said:

Tưởng trình độ của bạn thượng đẳng thế nào, té ra cũng chỉ là nhìn output phán. Chết cười.

Để tớ nói cho bạn, về software design có 1 cái principle nó gọi là "don't repeat yourself". Ý nghĩa của cái này nôm na là logic giống nhau phải được gộp vào 1 chỗ, và kế thừa là 1 thể hiện cơ bản của tư duy này. Tại sao điều này cần thiết thì tớ ví dụ thế này, về cơ bản, 1 phần mềm sử dụng trên thực tế nói chung có rất nhiều objects. Chả nói đâu xa 1 cửa hàng tạp hóa ngoài chợ có khi bán hàng trăm loại sản phẩm khác nhau. Nếu ko gom logic chung vào 1 chỗ thì đến khi có thay đổi, bạn sẽ phải vào cả trăm chỗ để sửa. Nhưng nhờ "dont repeat yourself" principle này, cụ thể ở đây là kế thừa, thì bạn chỉ cần phải thay đổi ở đúng 1 nơi thôi thay vì cả trăm nơi, đơn giản cụ thể ở đây là đổi base class cái là các class kế thừa tự động thay đổi theo.

Nói chung ấy, nói với tư cách đánh giá khách quan ko liên quan đến cá nhân nhé, thì với cái kiểu bạn nói, khẳng định viết cái phần mềm quản lý cho bà bán tạp hóa ngoài chợ còn éo nên hồn, cao siêu cái gì? Ai bảo bạn là ko ai thích kế thừa? Như tớ đã nói, đây nó là principle của software design rồi, trừ khi số lượng object ko nhiều, chứ ko có nó chỉ có mà nát bét, bất kể bạn thích hay ko. Còn Monkey Forest như tớ đã nói đấy là hậu quả của design kém, chứ ko phải do kế thừa, bạn hoàn toàn có thể khắc phục để ko bị tình trạng đấy xảy ra.

Nipin said:

tôi không biết giờ voz xuống cấp hay dev việt nam trình độ đi xuống, hoặc có thể chỉ là do được ngày có vài thằng dở hơi vào chơi, cơ mà đọc thread hài vkl.

nhân tiện thì đợt trước tôi có chia sẻ source code một cái clone chotot viết bằng elixir, tuy code dc tầm 2 tháng cho nên khá sơ sài, cơ mà thiết nghĩ rao vặt của chotot nó cũng đầy đủ đặc tính "nhiều loại sản phẩm" rồi các bạn nhỉ =)

rosario_1 said:

Anh cứ nói thẳng tôi trình độ kém, ngu v.v... cmn đi cho nhanh, tôi xin nhận hết. Có điều như vậy thì anh nên giải đáp vấn đề tôi hỏi cho trực diện vào.

Tôi lấy ví dụ tôi có nhiều loại khách hàng đi, khách hàng bình thường, khách Vip, khách dưới 18t v.v... Tôi cứ diễn đạt dưới ngôn ngữ OOP đi là tôi có class A, 1 đống class A', A'', A n phẩy kế thừa từ A. Bây giờ nhà nước ra yêu cầu lưu thêm số CMND của khách hàng, chẳng hạn vậy. Với OOP tôi chỉ cần thêm đúng 1 dòng vào class A. Câu hỏi của tôi là với FP các anh làm thế nào để làm được điều đấy với FP mà ko dùng đến kế thừa? Liệu có phải đi mà mò vào từng cái A, A' v.v... để sửa ko?

Nếu câu trả lời của anh là phải mò vào tất ấy, thì tôi có ý kiến thế này. Anh cứ nói viết cái này cái kia v.v... tôi thấy chưa đủ. Phải rồi các anh cứ làm sao cho nhanh cho tiện, thế là xong. 1 dự án chắc 1 vài năm là cùng, xong là phủi đít. Thế nhưng nếu làm cái kiểu ấy, thì nhiều năm về sau cái thằng maintain nó vẫn còn lôi 4 đời nhà các anh ra chửi đấy, chẳng qua các anh éo biết thôi.

type BasicInfo = {
    name: string
    age: number
}

type Customer {
    basicInfo: BasicInfo
    // other data
}

type VipCustomer {
    basicInfo: BasicInfo
    // other data
}

type Below18Customer {
    
}

rosario_1 said:

Tôi lại hỏi ngu anh 1 phát

basicInfo: BasicInfo

Cái dòng này là kế thừa hay không phải kế thừa?

cugiametruyen85 said:

Các anh cãi nhau hăng thế, tôi thích OOP vì IDE của nó tốt, lib tốt, cộng đồng to, thế là đủ rồi

.Lý thuyết ra sao tôi không cần biết nhưng hiện tại nó là như vậy. Thằng nào làm IDE tốt hơn bọn Intellij tôi dùng thằngđó thôi

lam vung lau lam said:

anh ngây ngô thật.

bản chất của lập trình là function biến đổi (transform) input thành output.
người ta thiết kế cấu trúc dữ liệu là để phục vụ cho giải thuật. các anh code OOP nhiều quá nên não toàn là noun mà chả có tý verb nào.

đọc bài này đi nhé
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
còn về tính diễn đạt của FP so với OOP thì đọc bài này.
https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html

còn về cái ví dụ của anh thì nó chỉ đơn giản như này thôi

JavaScript:

type BasicInfo = {
    name: string
    age: number
}

type Customer {
    basicInfo: BasicInfo
    // other data
}

type VipCustomer {
    basicInfo: BasicInfo
    // other data
}

type Below18Customer {
 
}

muốn thêm data chung thì thêm vào cái BasicInfo là được

lam vung lau lam said:

composition nha.
từ cái thớt mà có thảo luận js có first class function còn c# không có tôi đã thấy anh ngây ngô rồi, thấy anh quote tôi chả buồn trả lời.

lam vung lau lam said:

anh ngây ngô thật.

bản chất của lập trình là function biến đổi (transform) input thành output.
người ta thiết kế cấu trúc dữ liệu là để phục vụ cho giải thuật. các anh code OOP nhiều quá nên não toàn là noun mà chả có tý verb nào.

đọc bài này đi nhé
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
còn về tính diễn đạt của FP so với OOP thì đọc bài này.
https://www.lihaoyi.com/post/WhatsFunctionalProgrammingAllAbout.html

còn về cái ví dụ của anh thì nó chỉ đơn giản như này thôi

JavaScript:

type BasicInfo = {
    name: string
    age: number
}

type Customer {
    basicInfo: BasicInfo
    // other data
}

type VipCustomer {
    basicInfo: BasicInfo
    // other data
}

type Below18Customer {
   
}

muốn thêm data chung thì thêm vào cái BasicInfo là được

rosario_1 said:

Anh cứ nói thẳng tôi trình độ kém, ngu v.v... cmn đi cho nhanh, tôi xin nhận hết. Có điều như vậy thì anh nên giải đáp vấn đề tôi hỏi cho trực diện vào.

Tôi lấy ví dụ tôi có nhiều loại khách hàng đi, khách hàng bình thường, khách Vip, khách dưới 18t v.v... Tôi cứ diễn đạt dưới ngôn ngữ OOP đi là tôi có class A, 1 đống class A', A'', A n phẩy kế thừa từ A. Bây giờ nhà nước ra yêu cầu lưu thêm số CMND của khách hàng, chẳng hạn vậy. Với OOP tôi chỉ cần thêm đúng 1 dòng vào class A. Câu hỏi của tôi là với FP các anh làm thế nào để làm được điều đấy với FP mà ko dùng đến kế thừa? Liệu có phải đi mà mò vào từng cái A, A' v.v... để sửa ko?

Nếu câu trả lời của anh là phải mò vào tất ấy, thì tôi có ý kiến thế này. Anh cứ nói viết cái này cái kia v.v... tôi thấy chưa đủ. Phải rồi các anh cứ làm sao cho nhanh cho tiện, thế là xong. 1 dự án chắc 1 vài năm là cùng, xong là phủi đít. Thế nhưng nếu làm cái kiểu ấy, thì nhiều năm về sau cái thằng maintain nó vẫn còn lôi 4 đời nhà các anh ra chửi đấy, chẳng qua các anh éo biết thôi.

lam vung lau lam said:

còn về cái ví dụ của anh thì nó chỉ đơn giản như này thôi

JavaScript:

type BasicInfo = {
    name: string
    age: number
}

type Customer {
    basicInfo: BasicInfo
    // other data
}

type VipCustomer {
    basicInfo: BasicInfo
    // other data
}

type Below18Customer {
  
}

muốn thêm data chung thì thêm vào cái BasicInfo là được

Thích Màu Hường said:

FP expert cho em hỏi giờ giả sử VipCustomer có thêm field VipPoints, Below18Customer có thêm field Grade. Muốn thêm hàm Print tất cả thông tin của customer (bao gồm BasicInfo và các fields của nó tùy vào loại Customer, VipCustomer, Below18Customer) thì làm sao?

Ps: Thím chỉ giáo xong sau khi thấy code cho phép em hỏi 1 câu nữa

lam vung lau lam said:

pattern matching nha.
mà thiết nghĩ thay vì hỏi anh nên tìm hiểu trước thì hơn.

rosario_1 said:

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?

Thích Màu Hường said:

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?

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

lam vung lau lam said:

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.

Thích Màu Hường said:

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.

drnoxxx said:

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?

lam vung lau lam said:

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 said:

Code:

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

lyokha114 said:

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

lyokha114 said:

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 said:

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ổ?

Thích Màu Hường said:

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.

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

lam vung lau lam said:

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

Thích Màu Hường said:

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 said:

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.

lam vung lau lam said:

đọ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 said:

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.

lam vung lau lam said:

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

rosario_1 said:

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.

lyokha114 said:

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

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.

Nipin said:

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:

hikaruu said:

Vd test viec đi ỉa của con khỉ , anh phải tạo con khỉ để cho nó đi ỉa, nhưng tạo dc con khỉ anh phải truyền vào instance của khu rừng , thế nên phải tạo khu rừng để inject vào con khỉ (DI), etc,..., vì con khỉ phụ thuộc khi rừng vd rừng cháy con khỉ ko ỉa dc, mà con khỉ ko kiểm soát dc khu rừng nên test case phải bao gồm thêm tất cả trạng thái của khu rừng, khi anh implement thêm cho khu rừng việc test đi ỉa con khỉ cũng phải dc viết thêm, test caseko dự đoán truoc dc => khi có lỗi viết thêm test case cho trường hợp lỗi đó

hikaruu said:

Vd test viec đi ỉa của con khỉ , anh phải tạo con khỉ để cho nó đi ỉa, nhưng tạo dc con khỉ anh phải truyền vào instance của khu rừng , thế nên phải tạo khu rừng để inject vào con khỉ (DI), etc,..., vì con khỉ phụ thuộc khi rừng vd rừng cháy con khỉ ko ỉa dc, mà con khỉ ko kiểm soát dc khu rừng nên test case phải bao gồm thêm tất cả trạng thái của khu rừng, khi anh implement thêm cho khu rừng việc test đi ỉa con khỉ cũng phải dc viết thêm, test caseko dự đoán truoc dc => khi có lỗi viết thêm test case cho trường hợp lỗi đó

lyokha114 said:

Mấy a cứ ví dụ kiểu gì vậy, con khỉ là con khỉ, rừng là rừng, tự nhiên đi thiết kế dính vào vào rồi ép ngta phải theo à

Thích Màu Hường said:

Cho tới bây giờ các anh rồ FP vẫn chưa show ra được cái ví dụ cụ thể nào là FP nó ưu việt hơn OOP mà chỉ nói mồm thôi.

Bây giờ thế này. Cái ví dụ của tôi ở post này https://voz.vn/t/oop-hay-fp.137397/page-9#post-4498893 . Tôi sẽ dùng OOP, code bằng C#, anh nào rồ FP thì code thử bằng F# rồi đem ra so sánh, chứ nói mồm thôi cả chục page rồi chả tới đâu.

Quan điểm của tôi là FP chỉ khắc phục trong 1 số tình huống mà immutable với pure functions có lợi hơn thôi, còn phân tích thiết kế hệ thống thì OOP vẫn là trung tâm. FP là 1 phần nhỏ support OOP chứ ko phải là 1 thứ tiến hóa vượt bậc so với OOP như các anh nói. Khi đụng tình huống cần polymorphism thì giải pháp thay thế bên FP cũng lấn cấn thôi. Ngay cả thằng F# cũng có OOP style với interface, abstract.

hikaruu said:

Vd truyen instance và ảnh hưởng của nó thôi , chả lẽ tạo con khỉ ko truyền gì từ ngoài vào tư duy chán vậy

naiveryan said:

Challenge accept. Đưa code C# lên đi bạn. Ghi rõ cả đề + code giùm. Đề bạn đưa ra thì tất nhiên tôi k mạnh miệng bảo sẽ code ra đc ngon lành hơn với fp style nh vẫn code đưa lên cho các bạn so sánh. Quan điểm của tôi là tôi sẽ ko dùng OOP nhưng vẫn đảm bảo thiết kế code output đúng đề và stucture chuẩn tương đương.

Thích Màu Hường said:

Cho tới bây giờ các anh rồ FP vẫn chưa show ra được cái ví dụ cụ thể nào là FP nó ưu việt hơn OOP mà chỉ nói mồm thôi.

Bây giờ thế này. Cái ví dụ của tôi ở post này https://voz.vn/t/oop-hay-fp.137397/page-9#post-4498893 . Tôi sẽ dùng OOP, code bằng C#, anh nào rồ FP thì code thử bằng F# rồi đem ra so sánh, chứ nói mồm thôi cả chục page rồi chả tới đâu.

Quan điểm của tôi là FP chỉ khắc phục trong 1 số tình huống mà immutable với pure functions có lợi hơn thôi, còn phân tích thiết kế hệ thống thì OOP vẫn là trung tâm. FP là 1 phần nhỏ support OOP chứ ko phải là 1 thứ tiến hóa vượt bậc so với OOP như các anh nói. Khi đụng tình huống cần polymorphism thì giải pháp thay thế bên FP cũng lấn cấn thôi. Ngay cả thằng F# cũng có OOP style với interface, abstract.

naiveryan said:

Challenge accept. Đưa code C# lên đi bạn. Ghi rõ cả đề + code giùm. Đề bạn đưa ra thì tất nhiên tôi k mạnh miệng bảo sẽ code ra đc ngon lành hơn với fp style nh vẫn code đưa lên cho các bạn so sánh. Quan điểm của tôi là tôi sẽ ko dùng OOP nhưng vẫn đảm bảo thiết kế code output đúng đề và stucture chuẩn tương đương.

hikaruu said:

Cái ví dụ anh viết chỉ select data , có gì đâu mà làm , tối về ngồi máy tôi viết vd select data kiểu fp, mấy cái vấn đề trên là của oop rồi kêu tôi viết fp giải quyết có buồn cười ko, cái đa hình là oop nó tự sinh ra , rồi nó sing ra 23 cái design partten giải quyết nó , rồi DI các kiểu ) để scale dc dự án

1. Giả sử phần core hiển thị thông tin Customer là vô cùng phức tạp, ví dụ có tương tác phần cứng, thiết bị đặc biệt. Việc cập nhật, deploy lại sẽ dẫn tới dừng hoạt động kinh doanh. Tóm lại phần này hạn chế, trong đề bài này xem như fixed không được thay đổi. Hoạt động phức tạp đó là in ra các dấu "##############".
2. Hệ thống này cho phép bên thứ 3 custom cách hiển thị cho từng loại khách hàng thêm vào cái "hoạt động phức tạp" ở mục 1. Cụ thể là sau khi in thông tin sẽ in "$$$$$$$$$$$" đối với loại Customer, in "@@@@@@@" với loại VipCustomer.
3. Các loại khách hàng có thể phát sinh không giới hạn theo thời gian. Cụ thể sau khi deploy rồi thì có phát sinh InternalCustomer(Name, Age, Deparment) cũng cần được hiển thị thông tin như trong phần core và phần custom là in "&&&&&&&&&&&&"

using System;

namespace Visualizer
{
    public interface IPrintable
    {
        void CustomPrint();
    }

    public class Visualizer
    {
        public void Print(IPrintable printable)
        {
            Console.WriteLine("\n#######################################################");
            printable.CustomPrint();    
        }
    }
}

using Visualizer;
using System;
using System.Collections.Generic;

namespace CustomerInfoManager
{
    /// <summary>
    /// Base class implement IPrintable để giao tiếp với Visualizer
    /// </summary>
    public class Customer : IPrintable
    {
        public string Name { get; set; }

        public int Age { get; set; }

        /// <summary>
        /// Custom print được sử dụng trong Visualizer
        /// </summary>
        public virtual void CustomPrint()
        {
            // Process basic info
            Console.WriteLine($"{nameof(this.Name)} = {this.Name}");

            Console.WriteLine($"{nameof(this.Age)} = {this.Age}");

            // Process other info
            this.PrintOtherInfo();
        }

        protected virtual void PrintOtherInfo()
        {
            Console.WriteLine("$$$$$$$$$$$$$$$$$$$$$$$");
        }
    }

    public class VipCustomer : Customer
    {
        public int VipPoints { get; set; }

        protected override void PrintOtherInfo()
        {
            Console.WriteLine($"{nameof(this.VipPoints)} = {this.VipPoints}");
            Console.WriteLine("@@@@@@@@@@@@@@@@@@@@@@@");
        }
    }

    public class InternalCustomer : Customer
    {
        public string Department { get; set; }

        protected override void PrintOtherInfo()
        {
            Console.WriteLine($"{nameof(this.Department)} = {this.Department}");
            Console.WriteLine("&&&&&&&&&&&&&&&&&&&&&&&");
        }
    }

    public class CustomerRepo
    {
        /// <summary>
        /// Giả lập lấy data để test
        /// </summary>
        public static IList<Customer> GetCustomers()
        {
            IList<Customer> customers = new List<Customer>
            {
                new Customer { Name = "John Smith", Age = 20 },
                new VipCustomer { Name = "Tim Batte", Age = 30, VipPoints = 100 },
                new InternalCustomer { Name = "Jenny Lars", Age = 40, Department = "IT" }
            };

            return customers;
        }
    }
}

using CustomerInfoManager;
using System.Collections.Generic;

namespace CustomerManagement
{
    class Program
    {
        static void Main(string[] args)
        {
            IList<CustomerInfoManager.Customer> customers = CustomerRepo.GetCustomers();

            Visualizer.Visualizer visualizer = new Visualizer.Visualizer();
            foreach (CustomerInfoManager.Customer customer in customers)
            {
                visualizer.Print(customer);
            }
        }
    }
}

#######################################################
Name = John Smith
Age = 20
$$$$$$$$$$$$$$$$$$$$$$$

#######################################################
Name = Tim Batte
Age = 30
VipPoints = 100
@@@@@@@@@@@@@@@@@@@@@@@

#######################################################
Name = Jenny Lars
Age = 40
Department = IT
&&&&&&&&&&&&&&&&&&&&&&&

Visualizer.Visualizer visualizer = new Visualizer.Visualizer();
foreach (CustomerInfoManager.Customer customer in customers)
{
// customer có thể là VipCustomer, InternalCustomer mà hiển thị khác nhau
visualizer.Print(customer);
}

Thích Màu Hường said:

Đề bài:
Tạo hệ thống hiển thị thông tin cho nhiều loại khách hàng. Hiện tại có 2 loại: Customer (Name, Age), VipCustomer(Name, Age, VipPoints) thỏa các yêu cầu sau:

1. Giả sử phần core hiển thị thông tin Customer là vô cùng phức tạp, ví dụ có tương tác phần cứng, thiết bị đặc biệt. Việc cập nhật, deploy lại sẽ dẫn tới dừng hoạt động kinh doanh. Tóm lại phần này hạn chế, trong đề bài này xem như fixed không được thay đổi. Hoạt động phức tạp đó là in ra các dấu "##############".
2. Hệ thống này cho phép bên thứ 3 custom cách hiển thị cho từng loại khách hàng thêm vào cái "hoạt động phức tạp" ở mục 1. Cụ thể là sau khi in thông tin sẽ in "$$$$$$$$$$$" đối với loại Customer, in "@@@@@@@" với loại VipCustomer.
3. Các loại khách hàng có thể phát sinh không giới hạn theo thời gian. Cụ thể sau khi deploy rồi thì có phát sinh InternalCustomer(Name, Age, Deparment) cũng cần được hiển thị thông tin như trong phần core và phần custom là in "&&&&&&&&&&&&"

OOP Implementation
Module 1: CustomerVisualizer.dll: đây là phần core sẽ không được thay đổi, có cho phép bên thứ 3 custom cách hiển thị bằng cách public interface IPrintable với method CustomPrint()

C#:

using System;

namespace CustomerVisualizer
{
    public interface IPrintable
    {
        void CustomPrint();
    }

    public class CustomerVisualizer
    {
        public void Print(IPrintable printable)
        {
            Console.WriteLine("\n#######################################################");
            printable.CustomPrint();      
        }
    }
}

Module 2: CustomerInfoManager.dll: module này chứa thông tin các loại khách hàng và quy định phần hiển thị custom. Module này được cập nhật khi có thêm loại khách hàng mới:

C#:

using CustomerVisualizer;
using System;
using System.Collections.Generic;

namespace CustomerInfoManager
{
    /// <summary>
    /// Base class implement IPrintable để giao tiếp với CustomerVisualizer
    /// </summary>
    public class Customer : IPrintable
    {
        public string Name { get; set; }

        public int Age { get; set; }

        /// <summary>
        /// Custom print được sử dụng trong CustomerVisualizer
        /// </summary>
        public void CustomPrint()
        {
            // Process basic info
            Console.WriteLine($"{nameof(this.Name)} = {this.Name}");

            Console.WriteLine($"{nameof(this.Age)} = {this.Age}");

            // Process other info
            this.PrintOtherInfo();
        }

        protected virtual void PrintOtherInfo()
        {
            Console.WriteLine("$$$$$$$$$$$$$$$$$$$$$$$");
        }
    }

    public class VipCustomer : Customer
    {
        public int VipPoints { get; set; }

        protected override void PrintOtherInfo()
        {
            Console.WriteLine($"{nameof(this.VipPoints)} = {this.VipPoints}");
            Console.WriteLine("@@@@@@@@@@@@@@@@@@@@@@@");
        }
    }

    public class InternalCustomer : Customer
    {
        public string Department { get; set; }

        protected override void PrintOtherInfo()
        {
            Console.WriteLine($"{nameof(this.Department)} = {this.Department}");
            Console.WriteLine("&&&&&&&&&&&&&&&&&&&&&&&");
        }
    }

    public class CustomerRepo
    {
        /// <summary>
        /// Giả lập lấy data để test
        /// </summary>
        public static IList<Customer> GetCustomers()
        {
            IList<Customer> customers = new List<Customer>
            {
                new Customer { Name = "John Smith", Age = 20 },
                new VipCustomer { Name = "Tim Batte", Age = 30, VipPoints = 100 },
                new InternalCustomer { Name = "Jenny Lars", Age = 40, Department = "IT" }
            };

            return customers;
        }
    }
}

Program: CustomerManagement.exe: cái này là entry point, chứa hàm main để chạy thoy:

C#:

using CustomerInfoManager;
using System.Collections.Generic;

namespace CustomerManagement
{
    class Program
    {
        static void Main(string[] args)
        {
            IList<CustomerInfoManager.Customer> customers = CustomerRepo.GetCustomers();

            CustomerVisualizer.CustomerVisualizer visualizer = new CustomerVisualizer.CustomerVisualizer();
            foreach (CustomerInfoManager.Customer customer in customers)
            {
                visualizer.Print(customer);
            }
        }
    }
}

Tự nhận xét:
Dùng OOP có interface nên có thể public IPrintable.CustomPrint() cho bất kỳ ai muốn custom khi sử dụng CustomerVisualizer.dll. Đây là khả năng mở rộng.

Customer.CustomPrint() in basic info là Name, Age của tất cả các loại khách hàng. Cho dù có 10 loại thì cũng không phải lặp lại 10 lần và đặc biệt là cũng không cần phải gọi lại 10 chổ (do tính kế thừa).

Chương trình có 3 modules, mổi khi thêm loại khách hàng chỉ 1 CustomerInfoManager.dll là phải deploy lại:
CustomerVisualizer.dll - (fixed)
CustomerInfoManager.dll - (updated)
CustomerManagement.exe - (fixed)

Polymorphism hiện rõ cùng là in thông tin nhưng cách custom khác nhau tùy vào loại customer:


Hóng các thánh rồ FP code lại và SO SÁNH CỤ THỂ CHỔ NÀO FP LẠI ƯU VIỆT HƠN OOP cho đề bài trên.

Thích Màu Hường said:

Hóng các thánh rồ FP code lại và SO SÁNH CỤ THỂ CHỔ NÀO FP LẠI ƯU VIỆT HƠN OOP cho đề bài trên.

quandaso said:

Không liên quan lắm, tôi chưa code FP bao giờ, nhưng ko phủ nhận tư duy immutable rất hay, đang cố gắng áp dụng tư duy đó cho 1 phần nhỏ dự án của tôi. Nhưng cho hỏi anh em FP làm việc với các external resource như socket hay file ổn không nhỉ, performance, async các kiểu ấy?

tthixk said:

bài này code chỉ 10 phút nhưng câu này có mà cãi nhau tới năm sau chưa xong Tư duy của FP nó khác OOP, nên ko thể so đc cái nào ưu việt hơn.


fp - immutable cơ bản là tốt, nhưng performance sẽ ko đc ngon, phải làm bạn với memoize để tăng performance.

Thích Màu Hường said:

Đó là thím nghĩ như này:

View attachment 229295

Nhưng các anh rồ FP lại nghĩ như này cơ:

View attachment 229296

rosario_1 said:

Vừa tìm hiểu hóa ra C# cũng code FP được, đỡ phải làm quen ngôn ngữ mới. Có điều chuyển sang FP đúng tốn bộ nhớ, test thấy sơ sơ Memory x3 so với OOP, 1 phần có thể là do thói quen dùng variable thoải mái cho là chẳng tốn bao nhiêu nhưng giờ mọi thứ đã là immutable. Để lúc nào có thời gian tập code lại mọi thứ = FP xem thế nào, hy vọng cuối tuần. Ước gì mình trẻ lại 10 tuổi khi chưa có gia đình, thèm code quá mà con thì vẫn còn ốm.

Thích Màu Hường said:

Đề bài:
Tạo hệ thống hiển thị thông tin cho nhiều loại khách hàng. Hiện tại có 2 loại: Customer (Name, Age), VipCustomer(Name, Age, VipPoints) thỏa các yêu cầu sau:

1. Giả sử phần core hiển thị thông tin Customer là vô cùng phức tạp, ví dụ có tương tác phần cứng, thiết bị đặc biệt. Việc cập nhật, deploy lại sẽ dẫn tới dừng hoạt động kinh doanh. Tóm lại phần này hạn chế, trong đề bài này xem như fixed không được thay đổi. Hoạt động phức tạp đó là in ra các dấu "##############".
2. Hệ thống này cho phép bên thứ 3 custom cách hiển thị cho từng loại khách hàng thêm vào cái "hoạt động phức tạp" ở mục 1. Cụ thể là sau khi in thông tin sẽ in "$$$$$$$$$$$" đối với loại Customer, in "@@@@@@@" với loại VipCustomer.
3. Các loại khách hàng có thể phát sinh không giới hạn theo thời gian. Cụ thể sau khi deploy rồi thì có phát sinh InternalCustomer(Name, Age, Deparment) cũng cần được hiển thị thông tin như trong phần core và phần custom là in "&&&&&&&&&&&&"

OOP Implementation
Module 1: CustomerVisualizer.dll: đây là phần core sẽ không được thay đổi, có cho phép bên thứ 3 custom cách hiển thị bằng cách public interface IPrintable với method CustomPrint()

C#:

using System;

namespace CustomerVisualizer
{
    public interface IPrintable
    {
        void CustomPrint();
    }

    public class CustomerVisualizer
    {
        public void Print(IPrintable printable)
        {
            Console.WriteLine("\n#######################################################");
            printable.CustomPrint();    
        }
    }
}

Module 2: CustomerInfoManager.dll: module này chứa thông tin các loại khách hàng và quy định phần hiển thị custom. Module này được cập nhật khi có thêm loại khách hàng mới:

C#:

using CustomerVisualizer;
using System;
using System.Collections.Generic;

namespace CustomerInfoManager
{
    /// <summary>
    /// Base class implement IPrintable để giao tiếp với CustomerVisualizer
    /// </summary>
    public class Customer : IPrintable
    {
        public string Name { get; set; }

        public int Age { get; set; }

        /// <summary>
        /// Custom print được sử dụng trong CustomerVisualizer
        /// </summary>
        public void CustomPrint()
        {
            // Process basic info
            Console.WriteLine($"{nameof(this.Name)} = {this.Name}");

            Console.WriteLine($"{nameof(this.Age)} = {this.Age}");

            // Process other info
            this.PrintOtherInfo();
        }

        protected virtual void PrintOtherInfo()
        {
            Console.WriteLine("$$$$$$$$$$$$$$$$$$$$$$$");
        }
    }

    public class VipCustomer : Customer
    {
        public int VipPoints { get; set; }

        protected override void PrintOtherInfo()
        {
            Console.WriteLine($"{nameof(this.VipPoints)} = {this.VipPoints}");
            Console.WriteLine("@@@@@@@@@@@@@@@@@@@@@@@");
        }
    }

    public class InternalCustomer : Customer
    {
        public string Department { get; set; }

        protected override void PrintOtherInfo()
        {
            Console.WriteLine($"{nameof(this.Department)} = {this.Department}");
            Console.WriteLine("&&&&&&&&&&&&&&&&&&&&&&&");
        }
    }

    public class CustomerRepo
    {
        /// <summary>
        /// Giả lập lấy data để test
        /// </summary>
        public static IList<Customer> GetCustomers()
        {
            IList<Customer> customers = new List<Customer>
            {
                new Customer { Name = "John Smith", Age = 20 },
                new VipCustomer { Name = "Tim Batte", Age = 30, VipPoints = 100 },
                new InternalCustomer { Name = "Jenny Lars", Age = 40, Department = "IT" }
            };

            return customers;
        }
    }
}

Program: CustomerManagement.exe: cái này là entry point, chứa hàm main để chạy thoy:

C#:

using CustomerInfoManager;
using System.Collections.Generic;

namespace CustomerManagement
{
    class Program
    {
        static void Main(string[] args)
        {
            IList<CustomerInfoManager.Customer> customers = CustomerRepo.GetCustomers();

            CustomerVisualizer.CustomerVisualizer visualizer = new CustomerVisualizer.CustomerVisualizer();
            foreach (CustomerInfoManager.Customer customer in customers)
            {
                visualizer.Print(customer);
            }
        }
    }
}

Tự nhận xét:
Dùng OOP có interface nên có thể public IPrintable.CustomPrint() cho bất kỳ ai muốn custom khi sử dụng CustomerVisualizer.dll. Đây là khả năng mở rộng.

Customer.CustomPrint() in basic info là Name, Age của tất cả các loại khách hàng. Cho dù có 10 loại thì cũng không phải lặp lại 10 lần và đặc biệt là cũng không cần phải gọi lại 10 chổ (do tính kế thừa).

Chương trình có 3 modules, mổi khi thêm loại khách hàng chỉ 1 CustomerInfoManager.dll là phải deploy lại:
CustomerVisualizer.dll - (fixed)
CustomerInfoManager.dll - (updated)
CustomerManagement.exe - (fixed)

Polymorphism hiện rõ cùng là in thông tin nhưng cách custom khác nhau tùy vào loại customer:


Hóng các thánh rồ FP code lại và SO SÁNH CỤ THỂ CHỔ NÀO FP LẠI ƯU VIỆT HƠN OOP cho đề bài trên.

hikaruu said:

cái cục dll đó nó chỉ xài dc cho project nhà anh thôi, quăng cái dll đó vào project nào chạy cũng dc nhu các package trong fp đi mới có cái mà so sánh ,

hikaruu said:

Ưu việt hơn nó noi hết trong định nghĩa cả 2 rồi , tôi nói rồi code để show cách viết cách reuse thôi , lì vl
Thất bại điển hình nhất là thằng angular , oop tù quá thay đổi éo nổi viết lại cả cái framework từ đầu :]] , angular cũ éo merge lên bản mới dc làm con dân dỗi chuyển hết qua nền tảng khác , kế thừa, đa hình , bao đóng mạnh mẽ là thế đấy,
còn interface là khái niệm chung của lập trình rồi đừng lôi nó như đặc sản của oop vậy , cái cục dll đó nó chỉ xài dc cho project nhà anh thôi, quăng cái dll đó vào project nào chạy cũng dc nhu các package trong fp đi mới có cái mà so sánh ,

Thích Màu Hường said:

Câu này sai. Nói câu này ra thì tôi biết trình anh cỡ nào rồi.

À trước khi bật lại thì anh tìm hiểu kỹ rồi hay reply nhé.

quandaso said:

Tôi thấy ông thiếu kiến thức quá, thiếu kiến thức thì đừng tranh luận. DLL -> dynamic link library ngay cái tên của nó đã nói lên nhiều điều rồi.

lyokha114 said:

Đã gọi là file DLL thì còn bàn cái gì OOP với chả FP trời

hikaruu said:

tôi hiểu sai dòng nào chỉ hộ để cảm ơn cái

hikaruu said:

cái cục dll đó nó chỉ xài dc cho project nhà anh thôi.

naiveryan said:

Nay rảnh đc xíu code Rust trước cho bà con xem và bình phẩm trước, chỗ tôi hiện chỉ có 3G nên chưa tải GHC về đc, Haskell hẹn một hôm ko xa.

1. visualizer.rs

Code:

pub trait Visualization {
    fn special_print(&self) {
        println!("##############")
    }
}

2. customer.rs

Code:

use crate::visualizer::Visualization;
use core::fmt::Debug;

pub trait Printable
where
    Self: Visualization + Debug,
{
    fn customized_print(&self) -> ();

    fn print(&self) -> () {
        self.special_print();
        println!("{:?}", self);
        self.customized_print();
    }
}

#[derive(Debug)]
pub struct BasicInfo {
    pub name: String,
    pub age: u8,
}

#[derive(Debug)]
pub struct BasicCustomer {
    pub info: BasicInfo,
}

impl Visualization for BasicCustomer {}

impl Printable for BasicCustomer {
    fn customized_print(&self) -> () {
        println!("$$$$$$$");
    }
}

#[derive(Debug)]
pub struct VipCustomer {
    pub info: BasicInfo,
    pub vip_point: u8,
}

impl Visualization for VipCustomer {}

impl Printable for VipCustomer {
    fn customized_print(&self) -> () {
        println!("@@@@@@@");
    }
}

#[derive(Debug)]
pub struct InternalCustomer {
    pub info: BasicInfo,
    pub department: String,
}

impl Visualization for InternalCustomer {}

impl Printable for InternalCustomer {
    fn customized_print(&self) -> () {
        println!("&&&&&&&");
    }
}

pub fn get_list_customer() -> Vec<Box<dyn Printable>> {
    let basic = BasicCustomer {
        info: BasicInfo {
            name: "John Smith".into(),
            age: 20,
        },
    };
    let vip = VipCustomer {
        info: BasicInfo {
            name: "Tim Batte".into(),
            age: 30,
        },
        vip_point: 100,
    };
    let internal = InternalCustomer {
        info: BasicInfo {
            name: "Jenny Lars".into(),
            age: 40,
        },
        department: "IT".into(),
    };

    vec![Box::new(basic), Box::new(vip), Box::new(internal)]
}

3. main.rs

Code:

mod customer;
mod visualizer;

fn main() {
    let list = customer::get_list_customer();
    list.into_iter().for_each(|c| c.print())
}

Nhận xét: Cần dek gì Inheritance bạn toi ơi. Bài này interface + generic là quá đủ.

Đầy đủ output, structure chuẩn như lời hứa, còn lại đẹp xấu hay ngon hơn thì mời bà con bình. Output đây cho ai ko quen đọc code imperative.

Code:

##############
BasicCustomer { info: BasicInfo { name: "John Smith", age: 20 } }
$$$$$$$
##############
VipCustomer { info: BasicInfo { name: "Tim Batte", age: 30 }, vip_point: 100 }
@@@@@@@
##############
InternalCustomer { info: BasicInfo { name: "Jenny Lars", age: 40 }, department: "IT" }
&&&&&&&

soihoang said:

self.customized_print(); có tính là functional ko bác :v

f# cũng tương tự nè, mình code trong lúc đợi ... build dự án nên code để máy công ty rồi
post tạm cái hình. Làm như cách của c# interface kiểu customer.printOtherInfo cũng được nhưng mình ... ko thích làm, làm demo cho mọi người coi thôi. Ai tò mò muốn biết fp thế nào thì cứ lập thread hỏi, mình biết gì thì hỗ trợ náy chứ cũng ko máu hơn thua, vì làm cho tới nơi thì mất công mà mình lại lười.

chổ cái Test mình viết thêm cho mọi người thấy là ko cần thêm type Test = ...., mấy cái khác là viết cho ai ko quen với du(discriminated unions)

soihoang said:

self.customized_print(); có tính là functional ko bác :v

f# cũng tương tự nè, mình code trong lúc đợi ... build dự án nên code để máy công ty rồi
post tạm cái hình. Làm như cách của c# interface kiểu customer.printOtherInfo cũng được nhưng mình ... ko thích làm, làm demo cho mọi người coi thôi. Ai tò mò muốn biết fp thế nào thì cứ lập thread hỏi, mình biết gì thì hỗ trợ náy chứ cũng ko máu hơn thua, vì làm cho tới nơi thì mất công mà mình lại lười.

chổ cái Test mình viết thêm cho mọi người thấy là ko cần thêm type Test = ...., mấy cái khác là viết cho ai ko quen với du(discriminated unions)

cugiametruyen85 said:

Cho hỏi nếu làm theo cách này thì làm sau để extend được cái hàm print với type khác nếu mình không phải là tác giả của cái file trên

.

cugiametruyen85 said:

Cho hỏi nếu làm theo cách này thì làm sau để extend được cái hàm print với type khác nếu mình không phải là tác giả của cái file trên

.

The Deep Philosophies​

Of course adherents to both Object Orientation and Functional Programming will protest my reductionist analysis. They will contend that there are deep philosophical, psychological, and mathematical reasons why their favorite style is better than the other.

My reaction to that is: Phooey!

Everybody thinks their way is the best. Everybody is wrong.

FP and OO work nicely together. Both attributes are desirable as part of modern systems. A system that is built on both OO and FP principles will maximize flexibility, maintainability, testability, simplicity, and robustness. Excluding one in favor of the other can only weaken the structure of a system.

naiveryan said:

Nay rảnh đc xíu code Rust trước cho bà con xem và bình phẩm trước, chỗ tôi hiện chỉ có 3G nên chưa tải GHC về đc, Haskell hẹn một hôm ko xa.
Nhận xét: Cần dek gì Inheritance bạn toi ơi. Bài này interface + generic là quá đủ.

Đầy đủ output, structure chuẩn như lời hứa, còn lại đẹp xấu hay ngon hơn thì mời bà con bình. Output đây cho ai ko quen đọc code imperative.

Code:

##############
BasicCustomer { info: BasicInfo { name: "John Smith", age: 20 } }
$$$$$$$
##############
VipCustomer { info: BasicInfo { name: "Tim Batte", age: 30 }, vip_point: 100 }
@@@@@@@
##############
InternalCustomer { info: BasicInfo { name: "Jenny Lars", age: 40 }, department: "IT" }
&&&&&&&

canh_1412 said:

Uncle Bob có bàn nát cái này rồi mà
2014:
View attachment 230707

2018 bác lại nhắc lại:

Kết hợp cả 2 là tốt nhất
https://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html
https://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html

rosario_1 said:

Học tập nghiêm túc không ai thỏa mãn nổi với câu trả lời như vậy bạn ơi. Cá nhân tớ bao giờ phải convert được code từ OOP sang FP và ngược lại thì mới tính là hiểu, còn không là mù.

Vẫn đang hóng câu trả lời của các bạn FP về câu hỏi của "Thích Màu Hường". Tình huống giả sử là viết library cho 3rd party bọn nó dùng đi, bọn nó ko biết và ko có quyền sửa chữa code của mình. Phải viết thế nào để bọn nó reuse và extend được?

Edit: Ví dụ Code như của bạn "soihoang" là fail chặt.

trgiangvp3 said:

Thế mà bác đã dõng dạc tuyên bố từ bỏ OOP ở mấy page trước
Quyết định hơi vội vàng
Nói chung mấy anh FP ở đây vẫn chưa đưa ra được cái gì đáng kể để chứng minh FP vượt trội hoàn toàn so với OOP như lời các anh ý dè bỉu.
Tất cả mới chỉ dừng ở nói mồm kiểu rất là thượng đẳng “FP là nhất, nhưng tôi đéo rảnh thông não các anh, thích thì các anh tự đi mà tìm hiểu”. Đưa được vài cái ví dụ hay code nhưng cũng chẳng thể hiện được gì, bị phản biện thì lại tỏ vẻ thượng đẳng “tôi đéo rảnh blah blah...”
Hóng cực mạnh chờ phản biện từ các anh FP thượng đẳng.

lam vung lau lam said:

C# (~350k loc) to F# (~30k loc)
https://news.ycombinator.com/item?id=14803860

trgiangvp3 said:

Cái này anh phải xem lại nhé.
Nếu chuyển sang F# mà lại dùng nhiều thư viện hơn thì đương nhiên là số loc giảm đi rồi. Nếu số loc giảm là do dùng lib thì không thể nói đó là ưu việt của FP so với OOP.
Ngoài ra 1 số ngôn ngữ có đặc điểm cú pháp dài dòng hơn ngôn ngữ khác (VD java so với kotlin).
Thế nên muốn so sánh số loc thì phải xét thêm các điều kiện đi kèm khác.

Smaller team, smaller code base, fewer bugs, complete implementation of requirements, clearer code. The whole of the F# code base was less than the number of blank lines in the C# code base and a lot more fun to read and write.

trgiangvp3 said:

Cái này anh phải xem lại nhé.
Nếu chuyển sang F# mà lại dùng nhiều thư viện hơn thì đương nhiên là số loc giảm đi rồi. Nếu số loc giảm là do dùng lib thì không thể nói đó là ưu việt của FP so với OOP.
Ngoài ra 1 số ngôn ngữ có đặc điểm cú pháp dài dòng hơn ngôn ngữ khác (VD java so với kotlin).
Thế nên muốn so sánh số loc thì phải xét thêm các điều kiện đi kèm khác.

lam vung lau lam said:

vâng. lập luận không thể thuyết phục hơn. số thư viện của f# chắc hơn c# nhiều lắm.

thế còn ý này?


dự án 350k loc chắc cũng không nhỏ lắm nhỉ.

hikaruu said:

vô link đọc đi bạn, giải thích hết trong đó rồi, tìm sự thật đi đừng tìm lý do nữa

trgiangvp3 said:

Các anh bảo tôi đọc cái gì bây giờ? Nó đâu có show code ra đâu mà đọc.
Tôi không bảo nó chuyển từ C# sang F# là dở hay không. Tất nhiên là về mặt production thì giảm số loc thì team phát triển sẽ đỡ mệt hơn và cần ít người hơn.
Nhưng các anh phải rạch ròi giữa "ưu điểm của ngôn ngữ này so với ngôn ngữ kia" và "ưu điểm của FP so với OOP" chứ

Cái thuyết phục nhất là đợi anh nào implement lại bài tập của thím @Thích Màu Hường bằng một ngôn ngữ FP nào đó rồi xem có gì ưu việt hơn. Lúc đó các anh so số loc thì tôi đồng ý, mà so cái mẹ gì cũng đồng ý. Trước mắt mấy code FP trên kia chưa thấy có gì ưu việt hơn OOP cả.
Tôi dốt nên chờ/nhờ các anh thông não hộ.

Thích Màu Hường said:

Mấy anh rồ FP lại cố moi móc mấy cái ví dụ FP ngắn hơn làm gì. ~350k lc còn ~30k lc thì đã sao? Với tôi nó chỉ cho thấy cái project đó áp dụng FP sẽ tối ưu hơn. Nó không có nghĩa mọi thứ khác đều chuyển qua FP sẽ tối ưu.

Ví dụ thế này nhé: Giả sử làm việc với database cần join data từ 2 table rồi filter các kiểu. Nếu theo declarative style dùng SQL thì chỉ 1 dòng select là xong . Nếu imperative style dùng C/C++ để for loop, join, filter 2 dataset thì code sẽ dài hơn. Nhưng nếu làm game tôi đố các anh convert qua FP mà mong code ngắn hơn đó.

lam vung lau lam said:

làm game người ta dùng ECS chứ cũng chả dùng OOP.

buonnguqua said:

Really ?
Unity làm chơi thử nghiệm mới dám ECS chứ làm thật với dự án game kinh phí trên 100k $ thôi cũng bố ai dám
Còn các games engine khác vẫn OOP hết

tthixk said:

cười ỉa mấy con lợn dùng pattern matching hay enum type cho bài convert Oop qua fp ))) scale lên thêm type thì add thêm case cho matching? Đúng là bọn lợn đi code )))))))

soihoang said:

đang coi purescript có vẻ vui nên code thử nè , đợi cuối tuần hứng hứng se làm kĩ hơn



https://try.purescript.org/

Code:

module Main where

import Prelude
import Effect (Effect)
import Effect.Console (log)

data BasicInfo = BasicInfo
  { name :: String
  , age  :: Int
  }

newtype Customer = Customer { basicInfo :: BasicInfo}

newtype VipCustomer = VipCustomer
  { basicInfo :: BasicInfo
  , vipPoint :: Int
  }

newtype InternalCustomer = InternalCustomer
  { basicInfo :: BasicInfo
  , department :: String
  }

class Visualization user where
  print :: user -> Effect Unit

instance basicInfoViz :: Visualization BasicInfo where
  print (BasicInfo info) = do
    log "########################"
    log "Basic"

instance customerViz :: Visualization Customer where
  print (Customer customer) = do
    print customer.basicInfo
    log "$$$$$$$$$$$$$$$$$$$$$$$"

instance vipCustomerViz :: Visualization VipCustomer where
  print (VipCustomer customer) = do
    print customer.basicInfo
    log  ("Vip point = " <> (show customer.vipPoint))
    log  "$$$$$$$$$$$$$$$$$$$$$$$"

instance internalCustomerViz :: Visualization InternalCustomer where
  print (InternalCustomer customer) = do
    print customer.basicInfo
    log "InternalCustomer"
    log  ("Department = " <> (show customer.department))
    log "@@@@@@@@@@@@@@@@@@@@@@@"

basic = BasicInfo {name: "nhat", age: 123}
customer = Customer { basicInfo: basic}
internal = InternalCustomer { basicInfo: basic, department: "IT"}
vip = VipCustomer { basicInfo: basic, vipPoint: 100}

main :: Effect Unit
main = do
  print customer
  print vip
  print internal

public void Print(IPrintable printable)
{
    // Step 1
    Console.WriteLine("\n#######################################################");
    
    // Step 2 (project khác sử dụng hàm Print có thể custom được)
    printable.CustomPrint();     

    // Step 3

    // Step 4

    // Step 5

    // ...

    // Step n
}

frozeblade2579 said:

React thì nên học từ class rồi tới hook mới hiểu bản chất của nó rồi mốt xài linh động cả 2 cái, chả cái nào hơn cái nào

inteface Vehicle {
    String getEngine();
    void simulate();
}

• Mặc định các phương tiện giao thông sẽ có động cơ là động cơ hơi nước "steam-engine". Chương trình simulation mặc định khi bắt đầu chạy sẽ in ra tên động cơ phương tiện.
• Có ba loại phương tiện giao thông chính là xe ô tô, máy bay và tàu ngầm. Đối với ô tô (Car) sẽ có chung một phương thức điều khiển là (drive). Đối với máy bay (Aircraft) sẽ có chung phương thức điều khiển là (pilot). Đối với tàu ngầm (Submarine) sẽ có chung phương thức điều khiển là (dive). Ngoài ra chương trình có thể có thêm phương tiện giao thông khác như tàu hỏa (Train).
• Mặc định đối với xe ô tô khi gọi hàm simulate thực hiện hàm drive, đối với máy bay sẽ thực hiện hàm pilot và đối với tàu ngầm sẽ thực hiện hàm dive. Xe ô tô thực hiện hàm drive sẽ in ra tên động cơ của mình, tương tự với hàm pilot của máy bay và và hàm dive của tầu ngầm
• Xe ô tô mặc định sử dụng động cơ bốn kì "four-stroke engine". Máy bay mặc định sử dụng động cơ turbin quạt gió "turbofan engine". Tàu ngầm mặc định sử dụng động cơ xăng dầu "gasoline engine".
• Khi lái xe ô tô sẽ in ra tên động cơ và chuỗi kí tự "##########". Khi bay máy bay sẽ in ra tên động cơ và chuối kí tự ">>>>>>>>>>>>>>>". Khi lặn tàu ngầm sẽ in tên động cơ và chuỗi kí tự là "&&&&&&&&&&&&&&"

1. Hãy xây dựng và mô phỏng phương tiện là tàu hỏa với động cơ và cách lái mặc định.
2. Hãy xây dựng phương tiện là xe Ferrari với động cơ là "F154" và cách lái của xe ô tô mặc định.
3. Hãy xây dựng một loại siêu phương tiện kết hợp ô tô, máy bay và tàu ngầm sao cho khi chạy trên đường thì sẽ sử dụng động cơ mặc định của xe ô tô, khi bay trên không sẽ sử dụng động cơ mặc định của máy bay, khi di chuyển dưới nước sẽ sử dụng động cơ mặc định của tàu ngầm. Khi thực hiện mô phỏng sẽ in ra tên động cơ là "hybrid" và sau đó lần lượt thực hiện các phương thức là di chuyển mặt đất, bay lên không trung rồi lặn xuống nước.
4. Optional. Xây dựng siêu phương tiện với động cơ và cách lái khi chạy trên đường của xe Ferrari, động cơ và cách lái khi bay của máy bay Boeing và động cơ và cách lái của tàu ngầm mặc định.

ngkhoahoang said:

Mình phải cảm ơn bạn @Thích Màu Hường khá là nhiều. Nhờ bài toán của bạn mà mình đã được tìm hiểu được rất nhiều về Haskell.

Đây là link repo lời giải của mình: https://github.com/clitetailor/functional-challenges

Sau đây, để đáp lại sự mong mỏi của tất cả mọi người. Mình xin được triệu hồi "một trong" những kẻ thù cũ của OOP là đa kế thừa. Bài toán của mình như sau:

---

Xây dựng một chương trình mô phỏng các phương tiện giao thông. Đối với mỗi phương tiện giao thông sẽ có hai thông tin chính: Một là (getEngine) sẽ trả về thông tin là tên của động cơ phương tiện đang sử dụng. Hai là (simulate) là chương trình mô phỏng hoạt động của phương tiện.

C#:

inteface Vehicle {
    String getEngine();
    void simulate();
}

• Mặc định các phương tiện giao thông sẽ có động cơ là động cơ hơi nước "steam-engine". Chương trình simulation mặc định khi bắt đầu chạy sẽ in ra tên động cơ phương tiện.
• Có ba loại phương tiện giao thông chính là xe ô tô, máy bay và tàu ngầm. Đối với ô tô (Car) sẽ có chung một phương thức điều khiển là (drive). Đối với máy bay (Aircraft) sẽ có chung phương thức điều khiển là (pilot). Đối với tàu ngầm (Submarine) sẽ có chung phương thức điều khiển là (dive). Ngoài ra chương trình có thể có thêm phương tiện giao thông khác như tàu hỏa (Train).
• Mặc định đối với xe ô tô khi gọi hàm simulate thực hiện hàm drive, đối với máy bay sẽ thực hiện hàm pilot và đối với tàu ngầm sẽ thực hiện hàm dive. Xe ô tô thực hiện hàm drive sẽ in ra tên động cơ của mình, tương tự với hàm pilot của máy bay và và hàm dive của tầu ngầm
• Xe ô tô mặc định sử dụng động cơ bốn kì "four-stroke engine". Máy bay mặc định sử dụng động cơ turbin quạt gió "turbofan engine". Tàu ngầm mặc định sử dụng động cơ xăng dầu "gasoline engine".
• Khi lái xe ô tô sẽ in ra tên động cơ và chuỗi kí tự "##########". Khi bay máy bay sẽ in ra tên động cơ và chuối kí tự ">>>>>>>>>>>>>>>". Khi lặn tàu ngầm sẽ in tên động cơ và chuỗi kí tự là "&&&&&&&&&&&&&&"

Yêu cầu của đề bài là:

1. Hãy xây dựng và mô phỏng phương tiện là tàu hỏa với động cơ và cách lái mặc định.
2. Hãy xây dựng phương tiện là xe Ferrari với động cơ là "F154" và cách lái của xe ô tô mặc định.
3. Hãy xây dựng một loại siêu phương tiện kết hợp ô tô, máy bay và tàu ngầm sao cho khi chạy trên đường thì sẽ sử dụng động cơ mặc định của xe ô tô, khi bay trên không sẽ sử dụng động cơ mặc định của máy bay, khi di chuyển dưới nước sẽ sử dụng động cơ mặc định của tàu ngầm. Khi thực hiện mô phỏng sẽ in ra tên động cơ là "hybrid" và sau đó lần lượt thực hiện các phương thức là di chuyển mặt đất, bay lên không trung rồi lặn xuống nước.
4. Optional. Xây dựng siêu phương tiện với động cơ và cách lái khi chạy trên đường của xe Ferrari, động cơ và cách lái khi bay của máy bay Boeing và động cơ và cách lái của tàu ngầm mặc định.

Phương pháp giải và kết quả mình xin được phép giữ. Các bạn có thể từ chối giải bài toán này nếu thấy không hợp lý. Nhận xét sẽ có sau khi có người post lời giải cho phương pháp OOP lên.

Thích Màu Hường said:

Thanks thím, chưa xem kỹ vì không biết syntax của Rust phải vừa xem vừa Google nhưng trước khi mọi người so sánh có 2 điểm thím cần update để đúng đề bài:

1. Theo cách tổ chức code như này thì hàm print nằm trong Printable thuộc module customer.rs. Ví dụ có project khác là in thông tin Vozer, in hóa đơn, in employee vốn ko liên quan gì customer nhưng muốn sử dụng hàm print thì phải có dependency là customer.rs. ~~~~~> Cái này thì chỉ cần move Printable vào trong module visualizer.cs là được.

Thấy thím tách ra special với custom print nên nói lại cho rõ: Cái phần custom print là logic con của hàm print dùng để in các fields được thực hiện tuần tự sau phần "đặc biêt" là in "#####". Xem như hàm print là 1 process có 2 steps luôn đi cùng nhau: step 1 in "#####", step 2 in custom. Cái logic 2 steps gói trong hàm print này là cái thuộc phần core và fixed (process flow tuần tự step 1 -> step 2 không được thay đổi) và nó phải được reuse ở các project khác trong đó step 2 có thể cho người ta custom.

2. Cái phần thông tin chi tiết (Name, Age, VipPoints, Department) phải in ra từng field ra output đúng format như bên C# (tôi đã update cái ouput của code C# trong post đề bài). Hiện tài thím dùng println!("{:?}", self); là ăn gian. Cái phần này phải move nó vào trong custom print để đảm bảo không break process flow 2 steps của hàm print như đã nói ở trên với lại có thể format lúc in cho từng loại customer dc như bên code C#. ~~~~~~> làm vậy thì không có kế thừa thím phải gọi hàm nhiều chổ lúc in BasicInfo

P/s: sau cái này có thể tôi sẽ ví dụ thêm nhiều cái change requests dể giả lập implement mấy cái AOP như validation, authorized, logging túm lại thêm nhiều layer xung quanh business domain xem lúc project scale tới tầm enterprise các FP expert sửa code bao nhiêu chổ hay đập đi xây lai.

Nipin said:

tôi nhớ là rust có enum type mà nhỉ, rút gọn code được kha khá. tất nhiên làm sao enum cho chuẩn cũng tốn tế bào não phết :/

ngkhoahoang said:

Mình phải cảm ơn bạn @Thích Màu Hường khá là nhiều. Nhờ bài toán của bạn mà mình đã được tìm hiểu được rất nhiều về Haskell.

Đây là link repo lời giải của mình: https://github.com/clitetailor/functional-challenges

Sau đây, để đáp lại sự mong mỏi của tất cả mọi người. Mình xin được triệu hồi "một trong" những kẻ thù cũ của OOP là đa kế thừa. Bài toán của mình như sau:

---

Xây dựng một chương trình mô phỏng các phương tiện giao thông. Đối với mỗi phương tiện giao thông sẽ có hai thông tin chính: Một là (getEngine) sẽ trả về thông tin là tên của động cơ phương tiện đang sử dụng. Hai là (simulate) là chương trình mô phỏng hoạt động của phương tiện.

C#:

inteface Vehicle {
    String getEngine();
    void simulate();
}

• Mặc định các phương tiện giao thông sẽ có động cơ là động cơ hơi nước "steam-engine". Chương trình simulation mặc định khi bắt đầu chạy sẽ in ra tên động cơ phương tiện.
• Có ba loại phương tiện giao thông chính là xe ô tô, máy bay và tàu ngầm. Đối với ô tô (Car) sẽ có chung một phương thức điều khiển là (drive). Đối với máy bay (Aircraft) sẽ có chung phương thức điều khiển là (pilot). Đối với tàu ngầm (Submarine) sẽ có chung phương thức điều khiển là (dive). Ngoài ra chương trình có thể có thêm phương tiện giao thông khác như tàu hỏa (Train).
• Mặc định đối với xe ô tô khi gọi hàm simulate thực hiện hàm drive, đối với máy bay sẽ thực hiện hàm pilot và đối với tàu ngầm sẽ thực hiện hàm dive. Xe ô tô thực hiện hàm drive sẽ in ra tên động cơ của mình, tương tự với hàm pilot của máy bay và và hàm dive của tầu ngầm
• Xe ô tô mặc định sử dụng động cơ bốn kì "four-stroke engine". Máy bay mặc định sử dụng động cơ turbin quạt gió "turbofan engine". Tàu ngầm mặc định sử dụng động cơ xăng dầu "gasoline engine".
• Khi lái xe ô tô sẽ in ra tên động cơ và chuỗi kí tự "##########". Khi bay máy bay sẽ in ra tên động cơ và chuối kí tự ">>>>>>>>>>>>>>>". Khi lặn tàu ngầm sẽ in tên động cơ và chuỗi kí tự là "&&&&&&&&&&&&&&"

Yêu cầu của đề bài là:

1. Hãy xây dựng và mô phỏng phương tiện là tàu hỏa với động cơ và cách lái mặc định.
2. Hãy xây dựng phương tiện là xe Ferrari với động cơ là "F154" và cách lái của xe ô tô mặc định.
3. Hãy xây dựng một loại siêu phương tiện kết hợp ô tô, máy bay và tàu ngầm sao cho khi chạy trên đường thì sẽ sử dụng động cơ mặc định của xe ô tô, khi bay trên không sẽ sử dụng động cơ mặc định của máy bay, khi di chuyển dưới nước sẽ sử dụng động cơ mặc định của tàu ngầm. Khi thực hiện mô phỏng sẽ in ra tên động cơ là "hybrid" và sau đó lần lượt thực hiện các phương thức là di chuyển mặt đất, bay lên không trung rồi lặn xuống nước.
4. Optional. Xây dựng siêu phương tiện với động cơ và cách lái khi chạy trên đường của xe Ferrari, động cơ và cách lái khi bay của máy bay Boeing và động cơ và cách lái của tàu ngầm mặc định.

Phương pháp giải và kết quả mình xin được phép giữ. Các bạn có thể từ chối giải bài toán này nếu thấy không hợp lý. Nhận xét sẽ có sau khi có người post lời giải cho phương pháp OOP lên.

There is one final feature of Haskell's type system that sets it apart from other programming languages. The kind of polymorphism that we have talked about so far is commonly called parametric polymorphism. There is another kind called ad hoc polymorphism, better known as overloading. Here are some examples of ad hoc polymorphism:

naiveryan said:

Đã update code rust, b xem lại xem đúng y/c đề chưa. Còn AoP cho hỏi có lq gì đến OOP ko bạn?

#######################################################
Name = John Smith
Age = 20
$$$$$$$$$$$$$$$$$$$$$$$

#######################################################
Name = Tim Batte
Age = 30
VipPoints = 100  //<<<<<<<<<<< Thiếu chỗ này
@@@@@@@@@@@@@@@@@@@@@@@

#######################################################
Name = Jenny Lars
Age = 40
Department = IT  //<<<<<<<<<<< Thiếu chỗ này
&&&&&&&&&&&&&&&&&&&&&&&

ngkhoahoang said:

Mình phải cảm ơn bạn @Thích Màu Hường khá là nhiều. Nhờ bài toán của bạn mà mình đã được tìm hiểu được rất nhiều về Haskell.

Đây là link repo lời giải của mình: https://github.com/clitetailor/functional-challenges

Sau đây, để đáp lại sự mong mỏi của tất cả mọi người. Mình xin được triệu hồi "một trong" những kẻ thù cũ của OOP là đa kế thừa. Bài toán của mình như sau:

---

Xây dựng một chương trình mô phỏng các phương tiện giao thông. Đối với mỗi phương tiện giao thông sẽ có hai thông tin chính: Một là (getEngine) sẽ trả về thông tin là tên của động cơ phương tiện đang sử dụng. Hai là (simulate) là chương trình mô phỏng hoạt động của phương tiện.

C#:

inteface Vehicle {
    String getEngine();
    void simulate();
}

• Mặc định các phương tiện giao thông sẽ có động cơ là động cơ hơi nước "steam-engine". Chương trình simulation mặc định khi bắt đầu chạy sẽ in ra tên động cơ phương tiện.
• Có ba loại phương tiện giao thông chính là xe ô tô, máy bay và tàu ngầm. Đối với ô tô (Car) sẽ có chung một phương thức điều khiển là (drive). Đối với máy bay (Aircraft) sẽ có chung phương thức điều khiển là (pilot). Đối với tàu ngầm (Submarine) sẽ có chung phương thức điều khiển là (dive). Ngoài ra chương trình có thể có thêm phương tiện giao thông khác như tàu hỏa (Train).
• Mặc định đối với xe ô tô khi gọi hàm simulate thực hiện hàm drive, đối với máy bay sẽ thực hiện hàm pilot và đối với tàu ngầm sẽ thực hiện hàm dive. Xe ô tô thực hiện hàm drive sẽ in ra tên động cơ của mình, tương tự với hàm pilot của máy bay và và hàm dive của tầu ngầm
• Xe ô tô mặc định sử dụng động cơ bốn kì "four-stroke engine". Máy bay mặc định sử dụng động cơ turbin quạt gió "turbofan engine". Tàu ngầm mặc định sử dụng động cơ xăng dầu "gasoline engine".
• Khi lái xe ô tô sẽ in ra tên động cơ và chuỗi kí tự "##########". Khi bay máy bay sẽ in ra tên động cơ và chuối kí tự ">>>>>>>>>>>>>>>". Khi lặn tàu ngầm sẽ in tên động cơ và chuỗi kí tự là "&&&&&&&&&&&&&&"

Yêu cầu của đề bài là:

1. Hãy xây dựng và mô phỏng phương tiện là tàu hỏa với động cơ và cách lái mặc định.
2. Hãy xây dựng phương tiện là xe Ferrari với động cơ là "F154" và cách lái của xe ô tô mặc định.
3. Hãy xây dựng một loại siêu phương tiện kết hợp ô tô, máy bay và tàu ngầm sao cho khi chạy trên đường thì sẽ sử dụng động cơ mặc định của xe ô tô, khi bay trên không sẽ sử dụng động cơ mặc định của máy bay, khi di chuyển dưới nước sẽ sử dụng động cơ mặc định của tàu ngầm. Khi thực hiện mô phỏng sẽ in ra tên động cơ là "hybrid" và sau đó lần lượt thực hiện các phương thức là di chuyển mặt đất, bay lên không trung rồi lặn xuống nước.
4. Optional. Xây dựng siêu phương tiện với động cơ và cách lái khi chạy trên đường của xe Ferrari, động cơ và cách lái khi bay của máy bay Boeing và động cơ và cách lái của tàu ngầm mặc định.

Phương pháp giải và kết quả mình xin được phép giữ. Các bạn có thể từ chối giải bài toán này nếu thấy không hợp lý. Nhận xét sẽ có sau khi có người post lời giải cho phương pháp OOP lên.

ngkhoahoang said:

... blah blah...
Yêu cầu của đề bài là:

1. Hãy xây dựng và mô phỏng phương tiện là tàu hỏa với động cơ và cách lái mặc định.
2. Hãy xây dựng phương tiện là xe Ferrari với động cơ là "F154" và cách lái của xe ô tô mặc định.
3. Hãy xây dựng một loại siêu phương tiện kết hợp ô tô, máy bay và tàu ngầm sao cho khi chạy trên đường thì sẽ sử dụng động cơ mặc định của xe ô tô, khi bay trên không sẽ sử dụng động cơ mặc định của máy bay, khi di chuyển dưới nước sẽ sử dụng động cơ mặc định của tàu ngầm. Khi thực hiện mô phỏng sẽ in ra tên động cơ là "hybrid" và sau đó lần lượt thực hiện các phương thức là di chuyển mặt đất, bay lên không trung rồi lặn xuống nước.
4. Optional. Xây dựng siêu phương tiện với động cơ và cách lái khi chạy trên đường của xe Ferrari, động cơ và cách lái khi bay của máy bay Boeing và động cơ và cách lái của tàu ngầm mặc định.

naiveryan said:

Đã update code rust, b xem lại xem đúng y/c đề chưa. Còn AoP cho hỏi có lq gì đến OOP ko bạn?

Thích Màu Hường said:

Thím update cái phần in VipPoints, in Department như bạn trên có nói. À mà post source ra post mới luôn, đừng update cái cũ để người ta dễ đọc.

Tôi dùng từ AOP có thể không chính xác nhưng ý muốn nói là cái đề bài kia mới chỉ là "khúc dạo đầu" thôi. Để xem lúc project này scale lên, có requirement để implement thêm các "khía cạnh khác" xoay quanh business domain như logging, authorized, validation thì các anh FP làm như nào

vothevinh said:

thế thì vd xem "bên chú" authorized, validation dư lào?

vothevinh said:

thế thì vd xem "bên chú" authorized, validation dư lào?

Thích Màu Hường said:

Tôi dùng từ AOP có thể không chính xác nhưng ý muốn nói là cái đề bài kia mới chỉ là "khúc dạo đầu" thôi. Để xem lúc project này scale lên, có requirement để implement thêm các "khía cạnh khác" xoay quanh business domain như logging, authorized, validation thì các anh FP làm như nào

trgiangvp3 said:

Code của anh thiếu phần in ra thông tin đặc biệt của từng loại user và bị lặp ở chỗ gọi hàm self.info.print_info(); (cứ thêm loại user mới thì đều phải thêm lời gọi hàm self.info.print_info() )

C#:

#######################################################
Name = John Smith
Age = 20
$$$$$$$$$$$$$$$$$$$$$$$

#######################################################
Name = Tim Batte
Age = 30
VipPoints = 100  //<<<<<<<<<<< Thiếu chỗ này
@@@@@@@@@@@@@@@@@@@@@@@

#######################################################
Name = Jenny Lars
Age = 40
Department = IT  //<<<<<<<<<<< Thiếu chỗ này
&&&&&&&&&&&&&&&&&&&&&&&

quandaso said:

Cái hay OOP là bạn muốn code thế cc như nào cũng đc. Thích thì kế thừa, thích thì static method, thích reflection, vân vân và vân vân
Ko ai bắt phải pure nọ pure chai. Bài của bạn có tỉ cách implement. Mình thợ code chỉ implement như này thôi (không dùng đa kế thừa nhé, mà inject)
https://gist.github.com/quandaso/4e02db042f03979ea3d1438365b3d444

p/s: tôi đọc qua cái solution của bạn vẫn thấy dùng class cho class Visualizer customerType where, bạn dùng class thì chẳng phải đang dùng polymorphism, overloading của OOP đó sao?

Ref: https://www.haskell.org/tutorial/classes.html
Mình chưa code FP,hashkell bao giờ, liệu mình có nhầm gì không. Mong được thông não?

cugiametruyen85 said:

Đó h có dùng Spring hay Dotnet không mà hỏi thế vậy bác

AOP có phải OOP đâu thím

naiveryan said:

Bạn có hiểu pure là gì ko và ai ép bạn code pure?
Polymorphism nào của OOP, nhận vơ vào à -))
Cả Overload cũng vậy, các anh OOP giỏi nhận vơ.

Còn typeclass của Haskell nó giống interface bên C#/Java chứ k phải "class" như mấy anh nghĩ, đừng có bảo là interface cũng là của OOP nhé?

quandaso said:

thế interface chả từ bên OOP sang là gì, hay ông bảo không phải? Thế polymorphism là không từ OOP thì từ đâu?

naiveryan said:

Hahaha. Oop bá đạo quá. Hahaha. Buồn cười vãi. Coder như thế này bảo sao Oop đc thần thánh quá đáng.

cugiametruyen85 said:

Đó h có dùng Spring hay Dotnet không mà hỏi thế vậy bác

AOP có phải OOP đâu thím

vothevinh said:

tất cả các framework mà tôi từng xài như laravel, symfony, elixir phoenix, express, flask, rails, ... đều có chung 1 idea để authentication, authorization, logging với validation hết. Tự hỏi OOP với FP thì có khác biệt gì chăng?

quandaso said:

ờ tôi là thợ code mà, có biết FP là cc gì đâu. Anh muốn đọ sản phẩm tôi làm so với sp anh làm không. Xem anh làm FP có vượt trội so với tôi không?

naiveryan said:

self.info.print_into() call lại có vấn đề gì sao?

naiveryan said:

Tôi post lại code cho dễ theo dõi, đã thêm custom info
...

• Nó chứa những gì (data)
• Nó có thể làm được những gì. (behavior)

• data (struct)
• behavior (trait)
• data - behavior association (impl)

• Compiler có đảm bảo cái mớ association phủ hết không (ví dụ trong trường hợp tôi không cung cấp impl thì compiler có báo lỗi không.
• Cohesion: 3 phần ở mỗi nơi như thế, tôi nhìn vào customer không biết nó thể làm được gì. Nhìn vào 2 loại customer khác nhau không biết nó share những trait gì.
  Ví dụ trong Java tôi có 2 class A và B, tôi chỉ cần nhìn nó impl những interface nào là biết nó share những behaviour nào ngay. Nói đơn giản trong Java data + behavior là 1 mớ đi liền. Điều này làm giảm cognitive overhead thấy rõ, nhìn vào 1 class tôi biết nó chứa gì trong đó và tôi có thể làm được gì với mớ data đó.
• Compile time: Việc không khai báo explicit chắc chắn sẽ làm tăng compile time. Vì 3 cái mớ đó là riêng biệt hoàn toàn, giả sử tôi gọi customer.print_info(), compiler phải xác định impl của thằng customer nào match với trait nào. Trong khi anh Java compiler nó biết ngay class này impl interface nào, việc xác định là vô cùng dễ.

naiveryan said:

Về gúc gồ lại polymorphism là gì và lịch sử đi đã rồi hãy nói tiếp đi bạn ơi. Tôi k rảnh tiếp bạn ok?

quandaso said:

Ờ polymorphism thì đương nhiên là không phải oop, nhưng chỉ trong OOP polymorphism mới đầy đủ nhất. Các ngôn ngữ Functional sau này chả vay mượn từ java, c#.
Ngoài ra, các ông impelement interface đó khác gì OOP nào, tốt hơn chỗ nào. Giải thích hộ cho thợ code với, ngu quá đ*o hiểu nó hơn chỗ nào

naiveryan said:

Đầy đủ hơn chỗ nào nói nghe chơi đi đại hiệp?

Fp vay mượn java c# cái j cũng nói nghe chơi đi. Sinh sau đẻ muộn vay mượn expression của fp nhét vào ngta chưa thèm nói đến còn đi tố ngược.

Ps tôi ol đth nên trả lời đại hiệp mù software history này trc mấy bài về code sẽ rep sau.

Objection 1. Data structure and functions should not be bound together
Objects bind functions and data structures together in indivisible units. I think this is a fundamental error since functions and data structures belong in totally different worlds. Why is this?

Functions do things. They have inputs and outputs. The inputs and outputs are data structures, which get changed by the functions. In most languages functions are built from sequences of imperatives: “Do this and then that …”. To understand functions you have to understand the order in which things get done. (In lazy FPLs and logical languages this restriction is relaxed.)
Data structures just are. They don't do anything. They are intrinsically declarative. “Understanding” a data structure is a lot easier than “understanding” a function.
Functions are understood as black boxes that transform inputs to outputs. If I understand the input and the output then I have understood the function. This does not mean to say that I could have written the function.

Functions are usually “understood” by observing that they are the things in a computational system whose job is to transfer data structures of type T1 into data structure of type T2.

Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage.

naiveryan said:

self.info.print_into() call lại có vấn đề gì sao?

quandaso said:

1. Vay mượn thì hơi quá, nhưng lấy cảm hứng từ máy ảo java thì có 1 vài như: kotlin , scalar.
2. polymorphism đẩy đủ hơn chỗ nào thì nhìn code ông impelement là thấy tù vkl so với bên C# rồi, lại còn hỏi nữa?

cugiametruyen85 said:

Mình dẫn lại lời Joe Armstrong. Mình cho đây là 1 tư tưởng good in theory bad in practice.
Vì khi anh tách function và data ra làm 2 phần đi thì anh mất đi 1 thứ rất quan trọng: discoverability. Đó là thuộc tính trả lời cho câu hỏi "Tôi có thể làm được những gì với mớ data này" (và câu hỏi này vô cùng quan trọng nếu project phình to lên). Làm thế nào anh biết thằng customer có method print_info mà gọi.
Và đây là vấn đề, con nghĩ tư duy bằng dưới góc nhìn object chứ không phải function, thằng a nó là người, con người có thể ăn, ngủ, đ*t ỉa, therefore thằng A có thể ăn, ngủ, đ*t, ỉa.
Mặc dù OOP về mặt theory là không đúng vì đếch phải cái gì cũng phân loại được nhưng nó fit với tư duy của con người, và điều này là vô cùng quan trọng để collaboration.

naiveryan said:

Lol jvm thì liên quan què gì đến oop đây nữa đại hiệp. Đek hiểu đào đâu ra ông dev nào nhận vơ cả polymorphism, interface, overload rồi cả cái jvm vào bảo là bửu bối của oop và fp phải vay mượn. Sự thật là fp đek vay mượn j từ Oop cả và Oop thì đem cả lambda expression vào rồi đó.

Đã sai về lịch sử lại còn cố gượng bảo polymorphism của Oop xịn hơn vì code tù, tù cái gì đây bạn?

tornado said:

Cuối cùng thì FP ưu việt hơn chỗ nào vậy các bác?

Nipin said:

https://wiki.c2.com/?FunctionalProgramming, nhớ đọc thêm cả các bài báo liên quan trong đó.

nhân tiện thì tôi đọc lướt qua cái thread này thôi, nhưng thấy vụ tranh luận trong này đều được trả lời ở đây thì phải: https://wiki.c2.com/?FunctionalModeling, bạn nào hứng thú thì có thể đọc, trong đó nó có link đến https://wiki.c2.com/?OopNotForDomainModeling các kiểu.

nhân tiện các bạn có thể kéo xuống dưới cùng xem thời gian chỉnh sửa của mỗi bài viết :/

quandaso said:

Cái hay OOP là bạn muốn code thế cc như nào cũng đc. Thích thì kế thừa, thích thì static method, thích reflection, vân vân và vân vân
Ko ai bắt phải pure nọ pure chai. Bài của bạn có tỉ cách implement. Mình thợ code chỉ implement như này thôi (không dùng đa kế thừa nhé, mà inject)
https://gist.github.com/quandaso/4e02db042f03979ea3d1438365b3d444

p/s: tôi đọc qua cái solution của bạn vẫn thấy dùng class cho class Visualizer customerType where, bạn dùng class thì chẳng phải đang dùng polymorphism, overloading của OOP đó sao?

Ref: https://www.haskell.org/tutorial/classes.html
Mình chưa code FP,hashkell bao giờ, liệu mình có nhầm gì không. Mong được thông não?

I think there's good evidence that this isn't just a run of the mill "grass is greener" grousing by experts. Here's a challenge. Can you name a contemporary expert or a platform that started or spent a good chunk of time as FP and ran back towards OOP (I would say since 1990 or so, as it is a thing that FPs had very poor performance before that era)?

ngkhoahoang said:

Mình phải cảm ơn bạn @Thích Màu Hường khá là nhiều. Nhờ bài toán của bạn mà mình đã được tìm hiểu được rất nhiều về Haskell.

Đây là link repo lời giải của mình: https://github.com/clitetailor/functional-challenges

Sau đây, để đáp lại sự mong mỏi của tất cả mọi người. Mình xin được triệu hồi "một trong" những kẻ thù cũ của OOP là đa kế thừa. Bài toán của mình như sau:

---

Xây dựng một chương trình mô phỏng các phương tiện giao thông. Đối với mỗi phương tiện giao thông sẽ có hai thông tin chính: Một là (getEngine) sẽ trả về thông tin là tên của động cơ phương tiện đang sử dụng. Hai là (simulate) là chương trình mô phỏng hoạt động của phương tiện.

C#:

inteface Vehicle {
    String getEngine();
    void simulate();
}

• Mặc định các phương tiện giao thông sẽ có động cơ là động cơ hơi nước "steam-engine". Chương trình simulation mặc định khi bắt đầu chạy sẽ in ra tên động cơ phương tiện.
• Có ba loại phương tiện giao thông chính là xe ô tô, máy bay và tàu ngầm. Đối với ô tô (Car) sẽ có chung một phương thức điều khiển là (drive). Đối với máy bay (Aircraft) sẽ có chung phương thức điều khiển là (pilot). Đối với tàu ngầm (Submarine) sẽ có chung phương thức điều khiển là (dive). Ngoài ra chương trình có thể có thêm phương tiện giao thông khác như tàu hỏa (Train).
• Mặc định đối với xe ô tô khi gọi hàm simulate thực hiện hàm drive, đối với máy bay sẽ thực hiện hàm pilot và đối với tàu ngầm sẽ thực hiện hàm dive. Xe ô tô thực hiện hàm drive sẽ in ra tên động cơ của mình, tương tự với hàm pilot của máy bay và và hàm dive của tầu ngầm
• Xe ô tô mặc định sử dụng động cơ bốn kì "four-stroke engine". Máy bay mặc định sử dụng động cơ turbin quạt gió "turbofan engine". Tàu ngầm mặc định sử dụng động cơ xăng dầu "gasoline engine".
• Khi lái xe ô tô sẽ in ra tên động cơ và chuỗi kí tự "##########". Khi bay máy bay sẽ in ra tên động cơ và chuối kí tự ">>>>>>>>>>>>>>>". Khi lặn tàu ngầm sẽ in tên động cơ và chuỗi kí tự là "&&&&&&&&&&&&&&"

Yêu cầu của đề bài là:

1. Hãy xây dựng và mô phỏng phương tiện là tàu hỏa với động cơ và cách lái mặc định.
2. Hãy xây dựng phương tiện là xe Ferrari với động cơ là "F154" và cách lái của xe ô tô mặc định.
3. Hãy xây dựng một loại siêu phương tiện kết hợp ô tô, máy bay và tàu ngầm sao cho khi chạy trên đường thì sẽ sử dụng động cơ mặc định của xe ô tô, khi bay trên không sẽ sử dụng động cơ mặc định của máy bay, khi di chuyển dưới nước sẽ sử dụng động cơ mặc định của tàu ngầm. Khi thực hiện mô phỏng sẽ in ra tên động cơ là "hybrid" và sau đó lần lượt thực hiện các phương thức là di chuyển mặt đất, bay lên không trung rồi lặn xuống nước.
4. Optional. Xây dựng siêu phương tiện với động cơ và cách lái khi chạy trên đường của xe Ferrari, động cơ và cách lái khi bay của máy bay Boeing và động cơ và cách lái của tàu ngầm mặc định.

Phương pháp giải và kết quả mình xin được phép giữ. Các bạn có thể từ chối giải bài toán này nếu thấy không hợp lý. Nhận xét sẽ có sau khi có người post lời giải cho phương pháp OOP lên.

Mặc định các phương tiện giao thông sẽ có động cơ là động cơ hơi nước "steam-engine". Chương trình simulation mặc định khi bắt đầu chạy sẽ in ra tên động cơ phương tiện.

Có ba loại phương tiện giao thông chính là xe ô tô, máy bay và tàu ngầm. Đối với ô tô (Car) sẽ có chung một phương thức điều khiển là (drive). Đối với máy bay (Aircraft) sẽ có chung phương thức điều khiển là (pilot). Đối với tàu ngầm (Submarine) sẽ có chung phương thức điều khiển là (dive). Ngoài ra chương trình có thể có thêm phương tiện giao thông khác như tàu hỏa (Train).

Mặc định đối với xe ô tô khi gọi hàm simulate thực hiện hàm drive, đối với máy bay sẽ thực hiện hàm pilot và đối với tàu ngầm sẽ thực hiện hàm dive. Xe ô tô thực hiện hàm drive sẽ in ra tên động cơ của mình, tương tự với hàm pilot của máy bay và và hàm dive của tầu ngầm

Xe ô tô mặc định sử dụng động cơ bốn kì "four-stroke engine". Máy bay mặc định sử dụng động cơ turbin quạt gió "turbofan engine". Tàu ngầm mặc định sử dụng động cơ xăng dầu " gasoline engine".

Khi lái xe ô tô sẽ in ra tên động cơ và chuỗi kí tự "##########". Khi bay máy bay sẽ in ra tên động cơ và chuối kí tự ">>>>>>>>>>>>>>>". Khi lặn tàu ngầm sẽ in tên động cơ và chuỗi kí tự là "&&&&&&&&&&&&&&"

1. Hãy xây dựng và mô phỏng phương tiện là tàu hỏa với động cơ và cách lái mặc định.

1. Hãy xây dựng phương tiện là xe Ferrari với động cơ là "F154" và cách lái của xe ô tô mặc định.

1. Hãy xây dựng một loại siêu phương tiện kết hợp ô tô, máy bay và tàu ngầm sao cho khi chạy trên đường thì sẽ sử dụng động cơ mặc định của xe ô tô, khi bay trên không sẽ sử dụng động cơ mặc định của máy bay, khi di chuyển dưới nước sẽ sử dụng động cơ mặc định của tàu ngầm. Khi thực hiện mô phỏng sẽ in ra tên động cơ là "hybrid" và sau đó lần lượt thực hiện các phương thức là di chuyển mặt đất, bay lên không trung rồi lặn xuống nước.

p/s: tôi đọc qua cái solution của bạn vẫn thấy dùng class cho class Visualizer customerType where, bạn dùng class thì chẳng phải đang dùng polymorphism, overloading của OOP đó sao?

• Lý do thứ nhất là hàm simulate của bạn phải nhận thêm biến môi trường mới có thể thực hiện được trong khi hàm simulate của Vehicle là hàm không có tham số. Do đó không thể coi hàm simulate này là hàm simulate của vehicle được.
• Lý do thứ hai là trong hàm simulate của siêu phương tiện lần lượt thực hiện ba phương thức là drive, pilot và dive chứ không phải là mỗi lần simulate mình thực hiện một chức năng.
• Lý do thứ ba mình là vì đây đơn giản không phải là tính đa hình, đây thực ra chỉ là một trick của bạn kết hợp kế thừa và bạn overloading bằng hàm cùng tên nên trông cảm giác bạn implement có vẻ giống đa hình thật. Nếu bạn cho các phương tiện giao thông vào List<Vehicle> sẽ thấy kết quả ra khác ngay.

interface IVehicle {
  String getEngine();
  void simulation();
}

interface ICar {
  String getEgine();
  void drive();
  void simulate();
}

interface IAircraft {
  String getEgine();
  void pilot();
  void simulate();
}

interface ISubmarine {
  String getEgine();
  void dive();
  void simulate();
}

public class Program {
  static void simulateVehicle(IVehicle vehicle) {
    vehicle.simulation();
  }

  static void simulateCar(ICar car) {
    car.simulate();
  }

  static void simulateSubmarine(ISubmarine submarine) {
    submarine.simulate(); 
  }

  static void simulateAircraft(IAircraft aircraft) {
    aircraft.simulate();
  }

  public static void Main() {
    IVehicle superVehicle = new Vehicle() {} as IVehicle;
  
    Console.WriteLine("\n1");
    Program.simulateVehicle(superVehicle);
  
    Console.WriteLine("\n2");
    Program.simulateAircraft(superVehicle as IAircraft);
  
    Console.WriteLine("\n3");
    Program.simulateCar(superVehicle as ICar);
  
    Console.WriteLine("\n4");
    Program.simulateSubmarine(superVehicle as ISubmarine);
  }
}

ngkhoahoang said:

Nếu như OOP không support, bạn có thể tùy ý thay đổi cách thể hiện sao cho phù hợp nhất. Làm sao kết quả thể hiện được như ảnh bên dưới thì kết quả của bạn sẽ được coi là acceptted.

ngkhoahoang said:

• Lý do thứ nhất là hàm simulate của bạn phải nhận thêm biến môi trường mới có thể thực hiện được trong khi hàm simulate của Vehicle là hàm không có tham số. Do đó không thể coi hàm simulate này là hàm simulate của vehicle được.
• Lý do thứ hai là trong hàm simulate của siêu phương tiện lần lượt thực hiện ba phương thức là drive, pilot và dive chứ không phải là mỗi lần simulate mình thực hiện một chức năng.
• Lý do thứ ba mình là vì đây đơn giản không phải là tính đa hình, đây thực ra chỉ là một trick của bạn kết hợp kế thừa và bạn overloading bằng hàm cùng tên nên trông cảm giác bạn implement có vẻ giống đa hình thật. Nếu bạn cho các phương tiện giao thông vào List<Vehicle> sẽ thấy kết quả ra khác ngay.

ngkhoahoang said:

Vehicle superVehicle = new Vehicle() {} as IVehicle;

Với có một điểm mình thắc mắc là các bạn OOP thường blame là các bạn FP sử dụng enum để enum kiểu dữ liệu sau không extend được, trong khi trong code của mình không có bất cứ đoạn nào sử dụng kiểu dữ liệu enum cả. Trong khi đó để giải bài toán của mình bạn lại enum ba loại phương tiện là "car", "aircraft" và "submarine" theo ba môi trường để gọi. Ví dụ sau này nhỡ có thêm một loại phương tiện mới là phi thuyền bay vào vũ trụ thì không biết bạn sẽ extend nó như thế nào.

tornado said:

Cuối cùng thì FP ưu việt hơn chỗ nào vậy các bác?

quandaso said:

Theo ý ông ý bắt bẻ đây vẫn là enum nhá

ớ ông ko nhìn ảnh tôi chụp à. Hay chạy thử đi nhé. Hàm super.simulate của tôi ra 4 kết quả y hệt ông. Và ko có enum nhé. Tôi cũng muốn xem ở FP của ông xem như nào

ngkhoahoang said:

Sai rồi nhé, của ông là gọi simulate với 4 phương tiện khác nhau, của tôi là gọi simulate với cùng một phương tiện làq

ngkhoahoang said:

C#:

interface IVehicle {
  String getEngine();
  void simulation();
}

interface ICar {
  String getEgine();
  void drive();
  void simulate();
}

interface IAircraft {
  String getEgine();
  void pilot();
  void simulate();
}

interface ISubmarine {
  String getEgine();
  void dive();
  void simulate();
}

public class Program {
  static void simulateVehicle(IVehicle vehicle) {
    vehicle.simulation();
  }

  static void simulateCar(ICar car) {
    car.simulate();
  }

  static void simulateSubmarine(ISubmarine submarine) {
    submarine.simulate();
  }

  static void simulateAircraft(IAircraft aircraft) {
    aircraft.simulate();
  }

  public static void Main() {
    IVehicle superVehicle = new Vehicle() {} as IVehicle;
 
    Console.WriteLine("\n1");
    Program.simulateVehicle(superVehicle);
 
    Console.WriteLine("\n2");
    Program.simulateAircraft(superVehicle as IAircraft);
 
    Console.WriteLine("\n3");
    Program.simulateCar(superVehicle as ICar);
 
    Console.WriteLine("\n4");
    Program.simulateSubmarine(superVehicle as ISubmarine);
  }
}

quandaso said:

Vãi đãi nhỉ, ông bảo tôi implement = OOP mà? Đương nhiên làm = oop nó phải khởi tạo 4 object khác khác nhau và call simulate. Cái của ông đâu phải khởi tạo đâu mà đang gọi static truyền reference vào method simulate. Thế cũng tính là OOP à?
Nếu cái ảnh ông chụp ông code =OOP thì tôi đang nghi ngờ là ông chả hiểu con mẹ gì về OOP cả nên tranh luận cũng vô nghĩa.( Còn nếu cái ảnh đó dùng FP thì thôi)
Thắc mắc nữa
Đây là đề bài của ông:
View attachment 233642
Đây là cái ảnh ông post:
View attachment 233640
Hàm simulate theo đề bài không có tham số, thế ông truyền cái hybrid là sai cmnr

ngkhoahoang said:

Ừm đúng, tôi dùng FP. :3
Cơ mà nếu ông thắc mắc ông có thể tham khảo code của @cugiametruyen85 trong giờ giải lao trước khi có lời giải thích đáng :3

ngkhoahoang said:

C#:

interface IVehicle {
  String getEngine();
  void simulation();
}

interface ICar {
  String getEgine();
  void drive();
  void simulate();
}

interface IAircraft {
  String getEgine();
  void pilot();
  void simulate();
}

interface ISubmarine {
  String getEgine();
  void dive();
  void simulate();
}

public class Program {
  static void simulateVehicle(IVehicle vehicle) {
    vehicle.simulation();
  }

  static void simulateCar(ICar car) {
    car.simulate();
  }

  static void simulateSubmarine(ISubmarine submarine) {
    submarine.simulate();
  }

  static void simulateAircraft(IAircraft aircraft) {
    aircraft.simulate();
  }

  public static void Main() {
    IVehicle superVehicle = new Vehicle() {} as IVehicle;

    Console.WriteLine("\n1");
    Program.simulateVehicle(superVehicle);

    Console.WriteLine("\n2");
    Program.simulateAircraft(superVehicle as IAircraft);

    Console.WriteLine("\n3");
    Program.simulateCar(superVehicle as ICar);

    Console.WriteLine("\n4");
    Program.simulateSubmarine(superVehicle as ISubmarine);
  }
}

Với yêu cầu là phương tiện giao thông sẽ không có thông tin của môi trường xung quanh (Giả sử khi mô phỏng chương trình chạy multi-thread, phương tiện có thể vừa chạy vừa bay và vừa lặn một lúc không phụ thuộc vào môi trường)

Nếu như OOP không support, bạn có thể tùy ý thay đổi cách thể hiện sao cho phù hợp nhất. Làm sao kết quả thể hiện được như ảnh bên dưới thì kết quả của bạn sẽ được coi là acceptted.

interface ICar {

  String getEgine();

  void drive();

  void simulate();

}



interface IAircraft {

  String getEgine();

  void pilot();

  void simulate();

}



interface ISubmarine {

  String getEgine();

  void dive();

  void simulate();

}

interface IEngineable
{
    String GetEngine();
    void Simulate();
}

interface IEngineable
{
    String GetEngineName();
    void Simulate(); //still not clear enough what it does
}
interface IDriveable
{
    void Drive();
}
interface IPilotable
{
    void Pilot();
}
interface IDiveable
{
    void Dive();
}
interface ICar : IEngineable, IDriveable
interface IAircraft : IEngineable, IPilotable
...

cugiametruyen85 said:

Nhìn vào code mình có 1 số vấn đề:
1 class trong oop nhìn vào là biết ngay:

• Nó chứa những gì (data)
• Nó có thể làm được những gì. (behavior)

Còn code của thím chia tách nó ra làm 3 phần rời rạc:

• data (struct)
• behavior (trait)
• data - behavior association (impl)

Vậy 1 số vấn đề đặt ra như sau:

• Compiler có đảm bảo cái mớ association phủ hết không (ví dụ trong trường hợp tôi không cung cấp impl thì compiler có báo lỗi không.
• Cohesion: 3 phần ở mỗi nơi như thế, tôi nhìn vào customer không biết nó thể làm được gì. Nhìn vào 2 loại customer khác nhau không biết nó share những trait gì.
  Ví dụ trong Java tôi có 2 class A và B, tôi chỉ cần nhìn nó impl những interface nào là biết nó share những behaviour nào ngay. Nói đơn giản trong Java data + behavior là 1 mớ đi liền. Điều này làm giảm cognitive overhead thấy rõ, nhìn vào 1 class tôi biết nó chứa gì trong đó và tôi có thể làm được gì với mớ data đó.
• Compile time: Việc không khai báo explicit chắc chắn sẽ làm tăng compile time. Vì 3 cái mớ đó là riêng biệt hoàn toàn, giả sử tôi gọi customer.print_info(), compiler phải xác định impl của thằng customer nào match với trait nào. Trong khi anh Java compiler nó biết ngay class này impl interface nào, việc xác định là vô cùng dễ.

hikaruu said:

Sao lúc tạo anh biết anh phải tạo loại khách hàng nào

Thích Màu Hường said:

Đề Bài (phần 1):
https://voz.vn/t/oop-hay-fp.137397/page-10#post-4525643

Đề Bài (phần 2):

Giả sử phần custom print (business logic để custom cái step 2 cho hàm Print) đã được làm và chạy ổn định, việc sửa code trong module này cực kỳ nguy hiểm, đòi hỏi nhiều chi phí để test lại. Trong đề bài phần này xem như không được thay đổi. Như vậy hiện tại có 2 modules fixed là Visualizer (phần core) và CustomerInfoManager (chứa loại khách hàng và custom print).

Với điều kiện trên Implement thêm 2 yêu cầu sau:
4. Đối với khách hàng có Age <= 30, lúc in Name không được in tên thật mà phải mask thành các dấu "******".

5. Cần ghi log trước và sau khi gọi custom print cho từng khách hàng. Format như sau, xem phần output cho rõ:
[Log]: Begin CustomPrint for customer name = <Name>
// In phần custom như lúc đợt 1
[Log]: End CustomPrint for customer name = <Name>

OOP Implementation
Module 3: CrossCuttingConcerns.dll : module mới chứa các logic cho yêu cầu mới 4 và 5

C#:

using CustomerInfoManager;

namespace CrossCuttingConcerns
{
    public class CustomerWrapper : Customer
    {
        protected Customer customer;

        public CustomerWrapper(Customer customer)
        {
            this.customer = customer;
            this.Name = customer.Name;
            this.Age = customer.Age;
        }
    }

    public class CustomerMasker : CustomerWrapper
    {
        public CustomerMasker(Customer customer) : base(customer) { }

        public override void CustomPrint()
        {
            // Mask if Age <= 30
            if (this.customer.Age <= 30)
            {
                this.customer.Name = "******";
            }

            // CustomPrint with masked data
            this.customer.CustomPrint();

            // Unmask
            this.customer.Name = this.Name;
        }
    }

    public class CustomerLogger : CustomerWrapper
    {
        public CustomerLogger(Customer customer) : base(customer) { }

        public override void CustomPrint()
        {
            System.Console.WriteLine(string.Format($"[Log]: Begin CustomPrint for customer name = {this.customer.Name}"));
            this.customer.CustomPrint();
            System.Console.WriteLine(string.Format($"[Log]: End CustomPrint for customer name = {this.customer.Name}"));
        }
    }
}

Program: CustomerManagement.exe: Module Program, add thêm các logic mới trước khi bỏ vào hàm Print cho máy chạy:

C#:

using CrossCuttingConcerns;
using CustomerInfoManager;
using System.Collections.Generic;

namespace CustomerManagement
{
    class Program
    {
        static void Main(string[] args)
        {
            IList<CustomerInfoManager.Customer> customers = CustomerRepo.GetCustomers();

            Visualizer.Visualizer visualizer = new Visualizer.Visualizer();
            foreach (CustomerInfoManager.Customer customer in customers)
            {
                // Add masker
                CustomerMasker customerMasker = new CustomerMasker(customer);

                // Add logger
                CustomerLogger customerLogger = new CustomerLogger(customerMasker);

                visualizer.Print(customerLogger);
            }
        }
    }
}

Output:

Code:

#######################################################
[Log]: Begin CustomPrint for customer name = John Smith
Name = ******
Age = 20
$$$$$$$$$$$$$$$$$$$$$$$
[Log]: End CustomPrint for customer name = John Smith

#######################################################
[Log]: Begin CustomPrint for customer name = Tim Batte
Name = ******
Age = 30
VipPoints = 100
@@@@@@@@@@@@@@@@@@@@@@@
[Log]: End CustomPrint for customer name = Tim Batte

#######################################################
[Log]: Begin CustomPrint for customer name = Jenny Lars
Name = Jenny Lars
Age = 40
Department = IT
&&&&&&&&&&&&&&&&&&&&&&&
[Log]: End CustomPrint for customer name = Jenny Lars

P/s: mình đã rename cái CustomerVisualzer thành Visualizer bên code ở phần 1 để dễ so sánh cái này không làm thay đổi bản chất của đề bài.

hikaruu said:

bài toán phải có input chứ phải có list data khách hàng dưới dạng json , rồi làm gì thì làm chứ , ra đề cũng thiếu

Thích Màu Hường said:

Lúc mới tranh luận tôi tưởng là các anh expert kinh nghiệm dày dặn đã kinh qua nhiều dự án làm OOP rồi thấy được cái dở của nó mới đâm ra rồ FP.

Nhưng giờ thấy các a hỏi vài câu ngô nghê thì mới biết là các a tư duy rất cụ thể, cục bộ. Tôi dám chắc anh còn ko hiểu tôi với 2 bạn làm FP kia đang tranh luận cái gì đâu.

P/s: à còn đòi data dạng json nữa chứ. Cái đề bài của tôi là về phân tích thiết kế giữa 2 trường phái OOP vs FP chứ ko phải ngôn ngữ hay framework, platform cụ thể nào.

hikaruu said:

Vậy đề sai rồi bài toán phải có input output chứ, ko có data từ db hoặc các nguồn khác thì bói thông tin từ trong không khí à , tư duy cho gì biết đó dính với cái với oop cả đời là hợp lý rồi , sai đề nên làm lài đi

hikaruu said:

Vậy đề sai rồi bài toán phải có input output chứ, ko có data từ db hoặc các nguồn khác thì bói thông tin từ trong không khí à , tư duy cho gì biết đó dính với cái với oop cả đời là hợp lý rồi , sai đề nên làm lài đi

hikaruu said:

chỉ cần ra kết quả, đầu vào của ai thì người đó tự thêm,data hình dáng thế nào conver qua object thì không có phần quan trọng nhất thì bỏ qua, tôi nghĩ các anh dc thẩy sẵn data nên quen luôn rồi. thêm input data di, dưới dạng text hoặc json , tôi còn vô code nào. Đi giải bài mà tự thêm đầu vào nó kì lắm

var customer = { Name: "John Smith", Age: 20 };
var vipCcustomer = { Name: "Tim Batte", Age: 30, VipPoints: 100 };
var internalCustomer = { Name: "Jenny Lars", Age: 40, Department: "IT" };

hikaruu said:

chỉ cần ra kết quả, đầu vào của ai thì người đó tự thêm,data hình dáng thế nào conver qua object thì không có phần quan trọng nhất thì bỏ qua, tôi nghĩ các anh dc thẩy sẵn data nên quen luôn rồi. thêm input data di, dưới dạng text hoặc json , tôi còn vô code nào. Đi giải bài mà tự thêm đầu vào nó kì lắm

Thích Màu Hường said:

Haizzz, tôi có đưa rồi, mô tả data trong đề bài phần 1 bằng text, data cụ thể cũng đã show trong code hàm GetCustomers và phần ouput rồi. Tôi thấy a có vấn đề về đọc hiểu đấy, giờ tôi show lại nè:

Có 3 loại khách hàng với tên và các fields tương ứng như sau: Customer (Name, Age), VipCustomer (Name, Age, VipPoints), InternalCustomer (Name, Age, Department). Bên dưới là data json cụ thể để ra ouput:

JSON:

var customer = { Name: "John Smith", Age: 20 };
var vipCcustomer = { Name: "Tim Batte", Age: 30, VipPoints: 100 };
var internalCustomer = { Name: "Jenny Lars", Age: 40, Department: "IT" };

Thoả mãn chưa

trgiangvp3 said:

Anh này lì thế nhỉ. Đúng tư duy thợ code, chỉ biết làm theo thiết kế có sẵn.
Giờ anh có thằng khách trả tiền để anh thiết kế hệ thống cho nó thì nó cũng chỉ mô tả theo hướng nghiệp vụ về input và output nó mong muốn, có cứt nó cho anh "file json data input" nhé, vì thằng khách hàng có khi nó đếch biết gì về code cả.
Nếu anh thấy chưa rõ thì anh cũng chỉ có thể hỏi theo hướng nghiệp vụ chứ ko thể đòi "file json data input" được.

hikaruu said:

rồi anh tao object customer từ đó, rồi in ra tôi xem nào =]]

Thích Màu Hường said:

Anh cố tình thả bait để gây war hay ngu thật? Tôi hy vọng là cái thứ nhất. Lượn giùm cái.

hikaruu said:

vậy thì đơn giản quá rồi nó code trước dùng gì thì cứ theo đó làm đi , đang oop code thêm theo fp làm gì =]], tất nhiên cũng dc thôi nhưng mà rất dở hơi

cugiametruyen85 said:

Mà kể cũng lạ, so sánh FP mà toàn đem typeclass rồi mớ HM type system của haskell ra. Vậy ra FP = Haskell à, mấy FP khác không có typeclass thì không phải là FP hả

Mình tưởng FP thì phải nói tới immutability, first class function, adt, monad các kiểu chứ

tthixk said:

Lời giải dùng only function ở đây nhưng có vẻ ko ai để ý
https://voz.vn/t/oop-hay-fp.137397/post-4538671

đến đoạn sau tranh luận gì mà toàn so tính năng coi ngôn ngữ nào hỗ trợ đc cái lọ cái chai, chán chả buồn nói.

hikaruu said:

vậy thì đơn giản quá rồi nó code trước dùng gì thì cứ theo đó làm đi , đang oop code thêm theo fp làm gì =]], tất nhiên cũng dc thôi nhưng mà rất dở hơi

tthixk said:

Lời giải dùng only function ở đây nhưng có vẻ ko ai để ý
https://voz.vn/t/oop-hay-fp.137397/post-4538671

đến đoạn sau tranh luận gì mà toàn so tính năng coi ngôn ngữ nào hỗ trợ đc cái lọ cái chai, chán chả buồn nói.

1. Output không giống: cái này a update lại giùm vì để dễ so sánh 2 trường phái với các ngôn ngữ khác nhau, ít nhất output, format, structure phải giống. Cái này a xem lại mấy post trước của tôi. (đặc biệt là hàm Print step 1, step 2...).
2. Phải phân tách module ra file riêng cho người ta thấy rõ luôn. Tôi nhìn vào, anh nhìn vào thì biết phần nào chung phần nào riêng, cái nào fixed, cái nào reuse chứ ng khác ko biết.

soihoang said:

self.customized_print(); có tính là functional ko bác :v

f# cũng tương tự nè, mình code trong lúc đợi ... build dự án nên code để máy công ty rồi
post tạm cái hình. Làm như cách của c# interface kiểu customer.printOtherInfo cũng được nhưng mình ... ko thích làm, làm demo cho mọi người coi thôi. Ai tò mò muốn biết fp thế nào thì cứ lập thread hỏi, mình biết gì thì hỗ trợ náy chứ cũng ko máu hơn thua, vì làm cho tới nơi thì mất công mà mình lại lười.

chổ cái Test mình viết thêm cho mọi người thấy là ko cần thêm type Test = ...., mấy cái khác là viết cho ai ko quen với du(discriminated unions)

cugiametruyen85 said:

Mình tưởng FP thì phải nói tới immutability, first class function, adt, monad các kiểu chứ

tandatcr2000 said:

Chỗ này em hỏi chỗ này hàm print thay vì dùng một match (tương tự switch .. case), ta có thể dùng function pointer (hay delegate, lambda expression, em không biết F# gọi là gì) để lưu trữ hàm print tương ứng không. Làm như vậy có vi phạm nguyên lý gì của FP không.
Với bác có thể cho em xin link tài liệu của ảnh dưới để tham khảo thêm không?

soihoang said:

có phải ý bạn muốn nói là "inject" hàm printOtherInfo vào parameter của hàm print phải ko ?. Nếu đúng thì đó là "dependency injection" trong fp, còn nó có phá vỡ nguyên lý hay ko thì mình ... vẫn tìm hiểu, về nguyên tắt là ko kiểm soát được. Dùng những thằng strict thì nó sẽ phải kĩ hơn(bằng type signature để biết được nó có tạo side effect hay ko

type Customer = {Name: String; Age: int; PrintBehaviour: delegate}

soihoang said:

Còn đoạn kia mình trích trong cuốn này.
Real-World Functional Programming

soihoang said:

Lan mam một chuyện cũng tình cờ là người đưa generic vào C#(2.0) là Don Syme, creator của F#.

hikaruu said:

https://repl.it/repls/FairWarmObjectcode#index.js
code đây ,mấy bác Vô trang trên mà code cho mọi người run share dc với

tandatcr2000 said:

Code:

type Customer = {Name: String; Age: int; PrintBehaviour: delegate}

Cái này sẽ khá tương tự OOP khi nhét hàm vào trong kiểu dữ liệu (vào object) và tính đa hình (polymorphism, cái này là vấn đề bắt buộc của mọi paramdigm, không riêng gì OOP hay FP) sẽ giống virtual function của OOP (virtual table là "backend" của virtual function và virtual class).

hikaruu said:

https://repl.it/repls/FairWarmObjectcode#index.js
code đây ,mấy bác Vô trang trên mà code cho mọi người run share dc với

1. Output không giống
2. Không tách module ko thấy được phần nào chung, riêng.
3. Logic hàm Print đang hard code, không reuse được và đang tight couple với customer type. Tôi muốn dùng hàm Print in thông tin Vozer, in hóa đơn, in employee, in cái mịe gì khác thì tôi bó tay do anh đang hard code.

Nipin said:

cũng may là mấy thằng python ruby lên ngôi với performance còn kém hơn chục lần FP languages mà vẫn ổn nên giờ mới bớt định kiến đi, chứ nếu không thì còn mướt...

cugiametruyen85 said:

Sao ko thấy ai nhắc đến AOP nhỉ. Giả sử mình có 1 cái lib giao tiếp với server.
Giả sử lib này có chừng 1000 cái function khác nhau để client sử dụng. Mình cần thay đổi token sau một khoảng thời gian khi client dùng ( chỉ cần check lúc thực thi lúc client gọi hàm là đc). Naive solution là nhét 1000 cái check vào đầu mỗi hàm.
Vậy với oop và fp thì giải quyết bài này như nào

Thích Màu Hường said:

Customer chỉ nên là raw model thôi.

lam vung lau lam said:

anemic model hả anh?

ngkhoahoang said:

Vì Haskell là PureFP, để tránh việc mình code Groovy xong bạn lại bảo Groovy là OOP

Thích Màu Hường said:

Đúng vậy và tôi biết anh định nhảy vào định nói cái này anti-pattern. Cái này theo quan điểm của tôi là không nhé.

Thích Màu Hường said:

Đề Bài (phần 1):
https://voz.vn/t/oop-hay-fp.137397/page-10#post-4525643

Đề Bài (phần 2):

Giả sử phần custom print (business logic để custom cái step 2 cho hàm Print) đã được làm và chạy ổn định, việc sửa code trong module này cực kỳ nguy hiểm, đòi hỏi nhiều chi phí để test lại. Trong đề bài phần này xem như không được thay đổi. Như vậy hiện tại có 2 modules fixed là Visualizer (phần core) và CustomerInfoManager (chứa loại khách hàng và custom print).

Với điều kiện trên Implement thêm 2 yêu cầu sau:
4. Đối với khách hàng có Age <= 30, lúc in Name không được in tên thật mà phải mask thành các dấu "******".

5. Cần ghi log trước và sau khi gọi custom print cho từng khách hàng. Format như sau, xem phần output cho rõ:
[Log]: Begin CustomPrint for customer name = <Name>
// In phần custom như lúc đợt 1
[Log]: End CustomPrint for customer name = <Name>

OOP Implementation
Module 3: CrossCuttingConcerns.dll : module mới chứa các logic cho yêu cầu mới 4 và 5

C#:

using CustomerInfoManager;

namespace CrossCuttingConcerns
{
    public class CustomerWrapper : Customer
    {
        protected Customer customer;

        public CustomerWrapper(Customer customer)
        {
            this.customer = customer;
            this.Name = customer.Name;
            this.Age = customer.Age;
        }
    }

    public class CustomerMasker : CustomerWrapper
    {
        public CustomerMasker(Customer customer) : base(customer) { }

        public override void CustomPrint()
        {
            // Mask if Age <= 30
            if (this.customer.Age <= 30)
            {
                this.customer.Name = "******";
            }

            // CustomPrint with masked data
            this.customer.CustomPrint();

            // Unmask
            this.customer.Name = this.Name;
        }
    }

    public class CustomerLogger : CustomerWrapper
    {
        public CustomerLogger(Customer customer) : base(customer) { }

        public override void CustomPrint()
        {
            System.Console.WriteLine(string.Format($"[Log]: Begin CustomPrint for customer name = {this.customer.Name}"));
            this.customer.CustomPrint();
            System.Console.WriteLine(string.Format($"[Log]: End CustomPrint for customer name = {this.customer.Name}"));
        }
    }
}

Program: CustomerManagement.exe: Module Program, add thêm các logic mới trước khi bỏ vào hàm Print cho máy chạy:

C#:

using CrossCuttingConcerns;
using CustomerInfoManager;
using System.Collections.Generic;

namespace CustomerManagement
{
    class Program
    {
        static void Main(string[] args)
        {
            IList<CustomerInfoManager.Customer> customers = CustomerRepo.GetCustomers();

            Visualizer.Visualizer visualizer = new Visualizer.Visualizer();
            foreach (CustomerInfoManager.Customer customer in customers)
            {
                // Add masker
                CustomerMasker customerMasker = new CustomerMasker(customer);

                // Add logger
                CustomerLogger customerLogger = new CustomerLogger(customerMasker);

                visualizer.Print(customerLogger);
            }
        }
    }
}

Output:

Code:

#######################################################
[Log]: Begin CustomPrint for customer name = John Smith
Name = ******
Age = 20
$$$$$$$$$$$$$$$$$$$$$$$
[Log]: End CustomPrint for customer name = John Smith

#######################################################
[Log]: Begin CustomPrint for customer name = Tim Batte
Name = ******
Age = 30
VipPoints = 100
@@@@@@@@@@@@@@@@@@@@@@@
[Log]: End CustomPrint for customer name = Tim Batte

#######################################################
[Log]: Begin CustomPrint for customer name = Jenny Lars
Name = Jenny Lars
Age = 40
Department = IT
&&&&&&&&&&&&&&&&&&&&&&&
[Log]: End CustomPrint for customer name = Jenny Lars

P/s: mình đã rename cái CustomerVisualzer thành Visualizer bên code ở phần 1 để dễ so sánh cái này không làm thay đổi bản chất của đề bài.

ngkhoahoang said:

Ok vậy đề bài tiếp theo của mình như sau. Vẫn tiếp tục từ đề bài 2 của bạn Thích Màu Hường.

Sau khi hệ thống được xây dựng, số lượng người truy cập tăng. Để giúp tăng hiệu quả hệ thống tận dụng tối đa phần cứng và cho phép nhiều người truy cập đồng thời cùng một lúc, người ta phát triển hệ thống cho phép xử lý đa luồng multithreading.
Hãy lập trình bài toán trên hỗ trợ truy cập multithreading bằng cách tạo ra 50 thread hoặc hơn. Các thread thực hiện công việc tương tự nhau là in tra thông tin của 3 customer khởi tạo lúc ban đầu. Biết việc in ra thông tin có thể thực hiện song song.

Đây là lời giải của mình: https://github.com/clitetailor/functional-challenges/pull/2/files

quandaso said:

Hơi lạc đề rồi ông bạn, multiple thread khá ko liên quan đến topic. Vì FP điểm yếu chính là tốn memory, giờ ko phải 50 thread. Mà là 100k, hay 500k thread cùng với 1 mức phần cứng cố định thì FP thua chắc chắn vì out of memory.
Chỉ nên tranh luận về feature của FP và OOP. Thực sự tôi thấy tất cả code cả bên FP lẫn OOP đều không phải pure mà thiên về language feature hơn.

trgiangvp3 said:

Code của Thích màu hường tôi thấy là sử dụng design pattern và các tính chất của OOP chứ đâu có dùng feature gì đặc biệt chỉ có ở C# đâu.
Code bên FP thì tôi hiểu biết nông cạn ko dám phán.

quandaso said:

Hơi lạc đề rồi ông bạn, multiple thread khá ko liên quan đến topic. Vì FP điểm yếu chính là tốn memory, giờ ko phải 50 thread. Mà là 100k, hay 500k thread cùng với 1 mức phần cứng cố định thì FP thua chắc chắn vì out of memory.
Chỉ nên tranh luận về feature của FP và OOP. Thực sự tôi thấy tất cả code cả bên FP lẫn OOP đều không phải pure mà thiên về language feature hơn.

quandaso said:

Hơi lạc đề rồi ông bạn, multiple thread khá ko liên quan đến topic. Vì FP điểm yếu chính là tốn memory, giờ ko phải 50 thread. Mà là 100k, hay 500k thread cùng với 1 mức phần cứng cố định thì FP thua chắc chắn vì out of memory.
Chỉ nên tranh luận về feature của FP và OOP. Thực sự tôi thấy tất cả code cả bên FP lẫn OOP đều không phải pure mà thiên về language feature hơn.

Nipin said:

thời buổi này đíu ai dùng thread nữa mà sợ out of memory :/

cái vụ phoenix framework send 2 triệu messages cùng một lúc tôi tưởng là nổi tiếng lắm cơ mà nhỉ: https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections

Nipin said:

thời buổi này đíu ai dùng thread nữa mà sợ out of memory :/

cái vụ phoenix framework send 2 triệu messages cùng một lúc tôi tưởng là nổi tiếng lắm cơ mà nhỉ: https://www.phoenixframework.org/blog/the-road-to-2-million-websocket-connections

quandaso said:

Chính xác, giờ ngu gì design multiple thread đâu vì quá nguy hiểm. Cứ worker cho lành. Thế nên mang Multiple Thread để đọ giữa OOP và FP là quá là...không đúng. Vì Multiple Thread nó ở tầm cao khác rồi, ko dễ gì mà làm việc với multiple thread mà không dead lock

quandaso said:

Thì tôi có bảo nó không có đâu, nó có nhưng ông dev phải cực kì master mới làm chuẩn chỉ được.
Còn IPC có deadlock hay không tôi cũng chả rõ, vì thực tế chưa gặp bao giờ. (Tôi làm thực tế nhé không đọc trên wiki hay xyz gì đâu, server tôi dùng node worker handle khoảng 3,4k CCU, chạy 3 4 năm chưa bao giờ bị deadlock,)

Vì đề bài của ông bạn là không thể làm được. Nó đâu phải vấn đề với OOP?. Nó là bài toán hoàn toán khác của multiple thread nói chung. Bên FP có vẻ giải quyết bằng cách mỗi thread 1 object khác nhau chăng? (tôi cũng ko chắc) Nhưng như thế 50 thread là x50 lần memory lên à, hay như nào?

Thích Màu Hường said:

Ủa code C# của tôi toàn OOP chứ có language feature gì đâu. Muốn convert qua ngôn ngữ nào mà chả được.

Code bên FP đáng ra phải minh họa bằng bất kỳ ngôn ngữ nào cũng được luôn chứ ko phải Haskell hay Rust gì đấy vì đang bàn về pardigm mà. Thậm chí tôi dùng C# với 1 class toàn static method để minh họa về FP cũng được. Chổ nào language ko support thì cứ ghi chú ra. Như Higher Order Function thì gọi hàm lồng nhau, xài delegate, function pointer... rồi ghi chú là bên Rust, Haskell có support thì syntax ngắn được tí.

À còn cái vụ @ ngkhoahoang nói chuyện bên Haskell, Rust có ntellisense của racer với cargo docs, Hoogle gì gì đấy là tôi không chấp nhận vì anh đem language, IDE features ra nói. Chứ tôi code C# bằng notepad thì sao.

Dẫn nguồn các thằng ất ơ trên mạng nói rằng OOP đa số là novices còn FP là toàn pro, senior, lương cao là các anh tự cho mình thượng đẳng. Thực tế vài anh trên này ban đầu rồ FP sau khi show code hỏi lung tung thì thấy non kinh nghiệm rõ ràng chứ senior hay pro gì đâu mà chửi OOP.

P/s: cái bài threading là để làm sáng tỏ cái chuyện parallel processing, cái này các anh FP tự hào do có pure và immutable nên không bị chuyện truy xuất tài nguyên đồng thời. Mà như vậy cái đề đáng ra là phải cho modify cái field nào đó của Customer thì chính xac hơn là chỉ print info.

À mà nhắc lại là topic này đang bàn về pardigm, nguyên tắc là cả 2 cách code phải được implement ở bất kỳ ngôn ngữ nào cũng được nên đừng đem language feature ra nói chuyện!

ngkhoahoang said:

Bạn đừng trả lời với tuy duy lảng tránh nữa đi. Nếu thích mình có thể code bài trên có mutate state

ngkhoahoang said:

Vậy tôi thử cho bạn một bài về inter-process communication xem bạn có bị deadlock ko nhé :3

quandaso said:

OK, nhưng tôi ko thích chơi chay nữa. Chơi 50 củ VNĐ đi cho mát, bạn chơi thì lập topic nhé. Vì nó ko liên quan đến OOP nên tôi dùng mọi cách ko cho nó deadlock là được đúng không?

quandaso said:

OK, nhưng tôi ko thích chơi chay nữa. Chơi 50 củ VNĐ đi cho mát, bạn chơi thì lập topic nhé. Vì nó ko liên quan đến OOP nên tôi dùng mọi cách ko cho nó không deadlock là được đúng không?
p/s: Đương nhiên với điều kiện bạn ra bài phải có solution để giải quyết. Nếu ra đề bài vô lí, hoặc ko giải quyết được thì phạt 50 củ.

ngkhoahoang said:

Thôi lạy các cụ, tôi méo có tiền để các cụ khoe khoang đâu ạ

soihoang said:

lúc các bạn oop ra đề có ai bắt các bạn phải thế lọ thế chai ko, vì mình tự cho fp là chiếu dưới nên chiều các bạn ko bắt bẻ thôi. Giờ lấy cái lợi thế của fp ra thì chạy làng à

quandaso said:

Chính xác, giờ ngu gì design multiple thread đâu vì quá nguy hiểm. Cứ worker cho lành. Thế nên mang Multiple Thread để đọ giữa OOP và FP là quá là...không đúng. Vì Multiple Thread nó ở tầm cao khác rồi, ko dễ gì mà làm việc với multiple thread mà không dead lock

soihoang said:

mà thôi, topic này nó bị lái đi bởi 2 ông @naiveryan với @Thích Màu Hường . Nên mấy bác khác tạm thời nhường sân cho 2 bác này xử nhau. 2 bác ko xử nhau nữa thì nhường cho những người còn lại

• Phe thờ FP như bố, OOP là thứ rác rưởi (điển hình là anh naiveryan)
• Phe dung hoà: FP hay OOP sẽ phát huy tác dụng tuỳ trường hợp. Hay còn gọi là phe Right tool for right job

soihoang said:

mà thôi, topic này nó bị lái đi bởi 2 ông @naiveryan với @Thích Màu Hường . Nên mấy bác khác tạm thời nhường sân cho 2 bác này xử nhau. 2 bác ko xử nhau nữa thì nhường cho những người còn lại

prescolt said:

Xem ra các anh làm lập trình có nhiều bài toán cãi nhau quá, mấy thằng làm system chẳng có gì để cãi cho vui cả, bọn nó hay giấu nghề. network lại càng không nốt. Trước giờ ko viết OOP bao giờ, cũng ko biết OOP, toàn viết theo kiểu function, gọi qua gọi lại. Giờ mới biết nó được gắn cho tên gọi FP .

ngkhoahoang said:

Điểm khác nhau thứ nhất là name collision, tên các phương thức ở trong interface có thể bị name collision với nhau nhưng typeclass thì không. Một class không thể implement hai interface có cùng tên method nhưng lại khác nhau về input output, tuy nhiên typeclass có thể làm được điều này.

interface MyInterface{
   public void display();
}
interface MyInterface2{
   public void display(String name);
   public void display(String name, int age);
}

public class OverloadingInterfaces implements MyInterface, MyInterface2{
   String name;
   int age;
   public void display() {
      System.out.println("This is the implementation of the display method");
   }
   public void display(String name) {
      System.out.println("Name: "+name);
   }
   public void display(String name, int age) {
      System.out.println("Name: "+name);
      System.out.println("Age: "+age);
   }
   public static void main(String args[]) {
      OverloadingInterfaces obj = new OverloadingInterfaces();
      obj.display();
      obj.display("Foo");
      obj.display("Foo", 10);
   }
}

Ikeda said:

really??

Java:

interface MyInterface{
   public void display();
}
interface MyInterface2{
   public void display(String name);
   public void display(String name, int age);
}

public class OverloadingInterfaces implements MyInterface, MyInterface2{
   String name;
   int age;
   public void display() {
      System.out.println("This is the implementation of the display method");
   }
   public void display(String name) {
      System.out.println("Name: "+name);
   }
   public void display(String name, int age) {
      System.out.println("Name: "+name);
      System.out.println("Age: "+age);
   }
   public static void main(String args[]) {
      OverloadingInterfaces obj = new OverloadingInterfaces();
      obj.display();
      obj.display("Foo");
      obj.display("Foo", 10);
   }
}

kyo_pyro said:

Thế cùng param nhưng khác return type thì sao bro ?

Ikeda said:

really??
[/CODE]

cugiametruyen85 said:

Sao ko thấy ai nhắc đến AOP nhỉ. Giả sử mình có 1 cái lib giao tiếp với server.
Giả sử lib này có chừng 1000 cái function khác nhau để client sử dụng. Mình cần thay đổi token sau một khoảng thời gian khi client dùng ( chỉ cần check lúc thực thi lúc client gọi hàm là đc). Tất nhiên cái token sau khi đổi cũng cần phải lưu lại để reuse cho lần gọi sau.
Naive solution là nhét 1000 cái check vào đầu mỗi hàm rồi dùng 1 global variable để lưu token
Vậy với oop và fp thì giải quyết bài này như nào
Bài này khá tương tự với log, transaction, auth...

cugiametruyen85 said:

Thật ra tôi nghĩ ý anh ý là đang nói đến bài toán double dispatch này thôi (tất nhiên anh ta cũng sai bét vì double dispatch là liên quan đến feature của language, ko liên quan đến OOP)

View attachment 239340

trgiangvp3 said:

Anh này có kiểu post bài úp úp mở mở khịa khịa rất điếm thúi.
Nếu được thì xin anh nêu rõ luận điểm và lí luận như cái post dài dài đầu tiên của anh, như thế mới có cái để tiếp tục tranh luận. Chứ anh cứ kiểu "blah blah blah nhỉ nhỉ nhỉ" xong kèm thêm 1 cái emo để úp mở cái đéo gì đó tỏ vẻ nguy hiểm vkl. Mà bọn tôi đọc thì lại cứ phải đoán ý anh nhưng chả biết đúng không.
Đôi lời đến anh.

Ikeda said:

really??

Java:

interface MyInterface{
   public void display();
}
interface MyInterface2{
   public void display(String name);
   public void display(String name, int age);
}

public class OverloadingInterfaces implements MyInterface, MyInterface2{
   String name;
   int age;
   public void display() {
      System.out.println("This is the implementation of the display method");
   }
   public void display(String name) {
      System.out.println("Name: "+name);
   }
   public void display(String name, int age) {
      System.out.println("Name: "+name);
      System.out.println("Age: "+age);
   }
   public static void main(String args[]) {
      OverloadingInterfaces obj = new OverloadingInterfaces();
      obj.display();
      obj.display("Foo");
      obj.display("Foo", 10);
   }
}

ngkhoahoang said:

Ok vậy còn tại sao mình biết chỗ này lại có side-effect thì chắc các bạn làm FP cũng không khó để nhận ra. Mình gợi ý là nó cũng giống như việc tại sao trong OOP, thay vì người ta sử dụng biến global như trong Procedural người ta lại phải đóng gói thuộc tính vào trong Object. Do vậy nếu bạn sử dụng DI để share state giữa các Object thì sẽ phá vỡ ngay tính đóng gói của OOP và có khả năng tạo data race và đơn giản thôi, side-effect thì phải xử lý. Còn việc tìm ra side-effect như thế nào đến bài sau mình sẽ nói kĩ hơn về việc này.

ngkhoahoang said:

Ok giờ mình tạm thời coi như bài này bên OOP giải được vì kể cả bạn @cugiametruyen85 có giải được hay không thì mình cũng đã có 2 3 lời giải cho bài này rồi. Vậy ý nghĩa của bài này là gì. Bài này bắt nguồn từ việc mình nhìn thấy một đoạn trick của bạn @Thích Màu Hường như sau:

C#:

    public class CustomerMasker : CustomerWrapper
    {
        public CustomerMasker(Customer customer) : base(customer) { }

        public override void CustomPrint()
        {
            // Mask if Age <= 30
            if (this.customer.Age <= 30)
            {
                this.customer.Name = "******";
            }

            // CustomPrint with masked data
            this.customer.CustomPrint();

            // Unmask
            this.customer.Name = this.Name;
        }
    }

Đọc đoạn code này chắc FP developer nào cũng nhận ra ngay đoạn code này bị một vấn đề rất đơn giản thôi, data race. Mình cũng chưa thử đâu nhưng mình nhìn code cũng đoán được hòm hòm rằng khi chạy đoạn code này multithread sẽ gặp lỗi, nên vì thế khi ra đề mình đưa bừa một con số là 50 cho lớn lớn tí. Cơ mà không biết các bạn bên OOP có nhận ra điều gì không mà các bạn phản ứng rất gay gắt đoạn này mặc dù mình cho rằng đây là kiến thức rất căn bản thôi và trong OOP cũng chả thiếu gì cách để xử lý. Thực ra đây là pattern đơn giản thôi, check then act. Nếu bạn nào làm về DB thôi các bạn cũng hiểu nếu đoạn này làm cho DB ngân hàng thôi là transaction đoạn này phải rất kĩ nếu không sẽ mất tiền của khách hàng như chơi.

Các bạn làm về Go chắc biết đến go routine và go channel, khi code nó có tool là go race để check race condition đoạn này, nếu không sẽ lỗi side effect sấp mặt. Còn đối với những bạn code Haskell hay Rust, nếu đoạn này không xử lý thì compiler sẽ báo đỏ reject thẳng thừng ngay lập tức chứ đừng nói đến là code có compile hay không.

Nếu bạn dùng Python Flask chắc bạn cũng thắc mắc tại sao mình không khai báo và sử dụng biến global luôn mà phải khai báo thông qua một biến global g mà Flask cung cấp. Khi bạn dùng biến này, Flask sẽ xử lý việc bạn truy cập vào biến dùng chung này để tránh data race khi chạy multithread hay worker.

Kể cả đối với những bạn không biết về FP đi nữa thì một trong những khá là tối kị là đưa invalid state vào trong hệ thống vì khi chạy song song nhiều tiến trình hoặc khi chạy multithread, ở một thời điểm nào đó người dùng truy cập, hệ thống đang ở trong trạng thái invalid state thì ngay lập tức thôi cũng sẽ trả lại lỗi cho người dùng. Vì vậy nên nếu chỗ này chạy có lỗi thì khi đọc log bạn sẽ biết ngay là tên khách hàng có thể bị đổi thành ****** hoặc khi người dùng đọc dữ liệu từ trang web sẽ bị hiển thị thông tin đáng ra bị mask.

Thực ra đoạn này khi mình ra đề là đã không cân sức vì hệ thống của mình chỉ có đọc dữ liệu không có mutate gì còn hệ thống của bạn ý là đã có mutate dữ liệu sẵn có rồi. Đương nhiên bài 2 của bạn chỉ là về tính đa hình trong OOP, bài này có thể xử lý đơn giản thông qua tính đa hình chứ không nhất thiết phải mutate dữ liệu giống như bạn @Thích Màu Hường đã làm. Bạn @cugiametruyen85 chắc cũng gần tìm ra cách giải tuy nhiên rất tiếc output của bạn ra cho bài 2 lại bị sai mất. Tuy nhiên, kể cả khi mutate dữ liệu thì cũng không thiếu cách để xử lý bài này. Đơn giản thôi là mình sử dụng Mutex, còn sử dụng thế nào thì cái này bạn có thể tự tra, mình sẽ không giải đáp.

Ok vậy còn tại sao mình biết chỗ này lại có side-effect thì chắc các bạn làm FP cũng không khó để nhận ra. Mình gợi ý là nó cũng giống như việc tại sao trong OOP, thay vì người ta sử dụng biến global như trong Procedural người ta lại phải đóng gói thuộc tính vào trong Object. Do vậy nếu bạn sử dụng DI để share state giữa các Object thì sẽ phá vỡ ngay tính đóng gói của OOP và có khả năng tạo data race và đơn giản thôi, side-effect thì phải xử lý. Còn việc tìm ra side-effect như thế nào đến bài sau mình sẽ nói kĩ hơn về việc này.

cugiametruyen85 said:

Lại cái trò anchoring này

.
Thật tế thì oop không ai làm multithread kiểu thế mà người ta thường chia theo atomic task, hạn chế share state giữa các task (ví dụ in 10000 user chia đều cho 50 thread). Còn cái DI cũng không ai share state trong đó cả mà đa phần là inject services

Anh toàn vẽ ra những bài toán nontrivial rồi archor nó theo hướng favor fp. Nhất anh

Ikeda said:

wtf? trong trường hợp không biết return type thì làm sao để complier phân biệt được anh đang gọi hàm nào? dùng generic à? mà cái này thì liên quan gì đến OOP hay FP?

cugiametruyen85 said:

Nhìn vào code mình có 1 số vấn đề:
1 class trong oop nhìn vào là biết ngay:

• Nó chứa những gì (data)
• Nó có thể làm được những gì. (behavior)

Còn code của thím chia tách nó ra làm 3 phần rời rạc:

• data (struct)
• behavior (trait)
• data - behavior association (impl)

Vậy 1 số vấn đề đặt ra như sau:

• Compiler có đảm bảo cái mớ association phủ hết không (ví dụ trong trường hợp tôi không cung cấp impl thì compiler có báo lỗi không.
• Cohesion: 3 phần ở mỗi nơi như thế, tôi nhìn vào customer không biết nó thể làm được gì. Nhìn vào 2 loại customer khác nhau không biết nó share những trait gì.
  Ví dụ trong Java tôi có 2 class A và B, tôi chỉ cần nhìn nó impl những interface nào là biết nó share những behaviour nào ngay. Nói đơn giản trong Java data + behavior là 1 mớ đi liền. Điều này làm giảm cognitive overhead thấy rõ, nhìn vào 1 class tôi biết nó chứa gì trong đó và tôi có thể làm được gì với mớ data đó.
• Compile time: Việc không khai báo explicit chắc chắn sẽ làm tăng compile time. Vì 3 cái mớ đó là riêng biệt hoàn toàn, giả sử tôi gọi customer.print_info(), compiler phải xác định impl của thằng customer nào match với trait nào. Trong khi anh Java compiler nó biết ngay class này impl interface nào, việc xác định là vô cùng dễ.

kyo_pyro said:

Thì nó là vấn đề của interface đấy, khi mà 2 người định nghĩa 2 interface cùng input nhưng khác output thì chính là cái collision mà bro đang phản bác đó.

cugiametruyen85 said:

Lại cái trò anchoring này

.
Thật tế thì oop không ai làm multithread kiểu thế mà người ta thường chia theo atomic task, hạn chế share state giữa các task (ví dụ in 10000 user chia đều cho 50 thread). Còn cái DI cũng không ai share state trong đó cả mà đa phần là inject services

Anh toàn vẽ ra những bài toán nontrivial rồi archor nó theo hướng favor fp. Nhất anh

ngkhoahoang said:

1. Bạn sai nhé, ko có nghĩa inject service xong phát là bạn thoái thác hết trách nhiệm đâu. Khi bạn dùng chung service vẫn có thể dùng chung http client, dùng chung connection và nhiều thứ nữa. Bình thường các thư viện handle cho bạn hết nên bạn chả phải quan tâm đến vấn đề gì cả. Mình từng gặp trường hợp thư viện trong Go handle ko tốt nên panic cả service khiến service bị restart docker lại nhiều lần.
Bản thân object khi tạo request ra bên ngoài đã là side effect rồi.

zulu said:

Lạc đề rồi ba.
Cái này thì anh có code bằng cái qq thì cũng sẽ có thể dính thôi. Cái này thuộc về lỗi chủ quann của LTV , anh mang vô đây nói để lái topic hả?

ngkhoahoang said:

Thì có ông lập trình viên nào khi gặp lỗi lại bảo tôi cố ý đâu. Bản chất của việc xây dựng mô thức lập trình với dùng tool là để tránh nhiều nhất lỗi do con người gây ra mà bạn. Nếu ko OOP chả cần nghĩ ra tính đóng gói làm gì cho khổ. Còn nếu như chương trình mà code ra ko có lỗi hoàn toàn thì chắc anh em chả cần phải đi code nữa ý chứ.

Thích Màu Hường said:

Cái @ ngkhoahoang nói là tào lao luôn nhé, hiểu sai vấn đề rồi. Ngay cả cái code C# implement bài 2 như trên thì chuyện Parallel processing dể Print info cũng không có lỗi và nó vẫn đang là thread-safe.

Mà ông muốn chém về cái này lập topic riêng đi tôi chém với ông. Mà ko chém suông nhé, lập kèo 50 củ rồi tôi code cho ông in 1 triệu customer Parallel xem nó có lỗi không.

Tóm lại, TÀO LAO.

zulu said:

Chỗ đó rõ rang là non-thread safe mà. Thím có 1 customer masker và 2 thread liên tục gọi hàm CustomPrint sẽ xảy ra sai sốt thôi thím ơi.

Thích Màu Hường said:

Trường hợp anh nói là non-thread safe đúng! Nhưng nhìn lại cái code bài 2 và cái hàm Print info xem nó có phải trường hợp này không?

Xác định thế nào là thread safe hay không thì phải xác định cái scope của resource đang access ở đâu và các thread đang work trên resource đó ở đâu chứ.

zulu said:

Tôi hiêu ý anh. Ý anh là lúc xài các thread ko share chung 1 masker thì ko sao. Điều này đúng là như vậy, tôi đông ý. Rõ ràng vì nó ko thread safe nên kéo theo ==> ko đc xài như là shared data như ý anh nói.

Nhưng chung quy vẫn là non-thread safe mà thôi. Anh đừng đánh lận định nghĩa. Cá nhân tôi chỉ coi 1 method là Thread safe khi có nhiều hơn 2 threads xuất method đó trên cùng 1 instance mà vẫn đảm bảo tính đúng đắn.

1. Có shared resource ở ít nhất 2 threads.
2. Các thread này có cập nhật shared resource.

ngkhoahoang said:

Ok giờ mình tạm thời coi như bài này bên OOP giải được vì kể cả bạn @cugiametruyen85 có giải được hay không thì mình cũng đã có 2 3 lời giải cho bài này rồi. Vậy ý nghĩa của bài này là gì. Bài này bắt nguồn từ việc mình nhìn thấy một đoạn trick của bạn @Thích Màu Hường như sau:

C#:

    public class CustomerMasker : CustomerWrapper
    {
        public CustomerMasker(Customer customer) : base(customer) { }

        public override void CustomPrint()
        {
            // Mask if Age <= 30
            if (this.customer.Age <= 30)
            {
                this.customer.Name = "******";
            }

            // CustomPrint with masked data
            this.customer.CustomPrint();

            // Unmask
            this.customer.Name = this.Name;
        }
    }

Đọc đoạn code này chắc FP developer nào cũng nhận ra ngay đoạn code này bị một vấn đề rất đơn giản thôi, data race. Mình cũng chưa thử đâu nhưng mình nhìn code cũng đoán được hòm hòm rằng khi chạy đoạn code này multithread sẽ gặp lỗi, nên vì thế khi ra đề mình đưa bừa một con số là 50 cho lớn lớn tí. Cơ mà không biết các bạn bên OOP có nhận ra điều gì không mà các bạn phản ứng rất gay gắt đoạn này mặc dù mình cho rằng đây là kiến thức rất căn bản thôi và trong OOP cũng chả thiếu gì cách để xử lý. Thực ra đây là pattern đơn giản thôi, check then act. Nếu bạn nào làm về DB thôi các bạn cũng hiểu nếu đoạn này làm cho DB ngân hàng thôi là transaction đoạn này phải rất kĩ nếu không sẽ mất tiền của khách hàng như chơi.

... blabbers

qkhanhpro said:

Đoạn đầu OK. Đoạn sau bạn nói lan man quá. Và mình thấy topic này từ đoạn bạn hướng sang multi-threading nó đi hơi xa so với vấn đề ban đầu bạn Màu Hồng đang nói tới, là việc mô hình thế giới theo OOP, sống chung với Inheritance nếu làm tốt sẽ cho ra giải pháp elegant hơn các tiếp cận FP nhiều như bạn ấy đã phân tích ở 1 post ( mà không ai rep! ) - có lẽ phần đó sẽ để cho những người đọc tự đánh giá. Mình cũng đồng ý rằng có những bài toán khác nếu mô hình theo FP sẽ elegant hơn OOP, nhưng không liên quan đến câu chuyện multi-threading ở đây...

Ok trở lại bài toán OOP, khi thực hiện data mutation trên cùng tài nguyên có thể dùng lock/mutex. Nó đủ dễ hiểu, tuy không thật sự elegant

Về phía FP tôi được hiểu là khi gặp bài toán multi-threading như thế này, nhờ có pure function / không share resource nên mỗi thread sẽ capture state hiện tại và tạo ra bộ state mới. Câu chuyện ở đây là vào thời điểm kết thúc, chúng ta sẽ có [Số concurrent thread] state và chúng ta sẽ cần discard hoặc consolidate ở đâu đó. Trong bài toán trivial [New state-> Print -> discard] như bạn đưa ra thì nó rất đẹp. Vậy giả sử những state đó bạn tiếp tục đưa vào các pipeline ( hay là function ) tiếp theo khiến chúng ngày càng xa rời nhau thì sẽ như thế nào nhỉ... chắc là phải giữ các pilepine lại 1 điểm synchronization point?

Tôi cũng nghĩ rằng OOP hay FP đều sẽ gặp khó ( để diễn giải bài toán thành code một cách dễ hiểu ) với multi-threading thôi...

qkhanhpro said:

Vậy giả sử những state đó bạn tiếp tục đưa vào các pipeline ( hay là function ) tiếp theo khiến chúng ngày càng xa rời nhau thì sẽ như thế nào nhỉ... chắc là phải giữ các pilepine lại 1 điểm synchronization point?

Tôi cũng nghĩ rằng OOP hay FP đều sẽ gặp khó ( để diễn giải bài toán thành code một cách dễ hiểu ) với multi-threading thôi...

hoangducnhuan said:

Đồng ý là khi đi đến multithread thì nó quá xa rời câu chuyện ban đầu về khả năng mô hình bài toán thành ngôn ngữ lập trình rồi
Với ví dụ bạn Hường đưa ra thì OOP có lợi thế. Ở đầu kia hẳn là FP cũng có nhiều bài toán lợi thế khi mô hình bằng OOP sẽ tệ
Còn đã đem multithreading vào cộng thêm với các ông thần khách hàng cuối ( người đọc VoZ ) đòi tạo change request liên tục thì code gì cũng nát...
Cá nhân tôi thấy explicit multi-threading thời điểm hiện tại thường chỉ những người làm hệ thống performance critical / mathematical ... sử dụng nhiều? và 2 mảng đó cũng là đất thánh của FP rồi? Và FP đang muốn lấn sân sang mô hình bài toán business lớn / bài toán theo đầu óc tự nhiên của con người, nơi mà trước giờ là đất của OOP. Vậy thì nên quay lại với hướng tiếp cận của bạn Hường đi? Mô hình business với những yêu cầu tương đối khùng khùng, khả năng extend business theo những requirement trái ngoe và đôi khi chúng ta cũng cần những sự chắp và healthy trên 1 code base như đông cứt nữa?