OOP có khó không vì nó không tự nhiên?


86

Người ta thường có thể nghe rằng OOP tự nhiên tương ứng với cách mọi người nghĩ về thế giới. Nhưng tôi hoàn toàn không đồng ý với tuyên bố này: Chúng tôi (hoặc ít nhất là tôi) khái niệm hóa thế giới về mối quan hệ giữa những thứ chúng ta gặp phải, nhưng trọng tâm của OOP là thiết kế các lớp riêng lẻ và phân cấp của chúng.

Lưu ý rằng, trong cuộc sống hàng ngày, các mối quan hệ và hành động tồn tại chủ yếu giữa các đối tượng sẽ là các thể hiện của các lớp không liên quan trong OOP. Ví dụ về các mối quan hệ như vậy là: "màn hình của tôi ở trên cùng của bảng"; "Tôi (một con người) đang ngồi trên ghế"; "một chiếc xe đang trên đường"; "Tôi đang gõ trên bàn phím"; "máy pha cà phê đun sôi nước", "văn bản được hiển thị trong cửa sổ đầu cuối."

Chúng tôi nghĩ theo nghĩa hai phần tử (đôi khi là hóa trị ba, ví dụ như trong "Tôi đã tặng hoa cho bạn") động từ trong đó động từ là hành động (quan hệ) hoạt động trên hai đối tượng để tạo ra một số kết quả / hành động. Các trọng tâm là về hành động, và hai (hoặc ba) [ngữ pháp] đối tượng có tầm quan trọng như nhau.

Ngược lại với OOP nơi đầu tiên bạn phải tìm một đối tượng (danh từ) và bảo nó thực hiện một số hành động trên một đối tượng khác. Cách suy nghĩ được chuyển từ hành động / động từ hoạt động trên danh từ sang danh từ hoạt động trên danh từ - như thể mọi thứ đang được nói bằng giọng bị động hoặc phản xạ, ví dụ: "văn bản đang được hiển thị bởi cửa sổ đầu cuối". Hoặc có thể "văn bản tự vẽ trên cửa sổ terminal".

Không chỉ trọng tâm được chuyển sang danh từ, mà một trong những danh từ (hãy gọi nó là chủ đề ngữ pháp) được cho "tầm quan trọng" cao hơn so với đối tượng khác (đối tượng ngữ pháp). Do đó, người ta phải quyết định xem người ta sẽ nói terminalWindow.show (someText) hay someText.show (terminalWindow). Nhưng tại sao gánh nặng cho những người có các quyết định tầm thường như vậy mà không có hậu quả hoạt động khi một người thực sự có nghĩa là hiển thị (terminalWindow, someText)? [Hậu quả là không đáng kể về mặt vận hành - trong cả hai trường hợp, văn bản được hiển thị trên cửa sổ đầu cuối - nhưng có thể rất nghiêm trọng trong việc thiết kế hệ thống phân cấp lớp và một lựa chọn "sai" có thể dẫn đến mã bị sai lệch và khó duy trì.]

Do đó, tôi sẽ lập luận rằng cách làm chủ đạo của OOP (dựa trên lớp, gửi đơn) là khó bởi vì nó KHÔNG CHÍNH THỨC và không tương ứng với cách con người nghĩ về thế giới. Các phương pháp chung từ CLOS gần với cách suy nghĩ của tôi hơn, nhưng, than ôi, đây không phải là cách tiếp cận rộng rãi.

Với những vấn đề này, làm thế nào / tại sao nó lại xảy ra mà cách làm OOP hiện nay trở nên phổ biến? Và những gì, nếu có, có thể được thực hiện để truất ngôi nó?


OOP là dành cho 'lập trình', nó được tạo ra để trình biên dịch thưởng thức. nó không phải là một cách để mô hình hóa thế giới thực theo bất kỳ cách nào. Người ta thường sử dụng các ví dụ trong thế giới thực như lớp động vật và lớp hình chữ nhật, trong khi dạy OOP nhưng đây chỉ là các ví dụ để đơn giản hóa các khái niệm. Thật không may, ngôn ngữ lập trình và mô hình 'xảy ra' theo cách không tiến hóa và không khoa học. Với một vài ngoại lệ, quy trình thiết kế ngôn ngữ thường là đứa trẻ của một vài người đoán đúng nhất!
NoChance

3
Tôi sẽ không đồng ý với tuyên bố "trọng tâm của OOP là thiết kế các lớp riêng lẻ và hệ thống phân cấp của chúng." vì maybie nó là trọng tâm của một (các) triển khai OOP nhất định, nhưng tôi lấy ví dụ đã phát hiện ra rằng các ngôn ngữ OOP động thường không có hệ thống phân cấp lớn hoặc thậm chí các lớp. Chà, định nghĩa OOP có thể thay đổi trong tương lai, có một cố gắng thay đổi ngay cả Đối tượng một wcook.blogspot.com/2012/07/proposed-for-simplified-modern.html
Azder

1
OOP đang xác định các đối tượng trong hệ thống và xây dựng các lớp dựa trên các đối tượng đó. Không phải hướng ngược lại. Đây là lý do tại sao tôi cũng không đồng ý với "trọng tâm của OOP là thiết kế các lớp riêng lẻ và phân cấp của chúng".
Radu Murzea


1
Tôi nghĩ rằng đây là một câu hỏi mang tính chủ quan cao và nó chứa đầy những giả định kỳ lạ về OOP và "thế giới thực" là gì và mọi người nghĩ về vấn đề như thế nào. Và cuối cùng nó thậm chí còn hỏi "Và, nếu có bất cứ điều gì, có thể được thực hiện để truất ngôi nó?" Điều thực sự cho thấy OP có ý kiến ​​rất mạnh mẽ về điều này. Nếu bạn là người "tôn giáo" về các mô hình lập trình, tôi đoán bạn không cần bất kỳ câu trả lời nào ... bạn đã biết những gì bạn muốn nghe. Nếu tôi biết về câu hỏi này khi được hỏi lần đầu, có lẽ tôi đã bỏ phiếu để đóng nó ...
Simon Lehmann

Câu trả lời:


97

OOP là không tự nhiên đối với một số vấn đề. Thủ tục cũng vậy. Chức năng cũng vậy. Tôi nghĩ rằng OOP có hai vấn đề thực sự làm cho nó có vẻ khó khăn.

  1. Một số người hành động như đó là Cách thực sự để lập trình và tất cả các mô hình khác đều sai. IMHO mọi người nên sử dụng ngôn ngữ đa khung và chọn mô hình tốt nhất cho dự án con mà họ hiện đang làm việc. Một số phần trong mã của bạn sẽ có kiểu OO. Một số sẽ có chức năng. Một số sẽ có một phong cách thủ tục thẳng. Với kinh nghiệm, rõ ràng mô hình nào là tốt nhất cho những gì:

    a. OO thường tốt nhất khi bạn có các hành vi được kết hợp chặt chẽ với trạng thái mà chúng hoạt động và bản chất chính xác của trạng thái là một chi tiết triển khai, nhưng sự tồn tại của nó không thể dễ dàng bị trừu tượng hóa. Ví dụ: Các lớp sưu tập.

    b. Thủ tục là tốt nhất khi bạn có một loạt các hành vi không được kết hợp chặt chẽ với bất kỳ dữ liệu cụ thể nào. Ví dụ, có thể chúng hoạt động trên các loại dữ liệu nguyên thủy. Dễ dàng nhất để nghĩ về hành vi và dữ liệu là các thực thể riêng biệt ở đây. Ví dụ: Mã số.

    c. Chức năng là tốt nhất khi bạn có một cái gì đó khá dễ dàng để viết một cách khai báo sao cho sự tồn tại của bất kỳ trạng thái nào là một chi tiết triển khai có thể dễ dàng được trừu tượng hóa. Ví dụ: Bản đồ / Giảm song song.

  2. OOP thường cho thấy sự hữu ích của nó đối với các dự án lớn, nơi có các đoạn mã được đóng gói tốt là thực sự cần thiết. Điều này không xảy ra quá nhiều trong các dự án mới bắt đầu.


4
Tôi nghĩ rằng một điểm quan trọng trong câu hỏi không phải là liệu OOP có tự nhiên không, mà là cách tiếp cận chủ đạo đối với OOP có phải là cách tiếp cận OOP tự nhiên nhất hay không. (Dù sao cũng trả lời tốt.)
Giorgio

11
"OOP thường cho thấy sự hữu ích của nó đối với các dự án lớn, nơi có các đoạn mã được đóng gói tốt là thực sự cần thiết.": Nhưng đây không phải là một đặc tính cụ thể của OOP, vì cũng có các khái niệm mô-đun tốt cho các ngôn ngữ lập trình, chức năng, ... .
Giorgio

2
OOP thực sự ở một trục khác với thủ tục / chức năng; nó giải quyết cách tổ chức và đóng gói mã chứ không phải cách mô tả các hoạt động. (Bạn luôn hợp tác với OOP với mô hình thực thi. Có, có các ngôn ngữ chức năng OOP +.)
Donal Fellows

1
Không thể nói rằng OOP chỉ là các hộp chúng ta đặt các công cụ thủ tục vào?
Erik Reppen

Trong OOP, bạn vẫn có thể viết phương thức. Điều gì làm cho OOP yếu hơn lập trình Thủ tục?
Mert Akcakaya

48

IMHO nó là một câu hỏi về sở thích cá nhân và cách suy nghĩ. Tôi không có nhiều vấn đề với OO.

Chúng tôi (hoặc ít nhất là tôi) khái niệm hóa thế giới theo mối quan hệ giữa những thứ chúng ta gặp phải, nhưng trọng tâm của OOP là thiết kế các lớp riêng lẻ và hệ thống phân cấp của chúng.

IMHO điều này không hoàn toàn như vậy, mặc dù nó có thể là một nhận thức phổ biến. Alan Kay, người phát minh ra thuật ngữ OO, luôn nhấn mạnh các thông điệp được gửi giữa các đối tượng, hơn là chính các đối tượng. Và các tin nhắn, ít nhất là với tôi, biểu thị các mối quan hệ.

Lưu ý rằng, trong cuộc sống hàng ngày, các mối quan hệ và hành động tồn tại chủ yếu giữa các đối tượng sẽ là các thể hiện của các lớp không liên quan trong OOP.

Nếu có một mối quan hệ giữa các đối tượng, thì chúng có liên quan, theo định nghĩa. Trong OO, bạn có thể biểu thị nó với sự phụ thuộc liên kết / tổng hợp / sử dụng giữa hai lớp.

Chúng tôi nghĩ theo nghĩa hai phần tử (đôi khi là hóa trị ba, ví dụ như trong "Tôi đã tặng hoa cho bạn") động từ trong đó động từ là hành động (quan hệ) hoạt động trên hai đối tượng để tạo ra một số kết quả / hành động. Trọng tâm là hành động và hai (hoặc ba) đối tượng [ngữ pháp] có tầm quan trọng như nhau.

Nhưng họ vẫn có những vai trò được xác định rõ trong bối cảnh: chủ đề, đối tượng, hành động, v.v. "Tôi đã tặng hoa cho bạn" hoặc "Bạn đã tặng hoa cho tôi" không giống nhau (không đề cập đến "Hoa tặng bạn cho tôi": -)

Ngược lại với OOP nơi đầu tiên bạn phải tìm một đối tượng (danh từ) và bảo nó thực hiện một số hành động trên một đối tượng khác. Cách suy nghĩ được chuyển từ hành động / động từ hoạt động trên danh từ sang danh từ hoạt động trên danh từ - như thể mọi thứ đang được nói bằng giọng bị động hoặc phản xạ, ví dụ: "văn bản đang được hiển thị bởi cửa sổ đầu cuối". Hoặc có thể "văn bản tự vẽ trên cửa sổ terminal".

Tôi không đồng ý với điều này. IMHO câu tiếng Anh "Bill, go hell" đọc tự nhiên hơn trong mã chương trình bill.moveTo(hell)chứ không phải move(bill, hell). Và trước đây trên thực tế giống với giọng nói hoạt động ban đầu.

Do đó, người ta phải quyết định xem người ta sẽ nói terminalWindow.show (someText) hay someText.show (terminalWindow)

Một lần nữa, nó không giống nhau khi yêu cầu thiết bị đầu cuối hiển thị một số văn bản hoặc yêu cầu văn bản hiển thị thiết bị đầu cuối. IMHO nó là khá rõ ràng cái nào là tự nhiên hơn.

Với những vấn đề này, làm thế nào / tại sao nó lại xảy ra mà cách làm OOP hiện nay trở nên phổ biến?

Có lẽ bởi vì phần lớn các nhà phát triển OO thấy OO khác với bạn?


15
+1 để đề cập trực tiếp rằng các tin nhắn giữa các đối tượng và tầm quan trọng của chúng từ Alan Kay
bunglestink 18/03/2016

3
@zvrba, thực sự, cũng có những người tiên phong OO khác, nhưng đó là bên cạnh điểm của cuộc thảo luận này. "Điều tự nhiên nhất là yêu cầu văn bản được hiển thị." - bây giờ bạn đang sử dụng cùng một giọng nói thụ động mà bạn tuyên bố là rất "không tự nhiên" trong OOP.
Péter Török

5
@zvrba, bạn nói rằng 'luôn có một "tác nhân" [...] làm một số việc', nhưng phản đối cách tiếp cận OO trong việc xác định và đặt tên cho các tác nhân đó và xử lý họ như những công dân hạng nhất trong ngôn ngữ . Đối với tôi đây là một phần của việc mô hình hóa miền vấn đề - dù sao bạn cũng cần phải thực hiện công việc đó, chỉ cần ánh xạ mô hình miền kết quả thành mã theo một cách khác, tùy thuộc vào ngôn ngữ của bạn có phải là OO hay không.
Péter Török

6
@zvrba, đó không phải là OO per se, mà là nhà phát triển / nhà thiết kế, người quyết định về vai trò và trách nhiệm của các đối tượng khác nhau. Sử dụng phương pháp OO có thể mang lại các mô hình và thiết kế miền tốt hoặc xấu, giống như sử dụng một con dao có thể giúp bạn có được một lát bánh mì ngon hoặc một ngón tay chảy máu - chúng ta vẫn không đổ lỗi cho con dao, bởi vì nó chỉ là một công cụ. Cũng lưu ý rằng các khái niệm / đối tượng / tác nhân trong mô hình là sự trừu tượng hóa của mọi thứ trong thế giới thực và vì thế luôn bị giới hạn và bị bóp méo, chỉ tập trung vào các khía cạnh "thú vị" cụ thể.
Péter Török

6
@zvrba, một chiếc xe thực sự không bắt đầu theo ý mình - giống như một Carvật thể start()chỉ khi phương thức của nó được ai đó gọi một cách rõ ràng.
Péter Török

10

Một số lập trình viên thấy khó khăn vì các lập trình viên đó thích suy nghĩ về cách giải quyết vấn đề cho máy tính, chứ không phải về cách giải quyết vấn đề.

... nhưng trọng tâm của OOP là thiết kế các lớp riêng lẻ và phân cấp của chúng.

Không phải là về điều đó. OOD là về việc tìm ra cách mọi thứ cư xử và tương tác.

Chúng tôi nghĩ theo nghĩa hai phần tử (đôi khi là hóa trị ba, ví dụ như trong "Tôi đã tặng hoa cho bạn") động từ trong đó động từ là hành động (quan hệ) hoạt động trên hai đối tượng để tạo ra một số kết quả / hành động. Trọng tâm là hành động và hai (hoặc ba) đối tượng [ngữ pháp] có tầm quan trọng như nhau.

Trọng tâm của OOD luôn là hành động, trong đó hành động là hành vi của các đối tượng. Đối tượng không là gì nếu không có hành vi của họ. Hạn chế đối tượng duy nhất của OOD là mọi thứ phải được thực hiện bằng một cái gì đó.

Tôi không thấy người làm là quan trọng hơn sau đó là điều phải làm một cái gì đó cho nó.

Nhưng tại sao gánh nặng cho những người có các quyết định tầm thường như vậy mà không có hậu quả hoạt động khi một người thực sự có nghĩa là hiển thị (terminalWindow, someText)?

Đối với tôi đó là điều tương tự với một ký hiệu khác. Bạn vẫn phải quyết định ai là show-er và ai là show-ee. Một khi bạn biết điều đó, thì không có quyết định nào ở OOD. Windows hiển thị văn bản -> Window.Show (văn bản).

Rất nhiều thứ ngoài kia (đặc biệt là trong khu vực di sản) nói rằng đó là OO khi nó không. Ví dụ, có một số lượng lớn mã C ++ không triển khai một con số của OOD.

OOD dễ dàng một khi bạn thoát ra khỏi suy nghĩ rằng bạn đang giải quyết một vấn đề cho máy tính. Bạn đang giải quyết vấn đề cho những thứ làm công cụ.


10
Tôi không thích chính xác vì tôi thích cách giải quyết vấn đề, thời gian. Tôi không muốn nghĩ làm thế nào để dịch ngôn ngữ tự nhiên của một miền vấn đề sang một thế giới xa lạ của các đối tượng, thông điệp, sự kế thừa, v.v. Tôi không muốn phát minh ra các nguyên tắc phân loại chữ tượng hình nơi chúng không tồn tại một cách tự nhiên. Tôi muốn mô tả vấn đề bằng ngôn ngữ tự nhiên của nó và giải quyết nó một cách dễ dàng nhất có thể. Và, nhân tiện, thế giới không chỉ có "những thứ làm công việc". Quan điểm của bạn về thực tế là vô cùng hẹp.
SK-logic

7
@Matt Ellen, tôi viết các chương trình mô hình hành vi của những người được mời không phải là "những thứ" và điều đó không "làm" bất kỳ "công cụ" nào. Bất kỳ thực thể bất biến không làm bất cứ điều gì. Bất kỳ hàm thuần toán học nào cũng không làm được gì - nó chỉ là ánh xạ từ bộ này sang bộ khác và thế giới này chủ yếu được mô tả bởi các hàm như vậy. Bất kỳ hình thức logic nào không "làm" bất cứ điều gì. Có, OOD sẽ không giúp tôi, vì tôi có thể sử dụng các mô hình và mô hình trừu tượng mạnh mẽ hơn nhiều. Quay trở lại một khu vực nguyên thủy, hạn chế, hạn chế sẽ khiến tôi tàn phế nặng nề.
SK-logic

2
@Matt Ellen, vâng, tôi muốn xem các tài liệu tham khảo ủng hộ những tuyên bố kỳ lạ như vậy rằng thế giới được xem tốt hơn dưới dạng một tập hợp "những việc làm" hoặc "các đối tượng tương tác qua tin nhắn". Nó hoàn toàn không tự nhiên. Lấy bất kỳ lý thuyết khoa học nào (vì tất cả chúng đều gần giống với việc mô hình hóa thế giới thực như có thể ở giai đoạn này), và cố gắng viết lại nó bằng thuật ngữ của bạn. Kết quả sẽ vụng về và vụng về.
SK-logic

4
@ Antonio2011a, không có mô hình lập trình hoặc mô hình hóa duy nhất nào có thể bao quát tất cả các lĩnh vực vấn đề có thể có hiệu quả. OOP, chức năng, dataflow, logic thứ nhất, bất cứ điều gì khác - tất cả chúng đều là các mô hình cụ thể của miền và không có gì khác. Tôi chỉ ủng hộ sự đa dạng và cách tiếp cận cởi mở để giải quyết vấn đề. Thu hẹp suy nghĩ của bạn xuống một mô hình duy nhất chỉ là ngu ngốc. Điều gần nhất với cách tiếp cận phổ quát, không giới hạn bạn trong một khung ngữ nghĩa duy nhất, là en.wikipedia.org/wiki/L Language
SK-logic

3
@Calmarius tại sao bạn sẽ làm cho lập trình dễ dàng hơn cho máy tính? Điều đó thật ngớ ngẩn. Đó là những người phải làm công việc khó khăn hơn.
Matt Ellen

7

Có lẽ, tôi không thể có được điểm, nhưng:

Đọc cuốn sách đầu tiên về OOP (đầu thập niên 90, cẩm nang mỏng của Borland cho Pascal) tôi đơn giản ngạc nhiên với sự đơn giản và tiềm năng của nó. (Trước đây, tôi đã sử dụng Cobol, Fortran, ngôn ngữ hội và các công cụ tiền sử khác.)

Đối với tôi, nó khá rõ ràng: một con chó là một con vật, một con vật phải ăn, con chó của tôi là một con chó, vì vậy nó phải ăn ...

Mặt khác, bản thân việc lập trình vốn không tự nhiên (tức là nhân tạo). Lời nói của con người là giả tạo (đừng đổ lỗi cho tôi, tất cả chúng ta đều đã học ngôn ngữ của mình từ người khác, không ai biết người phát minh ra tiếng Anh). Theo một số nhà khoa học, tâm trí của con người được hình thành bởi ngôn ngữ mà anh ta đã học trước tiên.

Tôi thừa nhận, một số cấu trúc trong các ngôn ngữ OO hiện đại hơi khó xử, nhưng đó là sự tiến hóa.


1
Chính xác thì công việc của bạn là gì để bạn chuyển từ cobol sang fortran, sau đó đến lắp ráp (và phần còn lại)?
Rook

1
Sắp xếp sai. Trên thực tế, tôi đã bắt đầu với Basic, sau đó chuyển đến Fortran và sau đó đến hội và Cobol (vâng, đó là thứ tự đúng: hội đầu tiên). Máy tính đầu tiên trong đời tôi là một máy tính lớn "khổng lồ", bộ nhớ 256kB, đánh máy bàn điều khiển của nó, cho nó ăn bằng thẻ đục lỗ, bởi vì tôi là người vận hành nó. Khi tôi đã tăng đủ để trở thành một lập trình viên hệ thống, một điều đáng ngờ gọi là PC-AT đã hạ cánh xuống bàn của tôi. Vì vậy, tôi đã lao vào GW-Basic, Turbo-Pascal, ... và cứ thế.
Nerevar

1
Tôi đã không tham gia vào đó. Thêm vào lĩnh vực công việc của bạn; bởi vì tôi không biết nhiều người (bất kỳ ai thực sự) đã giao dịch với COBOL (định hướng kinh doanh), fortran (lĩnh vực khoa học), trình biên dịch (định hướng cs nhiều hơn) và sau đó là những người khác. Tuy nhiên họ có phải là lập trình viên chuyên nghiệp hay không.
Rook

1
Không có gì bí ẩn: tham gia vào các đội và dự án nơi quyết định về phương pháp tiếp cận đã được đưa ra trước đó. Và một số mức độ tò mò không tầm thường về các công cụ họ đang sử dụng.
Nerevar

6

Một điều khiến tôi cảm thấy khó khăn khi nghĩ rằng OOP là về mô hình hóa thế giới. Tôi nghĩ rằng nếu tôi không hiểu đúng, một cái gì đó có thể đến và cắn vào mông tôi (một điều là đúng hoặc không phải vậy). Tôi đã rất ý thức về các vấn đề giả vờ mọi thứ là một đối tượng hoặc thực thể. Điều này khiến tôi rất thận trọng và thiếu tự tin về lập trình trong OOP.

Sau đó tôi đọc SICP và nhận ra một sự hiểu biết mới rằng đó thực sự là về các loại dữ liệu và kiểm soát quyền truy cập vào chúng. Tất cả các vấn đề tôi đã tan chảy vì chúng dựa trên một tiền đề sai lầm, rằng trong OOP bạn đang làm mẫu cho thế giới.

Tôi vẫn ngạc nhiên trước những khó khăn to lớn mà tiền đề sai lầm này mang lại cho tôi (và cách tôi để bản thân mình được nhìn thấy nó).


Cảm ơn bạn đã chỉ ra sự nguy hiểm của việc cố gắng mô hình hóa thế giới.
Sean McMillan

4

Đúng, bản thân OOP rất không tự nhiên - thế giới thực không hoàn toàn được tạo thành từ các phân loại phân cấp. Một số phần nhỏ của nó được làm từ những thứ đó, và những phần đó là những thứ duy nhất có thể được thể hiện đầy đủ dưới dạng OO. Tất cả những người còn lại không thể tự nhiên phù hợp với lối suy nghĩ tầm thường và hạn chế như vậy. Xem các ngành khoa học tự nhiên, xem có bao nhiêu ngôn ngữ toán học khác nhau đã được phát minh ra để diễn đạt theo cách đơn giản nhất hoặc ít nhất có thể hiểu được sự phức tạp của thế giới thực. Và hầu như không ai trong số họ có thể dễ dàng dịch sang ngôn ngữ của các đối tượng và tin nhắn.


5
Vâng, điều đó cũng đúng với bất kỳ loại ký hiệu chính thức nào đang cố gắng mô tả chính xác thế giới thực.
Péter Török

1
@ Péter Török, chính xác là quan điểm của tôi. Không có chủ nghĩa hình thức duy nhất bao gồm tất cả mọi thứ. Bạn phải sử dụng tất cả chúng, trong vô số đáng sợ của chúng. Và đó là lý do tại sao tôi tin vào một chương trình định hướng ngôn ngữ - nó cho phép áp dụng các hình thức khác nhau, thường không tương thích vào một thực thể mã vững chắc.
SK-logic

1
Tất cả mọi thứ có thể được phân loại thành phân loại phân cấp. Bí quyết được đưa ra với các kế hoạch có ý nghĩa. Nhiều kế thừa thường được tham gia. Một sự khác biệt lớn giữa phần mềm và thế giới thực là trong thế giới thực, chúng ta thường phải suy luận hoặc khám phá các sơ đồ phân loại; trong phần mềm, chúng tôi phát minh ra chúng.
Caleb

1
Bằng cách sử dụng một thuật ngữ như "phân loại phân cấp", tôi nghĩ rằng bạn đang nghĩ về sự kế thừa. Kế thừa thực sự là khó để lý do về. Đó là lý do tại sao mọi người đề nghị sử dụng thành phần trên thừa kế.
Frank Shearar

1
@Frank: Có nhiều loại phân loại phân cấp trong thế giới thực, trong đó thừa kế chỉ là một. Làm tất cả điều này đúng cách đòi hỏi các công cụ tốt hơn OOP (ví dụ, lý luận bản thể học) và đã gây ra vấn đề cho các nhà triết học trong hàng thiên niên kỷ
Donal Fellows

4

Chúng tôi (hoặc ít nhất là tôi) khái niệm hóa thế giới theo mối quan hệ giữa những thứ chúng ta gặp phải, nhưng trọng tâm của OOP là thiết kế các lớp riêng lẻ và hệ thống phân cấp của chúng.

Bạn đang bắt đầu từ (IMO) một tiền đề sai. Các mối quan hệ giữa các đối tượng được cho là quan trọng hơn so với chính các đối tượng. Đó là các mối quan hệ cung cấp một cấu trúc chương trình hướng đối tượng. Kế thừa, mối quan hệ giữa các lớp, tất nhiên rất quan trọng vì lớp của một đối tượng xác định những gì đối tượng có thể làm. Nhưng đó là mối quan hệ giữa các đối tượng riêng lẻ xác định những gì một đối tượng thực sự làm trong giới hạn được xác định bởi lớp và do đó, chương trình này hoạt động như thế nào.

Mô hình hướng đối tượng ban đầu có thể khó khăn không phải vì khó nghĩ ra các loại đối tượng mới, mà vì khó hình dung ra một biểu đồ của các đối tượng và hiểu mối quan hệ giữa chúng nên là gì, đặc biệt là khi bạn không có cách để mô tả những mối quan hệ. Đây là lý do tại sao các mẫu thiết kế rất hữu ích. Các mẫu thiết kế gần như hoàn toàn về mối quan hệ giữa các đối tượng. Các mẫu cung cấp cho chúng ta cả các khối xây dựng mà chúng ta có thể sử dụng để thiết kế các mối quan hệ đối tượng ở mức cao hơn và ngôn ngữ mà chúng ta có thể sử dụng để mô tả các mối quan hệ đó.

Điều tương tự cũng đúng trong các lĩnh vực sáng tạo hoạt động trong thế giới vật lý. Bất cứ ai cũng có thể ném một loạt các phòng và gọi nó là một tòa nhà. Các phòng thậm chí có thể được trang bị đầy đủ với tất cả các điểm mới nhất, nhưng điều đó không làm cho tòa nhà hoạt động. Công việc của một kiến ​​trúc sư là tối ưu hóa các mối quan hệ giữa các phòng đó đối với các yêu cầu của mọi người khi sử dụng các phòng đó và môi trường của tòa nhà. Làm cho các mối quan hệ trở nên đúng đắn là những gì làm cho một công trình xây dựng từ các quan điểm chức năng và thẩm mỹ.

Nếu bạn gặp khó khăn khi làm quen với OOP, tôi khuyến khích bạn suy nghĩ thêm về cách các đối tượng của bạn khớp với nhau và cách sắp xếp trách nhiệm của chúng. Nếu bạn chưa có, hãy đọc về các mẫu thiết kế - bạn có thể sẽ nhận ra rằng bạn đã thấy các mẫu bạn đã đọc, nhưng đặt tên cho chúng sẽ cho phép bạn nhìn thấy không chỉ cây, mà cả chân, cảnh sát, bụi cây, rừng, rừng, rừng, và cuối cùng là rừng.


3

Đây chỉ là một phần của những gì sai với OOP.

Về cơ bản, các chức năng trở thành công dân hạng hai, và điều này là xấu.

Các ngôn ngữ hiện đại (ruby / python) không gặp phải vấn đề này và cung cấp các chức năng như các đối tượng hạng nhất, cũng như cho phép bạn tạo chương trình mà không cần xây dựng bất kỳ phân cấp lớp nào.


OOP có vẻ rất tự nhiên đối với tôi, thật ra tôi rất khó nghĩ về các nhiệm vụ lập trình theo bất kỳ cách nào khác. Tuy nhiên, trong nhiều năm tôi đã hiểu rằng OOP có xu hướng quá tập trung vào danh từ hơn các động từ. Câu nói hay này từ năm 2006 đã giúp tôi hiểu được sự khác biệt này: steve-yegge.blogspot.com/2006/03/ mẹo
Jim Tại Texas

3

OOP không khó. Điều gây khó khăn cho việc sử dụng tốt là sự hiểu biết nông cạn về những gì nó tốt, nơi các lập trình viên nghe những câu châm ngôn ngẫu nhiên, và lặp lại chúng trong hơi thở của họ để nhận được phước lành của Gang of Four thần thánh, Martin Fowler, hay bất cứ ai khác họ đã đọc.


3

EDITED

Trước hết tôi muốn nói rằng tôi chưa bao giờ thấy OOP khó, hay khó hơn các mô hình lập trình khác. Lập trình vốn đã khó vì nó cố gắng giải quyết các vấn đề từ thế giới thực và thế giới thực là vô cùng phức tạp. Mặt khác, khi tôi đọc câu hỏi này, tôi đã tự hỏi: OOP có "tự nhiên" hơn các mô hình khác không? Và do đó hiệu quả hơn?

Tôi đã từng tìm thấy một bài viết (tôi ước tôi có thể tìm lại nó để tôi có thể đăng nó như một tài liệu tham khảo) về một nghiên cứu so sánh giữa lập trình mệnh lệnh (IP) và lập trình hướng đối tượng (OOP). Về cơ bản họ đã đo năng suất của các lập trình viên chuyên nghiệp sử dụng IP và OOP trong các dự án khác nhau và kết quả là họ đã không thấy sự khác biệt lớn. Vì vậy, tuyên bố là không có sự khác biệt lớn về năng suất giữa hai nhóm và điều thực sự quan trọng là kinh nghiệm.

Mặt khác, những người đề xuất tuyên bố hướng đối tượng rằng, trong khi trong quá trình phát triển ban đầu, hệ thống OOP thậm chí có thể mất nhiều thời gian hơn bắt buộc, về lâu dài, mã dễ duy trì và mở rộng hơn do sự tích hợp chặt chẽ giữa dữ liệu và hoạt động.

Tôi đã làm việc chủ yếu với các ngôn ngữ OOP (C ++, Java) nhưng tôi thường có cảm giác rằng tôi có thể làm việc hiệu quả khi sử dụng Pascal hoặc Ada mặc dù tôi chưa bao giờ thử chúng cho các dự án lớn.

Ngược lại với OOP nơi đầu tiên bạn phải tìm một đối tượng (danh từ) và bảo nó thực hiện một số hành động trên một đối tượng khác.

[cắt]

Do đó, tôi sẽ lập luận rằng cách làm chủ đạo của OOP (dựa trên lớp, gửi đơn) là khó bởi vì nó KHÔNG CHÍNH THỨC và không tương ứng với cách con người nghĩ về thế giới. Các phương pháp chung từ CLOS gần với cách suy nghĩ của tôi hơn, nhưng, than ôi, đây không phải là cách tiếp cận rộng rãi.

Khi tôi đọc đoạn cuối này cẩn thận hơn, cuối cùng tôi đã hiểu được ý chính của câu hỏi của bạn và tôi phải viết lại câu trả lời của mình từ đầu. :-)

Tôi biết về các đề xuất OO khác trong đó nhiều đối tượng nhận được một tin nhắn thay vì chỉ một, tức là một số đối tượng đóng vai trò đối xứng khi nhận được tin nhắn. CÓ, đây có vẻ là một cách tiếp cận OOP tổng quát hơn và có thể tự nhiên hơn (ít hạn chế hơn) đối với tôi.

Mặt khác, "nhiều công văn" có thể được mô phỏng dễ dàng bằng cách sử dụng "công văn đơn" và "công văn đơn" dễ thực hiện hơn. Có lẽ đây là một lý do tại sao "nhiều công văn" không trở thành xu hướng.


3

Ngừng tìm kiếm một mô hình OOP độc quyền và thử một số JavaScript.

Tôi hiện đang có một cái gì đó của một lược đồ hoạt động trong đó các đối tượng UI của tôi đang hoạt động trong một giao diện hướng sự kiện. Điều đó có nghĩa là, tôi sẽ có những gì trông giống như một phương thức công khai điển hình mà khi bị sa thải sẽ dẫn đến một hành động được xác định nội bộ. Nhưng khi nó được kích hoạt, điều thực sự xảy ra là tôi kích hoạt một sự kiện trên chính đối tượng và một trình xử lý được xác định trước bên trong đối tượng đó phản hồi. Sự kiện này và đối tượng sự kiện mà bạn có thể đính kèm các thuộc tính được truyền cho bất kỳ người nghe nào khác có thể được nghe bởi bất cứ điều gì quan tâm lắng nghe. Bạn có thể nghe trực tiếp đối tượng hoặc bạn có thể nghe nói chung cho loại sự kiện đó (các sự kiện cũng được kích hoạt trên một đối tượng chung mà tất cả các đối tượng được xây dựng bởi nhà máy đều có thể nghe). Vì vậy, bây giờ, ví dụ, tôi đã có một hộp tổ hợp nơi bạn chọn một mục mới từ danh sách thả xuống.

Nếu bạn muốn, (và tôi đã ngạc nhiên khi phát hiện ra rằng tôi thường không muốn - đó là vấn đề rõ ràng khi bạn không thể thấy sự kiện đến từ đâu), bạn có thể tách đối tượng hoàn chỉnh và thiết lập bối cảnh thông qua một đối tượng sự kiện đã qua. Bất kể, bạn vẫn né tránh một lần gửi bằng cách có thể đăng ký nhiều người trả lời.

Nhưng tôi không làm điều này với OOP một mình và JS thậm chí không 'đúng' OOP theo một số định nghĩa, điều mà tôi thấy buồn cười. Theo quan điểm của tôi, đối với các cấp độ phát triển ứng dụng cao hơn, có khả năng bẻ cong mô hình thành bất cứ điều gì phù hợp với tình huống của bạn và chúng tôi có thể mô phỏng các lớp học tốt nếu chúng ta quan tâm. Nhưng trong trường hợp này, tôi đang trộn các khía cạnh của chức năng (chuyển các trình xử lý xung quanh) với OOP.

Quan trọng hơn, những gì tôi đã cảm thấy khá mạnh mẽ. Tôi không nghĩ về một đối tượng hành động trên một đối tượng khác. Về cơ bản, tôi quyết định những gì các đối tượng quan tâm, cung cấp cho họ các công cụ họ cần để sắp xếp mọi thứ và chỉ cần thả chúng vào một máy trộn và để chúng phản ứng với nhau.

Vì vậy, tôi đoán những gì tôi đang nói là: đây không phải là vấn đề. Đó là sự pha trộn và kết hợp. Vấn đề là ngôn ngữ và mốt muốn bạn tin rằng đó là một điều uber alles. Ví dụ, làm thế nào một nhà phát triển java cơ sở có thể thực sự đánh giá cao OOP khi họ nghĩ rằng họ luôn luôn làm đúng theo mặc định?


2

Cách nó được giải thích với tôi là với máy nướng bánh mì và xe hơi. Cả hai đều có lò xo, vì vậy bạn có một vật thể "lò xo" và chúng có kích thước, sức mạnh và bất cứ thứ gì khác nhau, nhưng cả hai đều là "lò xo" và sau đó kéo dài phép ẩn dụ đó lên xe, là bạn có rất nhiều bánh xe (Bánh xe, rõ ràng, cộng với tay lái, ect) và điều đó rất có ý nghĩa.

Sau đó, bạn có thể nghĩ chương trình là một danh sách các đối tượng và đơn giản hơn rất nhiều để hình dung ra "Đây là danh sách những thứ làm công cụ, vì vậy nó không giống như danh sách các hướng dẫn bạn đã thấy trước đây"

Tôi nghĩ vấn đề thực sự với OOP là cách giải thích với mọi người. Thông thường (trong các lớp uni của tôi) tôi thấy nó được giải thích bằng cách nói "đó là về rất nhiều lớp làm những việc nhỏ và bạn có thể tạo ra các đối tượng từ đó" và tất cả đều khiến nhiều người nhầm lẫn, bởi vì nó sử dụng những gì cơ bản là trừu tượng các thuật ngữ để giải thích các khái niệm này, thay vào đó là những ý tưởng cụ thể mà mọi người đã nắm bắt khi họ 5 tuổi chơi với lego.


2
Lò xo có hàng triệu dạng, tất cả đều thực hiện các chức năng tương tự nhau . Tôi muốn nói rằng đây là một ví dụ hoàn hảo cho lập trình chức năng.
l0b0

2

Đó là cách tự nhiên để nghĩ về thế giới thông qua phân loại. Đó là ít nhiều những gì OO nói về. OOP khó vì lập trình khó.


Nhưng bạn có phân loại theo liệu một số đối tượng có thuộc tính chung hoặc hành vi chung không? Là tất cả mọi thứ có tên và họ của một người? Là tất cả mọi thứ mà đi một con vật?
zvrba

Khi nói đến phân loại, có thể thực hiện một hành vi nhất định là một thuộc tính. Ngựa vằn và ngựa có thể sinh sản, nhưng con cái là con lai. Rất khó dự đoán kết quả này dựa trên việc sở hữu chức năng giao phối trừ khi bạn biết chúng không cùng loài.
JeffO

1
@zvrba: Câu trả lời của tôi cho câu hỏi được đặt ra trong bình luận là vậy it doesn't matter. Tất cả mọi thứ có tên và họ đều là một người cho mọi chương trình chỉ quan tâm đến mọi người. Đối với bất kỳ chương trình nào không có kiến ​​thức về người hoặc không phải người, đó là một IHasNameAndSurname. Đối tượng chỉ cần giải quyết vấn đề trong tầm tay.
Tom W

@Jeff O Ngay cả trong cùng một loài / giống / quần thể cũng có biến thể và không có ví dụ lý tưởng (thiết yếu). Vì vậy, vâng, OO không giống như tự nhiên, nhưng nó phù hợp với cách suy nghĩ của con người.
Tom Hawtin - tackline

2

Tôi nghĩ rằng một số khó khăn xuất hiện khi mọi người cố gắng sử dụng OOP để đại diện cho thực tế. Mọi người đều biết rằng một chiếc xe có bốn bánh và động cơ. Mọi người đều biết rằng xe hơi có thể Start(), Move()SoundHorn().

Một ánh sáng nhấp vào trong đầu tôi khi tôi nhận ra rằng tôi nên ngừng cố gắng làm điều này mọi lúc. Một đối tượng không phải là thứ mà nó chia sẻ tên. Một đối tượng là (nghĩa là phải) một phân vùng dữ liệu đủ chi tiết có liên quan đến phạm vi của vấn đề. Nó oughtcó chính xác những gì giải pháp cho vấn đề cần nó có, không hơn không kém. Nếu làm cho một đối tượng chịu trách nhiệm cho một số hành vi dẫn đến nhiều dòng mã hơn so với hành vi tương tự là công việc của một bên thứ ba mơ hồ nào đó (một số người có thể gọi đó là 'kẻ kiểm soát') thì nhà kiểm soát kiếm được chip của mình.


1

Để quản lý sự phức tạp, chúng ta cần nhóm chức năng thành các mô-đun và đây là một vấn đề khó khăn nói chung. Giống như câu nói cũ về chủ nghĩa tư bản, OOP là hệ thống tồi tệ nhất để tổ chức phần mềm ngoài đó, ngoại trừ mọi thứ khác mà chúng tôi đã thử.

Lý do chúng ta nhóm các tương tác bên trong các danh từ, mặc dù thường có sự mơ hồ về việc hai danh từ đó nhóm với nó, là số lượng danh từ xảy ra với các lớp có kích thước có thể quản lý được, trong khi việc nhóm các động từ có xu hướng tạo ra các nhóm rất nhỏ như một lần hoặc các nhóm rất lớn cho một chức năng như hiển thị . Tái sử dụng các khái niệm như thừa kế cũng xảy ra để làm việc dễ dàng hơn nhiều khi nhóm theo danh từ.

Ngoài ra, câu hỏi về việc quyết định nên đặt chương trình với cửa sổ hay văn bản hầu như luôn rõ ràng hơn nhiều trong thực tế so với lý thuyết. Ví dụ: gần như tất cả các nhóm công cụ GUI thêm vào vùng chứa, nhưng hiển thị với tiện ích con. Nếu bạn cố gắng viết mã theo cách khác, lý do trở nên rõ ràng khá nhanh chóng, mặc dù suy nghĩ về nó một cách trừu tượng, hai phương pháp dường như có thể thay thế cho nhau.


2
Bạn đã bao giờ nhìn thấy một hệ thống mô-đun thích hợp ? Làm thế nào bạn có thể nói rằng OOP là điều tốt nhất có sẵn? Các mô-đun SML là rất nhiều, mạnh mẽ hơn nhiều. Nhưng, ngay cả các gói Ada cũng đủ cho hầu hết các trường hợp, ngay cả khi không có một gợi ý nhỏ nào về OOP.
SK-logic

@ SK-logic, tôi nghĩ rằng bạn đang bị treo lên với các định nghĩa quá chính xác. Theo OOP, tôi không có nghĩa là các lớp , tôi có nghĩa là nhóm các "động từ" một cách hợp lý bởi các "danh từ" mà chúng hoạt động và có thể sử dụng lại và chuyên môn hóa các động từ đó dựa trên các danh từ cụ thể mà chúng đang hoạt động. Các lớp xảy ra là triển khai nổi tiếng nhất về điều đó, nhưng không phải là triển khai duy nhất . Tôi thừa nhận sự thiếu hiểu biết về các mô-đun SML, nhưng ví dụ đầu tiên tôi thấy khi tôi tra cứu nó là việc thực hiện một hàng đợi có thể đến từ bất kỳ cuốn sách thiết kế OO nào với các thay đổi cú pháp để làm cho nó hoạt động.
Karl Bielefeldt

đơn giản là sẽ không công bằng khi cung cấp cho một OOP đáng tiếc quá nhiều tín dụng cho một thứ không thuộc về nó. Các mô-đun là một phát minh tuyệt vời. Các mô-đun hạng nhất là tuyệt vời. Nhưng OOP không có gì để làm với họ cả. Một số ngôn ngữ OOP đã thông qua một số tính năng của mô-đun (đáng chú ý nhất là không gian tên), nhưng các mô-đun là khái niệm tổng quát và mạnh mẽ hơn nhiều so với các lớp. Bạn nói rằng các lớp học là "tốt nhất", khác xa với sự thật. Các mô-đun hạng nhất là tốt hơn nhiều. Và, tất nhiên, các hệ thống loại rộng hơn và sâu hơn nhiều so với chỉ một OO với kiểu phụ của nó.
SK-logic

1
"Giống như câu nói cũ về chủ nghĩa tư bản, OOP là hệ thống tồi tệ nhất để tổ chức phần mềm ngoài đó, ngoại trừ mọi thứ khác mà chúng tôi đã thử.": Có lẽ chúng tôi đã không cố gắng đủ lâu. :-)
Giorgio

1
Tôi nghĩ bạn có nghĩa là 'dân chủ': trích
dẫnpage.com / câu hỏi / 4.html

1

Không . Có một số cách để giải quyết vấn đề bằng cách sử dụng Lập trình: chức năng, Thủ tục, logic, OOP, khác.

Trong thế giới thực, đôi khi, mọi người sử dụng mô hình chức năng, và đôi khi, chúng tôi sử dụng mô hình thủ tục, v.v. Và đôi khi chúng tôi trộn lẫn. Và cuối cùng chúng tôi đại diện cho họ như một phong cách cụ thể hoặc mô hình lập trình.

Ngoài ra còn có mô hình "mọi thứ là danh sách hoặc vật phẩm", được sử dụng trong LISP. Tôi muốn đề cập đến như là một điều khác với lập trình chức năng . PHP sử dụng điều đó trong các mảng kết hợp.

Các mô hình OOP và "Mọi thứ là một danh sách hoặc vật phẩm" được xem xét 2 trong số các kiểu lập trình TỰ NHIÊN HƠN , như tôi nhớ trong một số lớp Trí tuệ nhân tạo.

Nghe có vẻ lạ, "OOP không tự nhiên", có thể cách bạn học hoặc cách bạn được dạy về OOP là sai, nhưng bản thân OOP thì không.


1

Với những vấn đề này, làm thế nào / tại sao nó lại xảy ra mà cách làm OOP hiện nay trở nên phổ biến? Và những gì, nếu có, có thể được thực hiện để truất ngôi nó?

OOP trở nên phổ biến vì nó cung cấp các công cụ để tổ chức chương trình của bạn ở mức độ trừu tượng cao hơn các ngôn ngữ thủ tục phổ biến đi trước nó. Nó cũng tương đối dễ dàng để tạo ra một ngôn ngữ có cấu trúc thủ tục bên trong các phương thức và cấu trúc hướng đối tượng xung quanh chúng. Điều này cho phép các lập trình viên đã biết cách lập trình thủ tục chọn từng nguyên tắc OO. Điều này cũng dẫn đến rất nhiều chương trình chỉ có tên OO là các chương trình thủ tục được gói trong một hoặc hai lớp.

Để truất ngôi OO, hãy xây dựng một ngôn ngữ giúp bạn dễ dàng chuyển đổi dần dần từ những gì hầu hết các lập trình viên biết ngày nay (chủ yếu là thủ tục, với một chút OO,) sang mô hình ưa thích của bạn. Hãy chắc chắn rằng nó cung cấp các API thuận tiện để thực hiện các tác vụ phổ biến và quảng bá nó tốt. Mọi người sẽ sớm thực hiện các chương trình chỉ có tên X bằng ngôn ngữ của bạn. Sau đó, bạn có thể mong đợi phải mất nhiều năm và nhiều năm để mọi người có thể thực sự làm X.


OP không cho rằng OO nói chung là xấu và nên bị truất ngôi nhưng "cách làm OOP hiện tại" không phải là cách tự nhiên nhất (so với "nhiều công văn").
Giorgio

OP dường như cũng tập trung quá mức vào việc xác định hệ thống phân cấp loại, trong đó các chương trình OO tốt nhất có xu hướng phụ thuộc nhiều hơn vào giao diện và thành phần. Nếu Nhiều công văn là X, thì việc tạo một ngôn ngữ cho phép mọi người dần dần học các kỹ năng liên quan đến nhiều công văn vẫn là chìa khóa để thay đổi môi trường.
Sean McMillan

1

Tôi nghĩ rằng ngôn ngữ OOP và OOP cũng có vấn đề.

Nếu hiểu chính xác, OOP là về các hộp đen (đối tượng) có các nút ấn trên chúng có thể được đẩy (phương thức). Các lớp học chỉ ở đó để giúp tổ chức các hộp đen này.

Một vấn đề là khi lập trình viên đặt các nút ấn vào đối tượng sai. Thiết bị đầu cuối không thể hiển thị văn bản trên chính nó, văn bản không thể hiển thị trên thiết bị đầu cuối. Thành phần quản lý cửa sổ của hệ điều hành có thể làm điều đó. Cửa sổ đầu cuối và văn bản chỉ là một thực thể thụ động. Nhưng nếu chúng ta nghĩ theo cách này, chúng ta nhận ra hầu hết các thực thể là những thứ thụ động và chúng ta sẽ chỉ có một vài đối tượng thực sự làm bất cứ điều gì (hoặc đơn giản là một: máy tính ). Thật vậy, khi bạn sử dụng C, bạn sắp xếp nó thành các mô-đun, các mô-đun này đại diện cho một vài đối tượng.

Một điểm khác là máy tính chỉ thực hiện các hướng dẫn tuần tự. Giả sử bạn có một VCRvà một Televisionđối tượng, bạn sẽ phát video như thế nào? Bạn có thể viết một cái gì đó như thế này:

connect(television, vcr);
vcr.turnOn();
television.turnOn();
insert(vcr, yourFavoriteCasette);
vcr.play();
while (vcr.isPlaying()) {} // Wait while the VCR is playing the casette.
vcr.eject();
vcr.turnOff();
television.turnOff();

Điều này sẽ đơn giản, nhưng bạn sẽ cần ít nhất 3 bộ xử lý ( hoặc các quy trình ) cho điều đó: một đóng vai trò của bạn, thứ hai là VCR, thứ ba là TV. Nhưng thông thường bạn chỉ có một lõi (ít nhất là không đủ cho tất cả các đối tượng của bạn). Ở trường đại học, nhiều bạn cùng lớp của tôi không hiểu tại sao GUI đóng băng khi một nút ấn thực hiện một thao tác đắt tiền.

Vì vậy, tôi nghĩ rằng một thiết kế hướng đối tượng có thể mô tả thế giới khá tốt, nhưng nó không phải là sự trừu tượng tốt nhất cho máy tính.


0

Hãy xem DCI (dữ liệu, bối cảnh và tương tác) được phát minh bởi người phát minh ra mẫu MVC.

Mục tiêu của DCI là (trích từ Wikipedia):

  • Cho hành vi hệ thống trạng thái hạng nhất, trên các đối tượng (danh từ).
  • Để tách mã một cách sạch sẽ để thay đổi nhanh chóng hành vi hệ thống (những gì hệ thống làm) khỏi mã để thay đổi kiến ​​thức miền chậm (hệ thống là gì), thay vì kết hợp cả hai trong một giao diện lớp.
  • Để hỗ trợ một kiểu suy nghĩ đối tượng gần với mô hình tinh thần của mọi người, hơn là kiểu tư duy giai cấp.

Đây là một bài viết hay của các tác giả và đây là một ví dụ nhỏ triển khai (.NET) nếu bạn muốn xem một số mã. Nó đơn giản hơn nhiều so với âm thanh và cảm thấy rất tự nhiên.


0

Người ta thường có thể nghe rằng OOP tự nhiên tương ứng với cách mọi người nghĩ về thế giới. Nhưng tôi hoàn toàn không đồng ý với tuyên bố này (...)

Vì nó được truyền giáo trong sách và những nơi khác trong nhiều thập kỷ, tôi cũng không đồng ý với nó. Tuy nhiên, tôi nghĩ Nygaard và Dahl là những người đưa ra như vậy và tôi nghĩ họ đang tập trung vào việc nghĩ về việc thiết kế mô phỏng dễ dàng hơn so với các lựa chọn thay thế thời đó.

(...) Nhưng trọng tâm của OOP là thiết kế các lớp riêng lẻ và phân cấp của chúng.

Khẳng định này đi vào lãnh thổ hợp lý dựa trên mức độ hiểu lầm phổ biến về OOP và mức độ nhạy cảm của OO đối với định nghĩa. Tôi có hơn mười năm trong lĩnh vực này, làm cả công việc trong ngành và nghiên cứu học thuật về prog. ngôn ngữ và tôi có thể nói với bạn rằng tôi đã dành nhiều năm để không học "OO chính thống" bởi vì tôi bắt đầu nhận thấy sự khác biệt (và kém hơn) của nó so với những gì mà những người sáng tạo trước đó đang nhắm đến. Đối với một điều trị hiện đại, cập nhật về chủ đề tôi sẽ đề cập đến nỗ lực gần đây của W. Cook:

"Đề xuất cho các định nghĩa hiện đại, đơn giản về" Đối tượng "và" Hướng đối tượng " http://wcook.blogspot.com.br/2012/07/proposed-for-simplified-modern.html

Với những vấn đề này, làm thế nào / tại sao nó lại xảy ra mà cách làm OOP hiện nay trở nên phổ biến?

Có thể cùng một lý do bàn phím QWERTY trở nên phổ biến hoặc cùng lý do hệ điều hành DOS trở nên phổ biến. Mọi thứ chỉ có một chuyến đi trên các phương tiện phổ biến, bất chấp tài sản của họ, và trở nên phổ biến. Và đôi khi, các phiên bản tương tự nhưng tồi tệ hơn của một cái gì đó được coi là thực tế.

Và những gì, nếu có, có thể được thực hiện để truất ngôi nó?

Viết chương trình sử dụng phương pháp ưu việt. Viết chương trình tương tự bằng cách sử dụng phương pháp OO. Hiển thị cái trước có các thuộc tính tốt hơn cái sau ở mọi khía cạnh quan trọng (cả thuộc tính của chính hệ thống và thuộc tính kỹ thuật). Cho thấy rằng chương trình được chọn là phù hợp và phương pháp đề xuất duy trì chất lượng cao của các thuộc tính nếu áp dụng cho các loại chương trình khác. Hãy nghiêm ngặt trong phân tích của bạn và sử dụng các định nghĩa chính xác và được chấp nhận khi cần thiết.

Cuối cùng, chia sẻ những phát hiện của bạn với chúng tôi.


-1

Lấy Java: các đối tượng là một loại tắc nghẽn trừu tượng, hầu hết các "thứ" đều là các thành phần phụ của các đối tượng hoặc sử dụng các đối tượng làm các thành phần phụ của chúng. Các đối tượng phải đủ đa mục đích cho toàn bộ một lớp trừu tượng giữa hai loại sự vật này - mục đích đột biến có nghĩa là không có một phép ẩn dụ nào mà chúng thể hiện. Cụ thể Java làm cho các đối tượng (& lớp) trở thành lớp duy nhất mà qua đó bạn gọi / gửi mã. Số lượng vật này hiện thân làm cho chúng, thật lòng mà nói, quá phức tạp. Bất kỳ mô tả hữu ích nào về chúng phải được giới hạn ở một số dạng chuyên biệt hoặc bị hạn chế.

Hệ thống phân cấp kế thừa và giao diện là "những thứ" sử dụng các đối tượng làm thành phần phụ. Đây là một cách chuyên biệt để mô tả các đối tượng, không phải là một cách để có được sự hiểu biết chung về các đối tượng.

"Các đối tượng" có thể được cho là có hoặc có nhiều thứ bởi vì chúng là một sự trừu tượng hóa đa mục đích ít nhiều phổ biến trong một "OO Langauge". Nếu chúng được sử dụng để chứa trạng thái đột biến cục bộ hoặc truy cập một số trạng thái thế giới bên ngoài thì chúng trông rất giống một "danh từ".

Ngược lại, một đối tượng đại diện cho một quá trình, ví dụ "mã hóa" hoặc "nén" hoặc "sắp xếp", trông giống như một "động từ".

Một số đối tượng được sử dụng cho vai trò của chúng như một không gian tên, ví dụ như một vị trí để đặt hàm "tĩnh" trong Java.

Tôi có khuynh hướng đồng ý với lập luận rằng Java quá nặng về các cuộc gọi phương thức đối tượng, với việc gửi đi đối tượng. Điều này có lẽ là vì tôi thích các lớp loại của Haskell để kiểm soát công văn. Đây là một giới hạn công văn và là một tính năng của Java nhưng không phải hầu hết các ngôn ngữ, hoặc thậm chí hầu hết các ngôn ngữ OO.


-3

Tôi đã chứng kiến ​​và tham gia nhiều cuộc tranh luận trực tuyến về OOP. Những người đề xuất OOP thường không biết cách viết mã thủ tục thích hợp. Có thể viết mã thủ tục có tính mô-đun cao. Có thể tách mã và dữ liệu và đảm bảo rằng các chức năng chỉ có thể ghi vào kho lưu trữ dữ liệu của riêng họ. Có thể thực hiện khái niệm thừa kế bằng mã thủ tục. Quan trọng hơn, mã thủ tục mỏng hơn, nhanh hơn và dễ gỡ lỗi hơn.

Nếu bạn xây dựng các mô-đun một tệp với các quy ước đặt tên nghiêm ngặt, mã thủ tục sẽ dễ viết và duy trì hơn OO và nó sẽ làm tương tự hoặc nhiều hơn và nhanh hơn. Và đừng quên rằng khi ứng dụng của bạn chạy, nó luôn mang tính thủ tục cho dù có bao nhiêu lớp trong tập lệnh của bạn.

Sau đó, bạn có vấn đề về các ngôn ngữ như PHP, vốn không thực sự hướng đối tượng và dựa vào các bản hack cho các công cụ giả mạo như nhiều kế thừa. Những bức ảnh lớn ảnh hưởng đến hướng của ngôn ngữ đã biến PHP thành một sự chắp vá của các quy tắc không nhất quán đã trở nên quá lớn so với những gì nó dự định ban đầu. Khi tôi thấy các nhà phát triển viết các lớp tạo khuôn mẫu lớn cho những gì được dự định là ngôn ngữ tạo khuôn mẫu theo thủ tục, tôi không thể không mỉm cười.

Nếu bạn so sánh mã OO được viết đúng với mã thủ tục được viết kém, thì bạn sẽ luôn đi đến kết luận sai. Rất ít dự án đảm bảo một thiết kế hướng đối tượng. Nếu bạn là IBM và quản lý một dự án lớn cần được duy trì trong nhiều năm bởi nhiều nhà phát triển, hãy tìm kiếm Hướng đối tượng. Nếu bạn đang viết một blog nhỏ hoặc trang web mua sắm cho khách hàng, hãy suy nghĩ kỹ.

Để trả lời câu hỏi ban đầu, OOP rất khó vì nó không giải quyết được các tình huống khó xử trong lập trình thực mà không dùng đến các giải pháp phức tạp hơn 100 lần so với chúng. Một trong những giải pháp mạnh mẽ nhất cho nhiều vấn đề lập trình là việc sử dụng dữ liệu toàn cầu một cách hợp lý. Tuy nhiên, các sinh viên tốt nghiệp đại học làn sóng mới sẽ nói với bạn rằng đó là một điều không nên. Dữ liệu toàn cầu chỉ nguy hiểm nếu bạn là một chú thỏ lập trình vụng về. Nếu bạn có một bộ quy tắc nghiêm ngặt và các quy ước đặt tên thích hợp, bạn có thể thoát khỏi việc có tất cả dữ liệu của mình trên toàn cầu.

Nó phải là một yêu cầu bắt buộc đối với bất kỳ lập trình viên hướng đối tượng nào để biết cách viết một ứng dụng chơi cờ trong trình biên dịch để có bộ nhớ tối đa 16K. Sau đó, họ sẽ học cách cắt giảm chất béo, cắt giảm sự lười biếng và tạo ra các giải pháp khéo léo.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.