|
|
|
JavaVietnam.org » Hiển thị tất cả diễn đàn » » Diễn đàn: Core Java - Java nền tảng » » » Luồng: Kế thừa không hết |
||
| In lúc 06:59:18 04-07-2009 |
|
|
| Gửi bởi cl lúc 18:19:29 27-09-2005 |
|
Re: Kế thừa không hết Cái này không xài được. Thực ra mình thấy cái ý tưởng của mình không chính thống lắm: Giả sử lớp Parent có phương thức X() là public. Lớp Child kế thừa từ Parent, như vậy theo lý thuyết thì mọi đối tượng của Child đều có phương thức X(). Mình muốn có một thiết kế mẫu nào đó mà sự kế thừa của Child từ Parent không đem lại cho Child phương thức X(). Còn việc override với cài đặt là rỗng vẫn cho Child một phương thức X(), và việc có một phương thức mà lại không làm việc là một việc làm theo mình là thừa. (Đây chỉ là một ý nghĩ thoáng qua của mình) Đây là ý tưởng ban đầu của người đặt câu hỏi. Cũng nên coi ý tưởng có hợp lý hay không trước khi mất thời giờ trả lời chứ ;-). Theo ý tưởng trên thì lời khuyên là nên xét lại thiết kế vì nó vi phạm nguyên lý Liskov substitution. Rõ ràng là chúng ném ra hoặc thông báo ra một câu là " method này không chưa được impl hoặc kô hỗ trợ". Cho nên mình để nghì dùng exception UnsupportedOperationException Việc override với cài đặt là rỗng, hay override nhưng throw một exception: "Phương thức này không hỗ trợ" là như nhau. Are you sure about this one? |
| Gửi bởi sonngoc lúc 21:09:15 27-09-2005 |
|
Re: Kế thừa không hết Cũng nên coi ý tưởng có hợp lý hay không trước khi mất thời giờ trả lời chứ ;-). Theo ý tưởng trên thì lời khuyên là nên xét lại thiết kế vì nó vi phạm nguyên lý Liskov substitution. Thanks bro! Rõ ràng là chúng ném ra hoặc thông báo ra một câu là " method này không chưa được impl hoặc kô hỗ trợ". Cho nên mình để nghì dùng exception UnsupportedOperationException Việc override với cài đặt là rỗng, hay override nhưng throw một exception: "Phương thức này không hỗ trợ" là như nhau. Are you sure about this one? Theo ngữ cảnh của câu hỏi đặt ra  ---------------------------------------- MiniAjax Ajax.Solutoire |
| Gửi bởi cl lúc 06:12:36 28-09-2005 |
|
Re: Kế thừa không hết Rõ ràng là chúng ném ra hoặc thông báo ra một câu là " method này không chưa được impl hoặc kô hỗ trợ". Cho nên mình để nghì dùng exception UnsupportedOperationException Việc override với cài đặt là rỗng, hay override nhưng throw một exception: "Phương thức này không hỗ trợ" là như nhau. Are you sure about this one? Theo ngữ cảnh của câu hỏi đặt ra Có điều ngữ cảnh của 2 giải pháp (runtime semantics) hoàn toàn khác nhau ;-). Keep up the goodworks. |
| Gửi bởi phongtq lúc 09:03:12 28-09-2005 |
|
Re: Kế thừa không hết ... Cũng nên coi ý tưởng có hợp lý hay không trước khi mất thời giờ trả lời chứ ;-). Theo ý tưởng trên thì lời khuyên là nên xét lại thiết kế vì nó vi phạm nguyên lý Liskov substitution. Chắc ý tưởng của bạn ấy fải thiết kế lại Java..  Coi như tụi em hong quen với Liskov đi anh.. Đôi khi Archimedes cũng xem lại thiết kế của Galile mà.. hihi.. |
| Gửi bởi hungjava lúc 11:25:17 28-09-2005 |
|
Re: Kế thừa không hết Cũng nên coi ý tưởng có hợp lý hay không trước khi mất thời giờ trả lời chứ ;-). Theo ý tưởng trên thì lời khuyên là nên xét lại thiết kế vì nó vi phạm nguyên lý Liskov substitution. Trong một bài viết của anh cl có nói về các nguyên lý thiết kế OOP: 1. Open closed, 2. Liskov substitution, 3. Dependency inversion, 4. Interface segregation, 5. Single Responsibility Anh có thể nói khái quát các nguyên lý này được không. Thanks! ---------------------------------------- The greatest thing You've ever learned is just to love And be loved in return. |
| Gửi bởi cl lúc 12:53:26 28-09-2005 |
|
Re: Kế thừa không hết Trong một bài viết của anh cl có nói về các nguyên lý thiết kế OOP: 1. Open closed, 2. Liskov substitution, 3. Dependency inversion, 4. Interface segregation, 5. Single Responsibility Anh có thể nói khái quát các nguyên lý này được không. Thanks! Như đã nói trong post đó - bồ cố gắng đọc trước từng nguyên lý một (theo thứ tự trên) rồi đặt tiêu đề cụ thể để thảo luận. Active learning kiểu này giúp bồ 'nhớ' dai và sâu hơn. Khái quát thì có thể hiểu OCP là mở rộng chức năng (open to extension) mà không cần thay đổi thiết kế (closed to modification). Chỉ nhiêu đây đã thấy đòi hỏi ban đầu của bồ không hợp lý với 'tinh thần' OO cho lắm. Thân |
| Gửi bởi traimuopdang lúc 19:21:12 28-09-2005 |
|
Re: Kế thừa không hết Giả sử lớp Parent có phương thức X() là public. Lớp Child kế thừa từ Parent, như vậy theo lý thuyết thì mọi đối tượng của Child đều có phương thức X(). tại sao set thuộc tính là public rồi lại không cho người khác sử dụng nhỉ? giống như vứt 500.000đ ngoài đường rồi bỏ mọi người đừng có lượm!? ---------------------------------------- Betonamujin no otoko no hito |
| Gửi bởi hungjava lúc 08:29:59 29-09-2005 |
|
Re: Kế thừa không hết Thanks mọi người đã nhiệt tình quan tâm. Quả thật trước khi đưa ra luồng này tôi cũng thấy rằng ý tưởng này là không khả thi. Nhưng tôi vẫn thắc mắc một điều như thế này: Xét tính kế thừa của con người (hay động vật ), qua rất nhiều thế hệ một số đặc tính bị mất hẳn đi, nhưng những đặc tính cơ bản thì vẫn còn giữ lại. Việc kế thừa đến một mức nào đó làm cho các đặc tính mất đi, nhưng đến mức nào thì đó không phải là điều được dự đoán trước. Như vậy thiết nghĩ vấn đề tôi đưa ra không hẳn là vô lý (theo tôi nghĩ - mặc dù với các ngôn ngữ OOP hiện có thì điều này là không tưởng). Việc override nhưng không làm gì không giải quyết được vấn đề trên: hành vi đó tuy không có tác dụng nhưng vẫn thể hiện ra ngoài ( như một người bị liệt khác với một người vốn dĩ đã không có chân tay ). Với trình độ giới hạn của mình , tôi không thể nào giải quyết được vấn đề trên. Nhưng dù sao cũng cám ơn mọi người đã nhiệt tình thảo luận. Thân! ---------------------------------------- The greatest thing You've ever learned is just to love And be loved in return. |
| Gửi bởi cl lúc 09:11:03 29-09-2005 |
|
Re: Kế thừa không hết Xét tính kế thừa của con người (hay động vật ), qua rất nhiều thế hệ một số đặc tính bị mất hẳn đi ... và chúng trở thành 1 loài mới không thích hợp với môi trường mà tổ tiên chúng từng sinh sống. OO cũng tương tự, nếu 1 class mới phá vỡ giao ước (contract) được định sẵn bởi class cha thì class đó không thích hợp với framework mà class cha là 1 thành phần (Liskov substitution). nhưng những đặc tính cơ bản thì vẫn còn giữ lại. Việc kế thừa đến một mức nào đó làm cho các đặc tính mất đi, nhưng đến mức nào thì đó không phải là điều được dự đoán trước. Hưng/Hùng nhận được điều này thì nên tham khảo nguyên lý interface segration và single responsibility - những thứ gì là căn bản cần được "đóng gói" cho thật kỹ để nâng cao độ tái dụng và đỡ làm ô nhiễm cho các 'thế hệ' sau. nhưng đến mức nào thì đó không phải là điều được dự đoán trước. Chính xác, không ai biết trước được, cũng vì vậy refactoring là 1 bước quan trọng trong software engineering ;-) Như vậy thiết nghĩ vấn đề tôi đưa ra không hẳn là vô lý (theo tôi nghĩ - mặc dù với các ngôn ngữ OOP hiện có thì điều này là không tưởng). Không có đòi hỏi nào vô lý cả, chỉ có giải pháp không chuyên thôi ;-). Hưng/Hùng đang ở bước "vật lộn", qua được bước này thì sẽ hít thở với OO ;-). Cứ việc kéo dài mạch thảo luận này, tôi sẽ góp ý theo khả năng. Thân |
| Gửi bởi javae202 lúc 09:34:08 29-09-2005 |
|
Re: Kế thừa không hết Hi all và anh CL! Tôi không nghĩ đòi hỏi của hungjava là quá vô lý. Như đã nói ở trên JDBC và các thư viện driver là ví dụ về việc co hẹp bớt tính năng. JDBC hỗ trợ gọi Procedure, Batch, nhưng HSQLDB hay MySQL không hỗ trợ thì các chức năng này phải bỏ ra thôi. Đặt anh cl vào trong trường hợp này anh sẽ impl như thế nào để vẫn thỏa mãn những nguyên tắc OOP? ---------------------------------------- http://rualatngua.wordpress.com |
|
|
Múi giờ hiện tại là +7 06:59:20 04-07-2009 |