thảo luận Cuối cùng thì áp dụng 4 tính chất OOP vào code base như thế nào nhỉ?

hokages said:

Overriding method từ đâu nhỉ.

Click to expand...

À cái này em từ abstract method ấy bác. Mà em mới coi vài chỗ. Thấy họ bảo như vầy nếu ví dụ chim ưng là chim và có thể bay, thì mình sẽ tạo class ChimUng kế thừa abstract class Chim và interface ICoTheBay. Nên cái trên mới dùng interface chứ không dùng override abstract method phải ko bác?

tính đóng gói chính là mấy cái private public các thứ đó bác

Nick để hóng said:

À cái này em từ abstract method ấy bác. Mà em mới coi vài chỗ. Thấy họ bảo như vầy nếu ví dụ chim ưng là chim và có thể bay, thì mình sẽ tạo class ChimUng kế thừa abstract class Chim và interface ICoTheBay. Nên cái trên mới dùng interface chứ không dùng override abstract method phải ko bác?

Click to expand...

Nếu dùng abstract thì ko extends dc nhiều class, interface mới dc.

Nick để hóng said:

À cái này em từ abstract method ấy bác. Mà em mới coi vài chỗ. Thấy họ bảo như vầy nếu ví dụ chim ưng là chim và có thể bay, thì mình sẽ tạo class ChimUng kế thừa abstract class Chim và interface ICoTheBay. Nên cái trên mới dùng interface chứ không dùng override abstract method phải ko bác?

Click to expand...

vầy nhé, abstract nó chỉ ra những phần chung nhất ví dụ về các con chim nhé. chim ưng có lông, chim cánh cụt cũng có lông -> phần chung nhất, còn về khả năng bay, con chim ưng nó bay đc còn con chim cánh cụt thì không -> lắp interface flyable vào cho con chim ưng còn cánh cụt ko bay đc nên khỏi lắp còn lông thì con nào cũng có -> override lại màu lông

Interface thường sẽ là để mô tả, chức năng của class. Còn abstract là lưu trữ các đặc tính chung của class đó

Tìm hiểu các design pattern đi là hiểu liền

NobiEmon said:

vầy nhé, abstract nó chỉ ra những phần chung nhất ví dụ về các con chim nhé. chim ưng có lông, chim cánh cụt cũng có lông -> phần chung nhất, còn về khả năng bay, con chim ưng nó bay đc còn con chim cánh cụt thì không -> lắp interface flyable vào cho con chim ưng còn cánh cụt ko bay đc nên khỏi lắp còn lông thì con nào cũng có -> override lại màu lông

Click to expand...

hokages said:

Interface thường sẽ là để mô tả, chức năng của class. Còn abstract là lưu trữ các đặc tính chung của class đó

Click to expand...

Thx các bác. Đã hiểu thêm đc 1 chút.

methanol197 said:

Tìm hiểu các design pattern đi là hiểu liền

Click to expand...

Cuốn head first design pattern đọc ổn không bác? Hay mới học design pattern thì nên học như thế nào vậy bác

Thực sự mà nói cách tiếp cận OOP cho người mới bắt đầu nhiều sách vở/tài liệu chỉ dẫn một cách phi thực tế nên là người mới cực kỳ mơ hồ về OOP. Tôi tìm hiểu các hướng dẫn về OOP thế éo nào toàn nói rất nhiều về 4 tính chất đi kèm với nó (Encapsulation, Inheritance, Polymorphism, Interface). Như thể không hiểu được 4 tính chất này thì éo làm được OOP ấy.

Theo tôi newbie OOP cứ chỉ cần hiểu OOP đơn giản là các lớp kế thừa lẫn nhau, 4 tính chất trên là các giải pháp khắc phục các nhược điểm của việc kế thừa. Mà thực tế là còn rất nhiều các tính chất khác nữa cần dùng để khắc phục các nhược điểm của kế thừa, thế nên tiếp cận OOP thì cứ hiểu duy nhất về tính chất kế thừa cái đã, khi kế thừa búa xua trong code, nó phát sinh ra vấn đề thì bắt đầu tìm hiểu các cách khắc phục vấn đề thì tự hiểu thôi. Có cả mấy chục tính chất chứ đâu chỉ 4 tính chất base kia đâu mà.

Như mấy thím trên cũng có nói, khái niệm quan trọng nhất của OOP là state. Hầu như(ko phải tất cả) những tính chất trên giúp quản lý state chặt chẽ, rõ ràng, ít bị issue... Do nó chặt chẽ hơn nên cũng gây khó chịu hơn so với fg.

Mấy thím nói private properties là ko có tác dụng gì, xài public đi cho dễ. Cái đó vi phạm nghiêm trọng mấy tính chất của OOP. Nhưng ý đó ko phải là ko có lý, ví dụ như những object thuần chỉ là Data(chỉ có state ko có control state như Model, entity...), thì define những object như rất verbose. Nên đẻ ra mấy thư viện lombok, cái annotation @data rất hay, đúng ý nghĩa của 1 class data điển hình luôn. Lâu rồi mình ko làm Java, ko biết đã có improve gì chỗ này chưa.

Về cái private/public state, ví dụ như bạn có state là tiền. Bạn chỉ public những hành vi như mượn tiền, trả tiền, với một số rành buộc(validator) trên những hành vi này. Do đó những người khác không biết bạn có bao nhiêu tiền, không tự tiện access vô state, thay đổi state(tiền) của bạn.

Vấn đề trong tài liệu mô hình hoá 1 Object, thường nhắc tới attribute/property, nó khá technical và khó hiểu khi áp dụng trong thực tế, trong business. Sau này mình biết tới khái niệm state thì cảm thấy OOP nó dễ hiểu hơn nhiều. Và thực tế là nhiều người sử dụng OOP và kể cả FG không hiểu sự quan trọng của state, và cách control state hiệu quả.

Mình thì lại không đồng tình việc nói OOP là về quản lý state. Như bác nào đã post trước đó thì Alan Kay chủ yếu coi OOP là messaging.

steelheartvn said:

Hầu như(ko phải tất cả) những tính chất trên giúp quản lý state chặt chẽ, rõ ràng, ít bị issue..

Click to expand...

Chỉ có encapsulation và inheritance là có liên quan tới state, còn lại đều nói về behavior. Abstraction tạo ra một layer mới để đơn giản hóa/giảm sự phụ thuộc giữa các class. Polymorphism cho phép một hành động thực hiện được ở nhiều dạng khác nhau.

---

Mục tiêu của OOP là giải quyết sự phức tạp bằng cách phân chia trách nhiệm cho các class. Các class này phối hợp làm việc với nhau (messaging/behavior) để hoàn thành công việc, chứ không phải chỉ là maintain state (xem phần bonus bên dưới).

steelheartvn said:

Mấy thím nói private properties là ko có tác dụng gì, xài public đi cho dễ. Cái đó vi phạm nghiêm trọng mấy tính chất của OOP. Nhưng ý đó ko phải là ko có lý, ví dụ như những object thuần chỉ là Data(chỉ có state ko có control state như Model, entity...), thì define những object như rất verbose. Nên đẻ ra mấy thư viện lombok, cái annotation @data rất hay, đúng ý nghĩa của 1 class data điển hình luôn. Lâu rồi mình ko làm Java, ko biết đã có improve gì chỗ này chưa.

Click to expand...

Java mới có record, cũng là một dạng immutable data object.
Và việc sử dụng data object là dấu hiệu của procedural code, vì data một nơi mà code xử lý một nẻo. Thành ra lại không dùng đến OOP

---

Bonus thêm một ví dụ là closure trong JavaScript. Trong closure hoàn toàn có thể define state, behavior và control được access vào các state. Như vậy có thể xem closure là một dạng OOP được không?
Ps: sorry vì đào mộ, cơ mà topic hay quá

Hellsing said:

các thím cho em hỏi ké là instance vs object nó khác nhau ở điểm nào ạ, tại thời điểm hiện tại thì em hiểu tụi nó là giống nhau

Click to expand...

object là vozer instance là ông.

methanol197 said:

object là vozer instance là ông.

Click to expand...

Theo mình hiểu thì class là vozer, object == instance là methanol197

methanol197 said:

object là vozer instance là ông.

Click to expand...

Cùng 1 thứ đó thím ơi, tại xài từ khác thôi chứ ý có khác đâu.

nguyenduhn said:

Theo mình hiểu thì class là vozer, object == instance là methanol197

Click to expand...

Theo tối kiến của mình thì mình không đồng ý với ý kiến trên

tonghoangvu said:

Mình thì lại không đồng tình việc nói OOP là về quản lý state. Như bác nào đã post trước đó thì Alan Kay chủ yếu coi OOP là messaging.

Chỉ có encapsulation và inheritance là có liên quan tới state, còn lại đều nói về behavior. Abstraction tạo ra một layer mới để đơn giản hóa/giảm sự phụ thuộc giữa các class. Polymorphism cho phép một hành động thực hiện được ở nhiều dạng khác nhau.

---

Mục tiêu của OOP là giải quyết sự phức tạp bằng cách phân chia trách nhiệm cho các class. Các class này phối hợp làm việc với nhau (messaging/behavior) để hoàn thành công việc, chứ không phải chỉ là maintain state (xem phần bonus bên dưới).

Java mới có record, cũng là một dạng immutable data object.
Và việc sử dụng data object là dấu hiệu của procedural code, vì data một nơi mà code xử lý một nẻo. Thành ra lại không dùng đến OOP

---

Bonus thêm một ví dụ là closure trong JavaScript. Trong closure hoàn toàn có thể define state, behavior và control được access vào các state. Như vậy có thể xem closure là một dạng OOP được không?

Spoiler

Tất nhiên là không, closure chỉ là phần encapsulation của OOP (closures are poor man's objects). Nếu chỉ cần OOP để maintain state thì xài closure cho rồi.

Ps: sorry vì đào mộ, cơ mà topic hay quá

Click to expand...

Em thì lại có quan điểm khác xíu, OOP hay không thì abstraction vẫn luôn ở đó nên theo ý em thì chỉ có 3 tính chất OOP thôi. OOP là một trong số những cách đạt được abstraction, cách của OOP là gói behavior với state lại thành cái kêu là object rồi để nó giao tiếp với nhau qua interface (không phải interface của ngôn ngữ, interface theo nghĩa trừu tượng). Em nghĩ cái rối nhất chắc là chuyện những khái niệm trừu tượng được thảo luận và tính năng ngôn ngữ nó bị trộn lẫn với nhau làm cho người chưa quen hiểu nhầm.

uoc1landcnoivedayanuoi said:

Em thì lại có quan điểm khác xíu, OOP hay không thì abstraction vẫn luôn ở đó nên theo ý em thì chỉ có 3 tính chất OOP thôi. OOP là một trong số những cách đạt được abstraction, cách của OOP là gói behavior với state lại thành cái kêu là object rồi để nó giao tiếp với nhau qua interface (không phải interface của ngôn ngữ, interface theo nghĩa trừu tượng). Em nghĩ cái rối nhất chắc là chuyện những khái niệm trừu tượng được thảo luận và tính năng ngôn ngữ nó bị trộn lẫn với nhau làm cho người chưa quen hiểu nhầm.

Click to expand...

trừu tượng nó chỉ là 1 cái thuộc tính sinh sau đẻ muộn của oop,nếu tìm các tài liệu về lý thuyết oop chung thì chỉ có 3 cái chính,nên nhiều ông học java ,python mấy ngôn ngữ được phát triển mạnh thì luôn nghĩ có 4 cái
nhưng từ ban đầu nó có 3 cái thôi

thapnhat111 said:

trừu tượng nó chỉ là 1 cái thuộc tính sinh sau đẻ muộn của oop,nếu tìm các tài liệu về lý thuyết oop chung thì chỉ có 3 cái chính,nên nhiều ông học java ,python mấy ngôn ngữ được phát triển mạnh thì luôn nghĩ có 4 cái
nhưng từ ban đầu nó có 3 cái thôi

The 3 Pillars of Object-Oriented Programming (OOP) Brought Down to Earth - Tech Elevator

Object-oriented programming: Refers to the practice of defining classes and objects to organize code, and is used in most programming languages today. There are three major pillars on which object-oriented programming relies: encapsulation, inheritance, and polymorphism.

www.techelevator.com

Click to expand...

Trừu tượng nói chung thì có thể lấy toán làm ví dụ, nó lại có trước cả khi có máy tính ấy chứ thím. Ngay từ những thứ như con số, hàm, biến đã đậm tính trừu tượng rồi. Mấy mô hình toán học là bản cắt giảm tối giản hóa của vấn đề thực tế, đấy chính xác là trừu tượng mà. Trừu tượng mà em nói ở đây là cắt bỏ cái thừa và rút lấy cái chung thôi, em đang nói về khái niệm, chứ không nói về abstract keyword trong ngôn ngữ lập trình.

thím code 1 vài project rồi bị coupling tùm lum là tự tiến hóa thôi :v

Cắm mắt

Tính ra nhiều anh không biết rõ về OOP quá nhỉ, theo mình hiện tại chưa nói đến những kĩ năng khác, OOP mà chưa hiểu rõ thì khó mà giỏi đc. OOP thật ra nó chỉ là concept, khi code bạn có thể ko cần tuân theo, nhưng khi bạn thật hiện theo đủ và đúng thì nó sẽ mang lại những lợi ích. OOP còn tùy thuộc vào framework và ngôn ngữ chúng ta viết. Như java thì khi viết từ cơ bản nó đã đòi hỏi syntax cần phải tuân theo OOP vô cùng rõ ràng, còn python thì ko như vậy. Có nhiều bài viết trên gg bằng tiếng việt viết về OOP chỉ cóp nhặt lung tung nên gây khó khăn cho người muốn tìm hiểu. Ví dụ như Encapsulation, nhiều ví dụ trên mạng nêu rằng tính đóng gói ngăn người dùng access trực tiếp vào và sửa đổi các mã code mà phải thông qua method đc cung cấp. Từ người dùng ở đây rất có thể gây hiểu lầm với end user, vì end user làm gì có quyền hoặc ko thể truy cập vào source code thì làm sao mà access, làm sao end user có thể vào code của bạn mà gáng 1 propertise của 1 instance thành 1 giá trị khác. Vì vậy cho nên, encapsulation chỉ có tính chất phụ trợ cho cách làm việc của lập trình viên để tránh việc chính họ (hoặc người khác trong team) vô tình thay đổi 1 thứ gì đó mà họ ko nhận thức đc là nó đc protect. Khi họ muốn thay đổi, họ phải thông qua getter, setter (java), khi dùng getter, setter họ sẽ nhận thức đc rõ ràng những gì họ thay đổi. Và việc đó cũng giúp quản lý code dễ dàng hơn, cũng như dễ mở rộng, maintain sau này