Tại sao OOP khó khăn? [đóng cửa]

Khi tôi bắt đầu sử dụng ngôn ngữ hướng đối tượng (Java), tôi gần như đã đi "Tuyệt vời" và bắt đầu viết mã. Tôi chưa bao giờ thực sự nghĩ về nó cho đến gần đây sau khi đọc rất nhiều câu hỏi về OOP. Ấn tượng chung tôi nhận được là mọi người đấu tranh với nó. Vì tôi không nghĩ nó khó, và tôi sẽ không nói tôi là thiên tài, tôi nghĩ rằng tôi đã bỏ lỡ điều gì đó hoặc hiểu lầm về nó.

Tại sao OOP khó hiểu? Có khó hiểu không?

Cá nhân tôi thấy các cơ chế của OOP khá dễ nắm bắt. Phần khó đối với tôi là "tại sao" của nó. Khi tôi lần đầu tiên tiếp xúc với nó, nó có vẻ như là một giải pháp để tìm kiếm một vấn đề. Dưới đây là một vài lý do tại sao tôi nghĩ rằng hầu hết mọi người cảm thấy khó khăn:

1. IMHO dạy OO ngay từ đầu là một ý tưởng tồi tệ. Mã hóa thủ tục không phải là "thói quen xấu" và là công cụ phù hợp cho một số công việc. Dù sao đi nữa, các phương thức riêng lẻ trong một chương trình OO thường có vẻ khá thủ tục. Hơn nữa, trước khi học lập trình thủ tục đủ tốt để các giới hạn của nó được hiển thị, OO dường như không hữu ích cho học sinh.

2. Trước khi bạn thực sự có thể nắm bắt OO, bạn cần biết những điều cơ bản về cấu trúc dữ liệu và các hàm liên kết muộn / bậc cao hơn. Thật khó để hiểu được tính đa hình (về cơ bản là truyền xung quanh một con trỏ tới dữ liệu và một loạt các hàm hoạt động trên dữ liệu) nếu bạn thậm chí không hiểu các khái niệm về cấu trúc dữ liệu thay vì chỉ sử dụng các hàm nguyên thủy và chuyển qua các hàm bậc cao hơn / con trỏ đến các chức năng.

3. Các mẫu thiết kế nên được dạy như một cái gì đó cơ bản cho OO, không phải là thứ gì đó cao cấp hơn. Các mẫu thiết kế giúp bạn nhìn thấy khu rừng xuyên qua rừng và đưa ra các ví dụ tương đối cụ thể về nơi OO có thể đơn giản hóa các vấn đề thực sự và cuối cùng bạn sẽ muốn tìm hiểu chúng. Hơn nữa, một khi bạn thực sự có được OO, hầu hết các mẫu thiết kế trở nên rõ ràng trong nhận thức muộn màng.

Tôi nghĩ rằng có một vài yếu tố chưa được đề cập.

Trước hết, ít nhất là trong "OOP thuần túy" (ví dụ, Smalltalk) trong đó mọi thứ đều là một đối tượng, bạn phải xoay chuyển tâm trí của mình thành một cấu hình khá không tự nhiên để nghĩ về một số (chỉ một ví dụ) như một đối tượng thông minh thay vì chỉ là một giá trị - vì trong thực tế, 21(ví dụ) thực sự là chỉ là một giá trị. Điều này trở nên đặc biệt khó khăn khi một mặt bạn nói rằng một lợi thế lớn của OOP là mô hình hóa thực tế chặt chẽ hơn, nhưng bạn bắt đầu bằng cách nhìn những gì trông rất khủng khiếp như một quan điểm lấy cảm hứng từ LSD về những phần cơ bản và rõ ràng nhất của thực tế.

Thứ hai, thừa kế trong OOP cũng không theo sát hầu hết các mô hình tinh thần của mọi người. Đối với hầu hết mọi người, việc phân loại những thứ cụ thể nhất không có bất kỳ nơi nào gần với các quy tắc tuyệt đối cần thiết để tạo một hệ thống phân cấp lớp hoạt động. Cụ thể, tạo ra một class Dkế thừa từ một class Bphương tiện khác có nghĩa là các đối tượng class Dchia sẻ hoàn toàn, tích cực tất cả các đặc điểm của class B. class Dcó thể thêm các đặc điểm mới và khác nhau của riêng nó, nhưng tất cả các đặc điểm class Bphải còn nguyên vẹn.

Ngược lại, khi mọi người phân loại mọi thứ về mặt tinh thần, họ thường theo mô hình lỏng lẻo hơn nhiều. Ví dụ, nếu một người đưa ra một số quy tắc về những gì cấu thành một lớp đối tượng, thì khá điển hình là hầu như bất kỳ quy tắc nào cũng có thể bị phá vỡ miễn là tuân theo đủ các quy tắc khác. Ngay cả một vài quy tắc không thể thực sự bị phá vỡ hầu như luôn có thể được "kéo dài" một chút.

Ví dụ, coi "xe hơi" là một lớp học. Đó là khá dễ dàng để thấy rằng rộng lớn đa số những gì hầu hết mọi người nghĩ là "xe hơi" có bốn bánh xe. Tuy nhiên, hầu hết mọi người đã nhìn thấy (ít nhất là một hình ảnh) một chiếc xe chỉ có ba bánh. Một số người trong chúng ta ở độ tuổi phù hợp cũng nhớ một hoặc hai chiếc xe đua từ đầu thập niên 80 (hoặc hơn) có sáu bánh xe - vân vân. Điều này cho chúng ta cơ bản ba lựa chọn:

1. Đừng khẳng định bất cứ điều gì về việc một chiếc xe có bao nhiêu bánh xe - nhưng điều này có xu hướng dẫn đến giả định ngầm định rằng nó sẽ luôn là 4 và mã có khả năng bị phá vỡ cho một số khác.
2. Khẳng định rằng tất cả các xe đều có bốn bánh và chỉ phân loại những xe khác là "không phải xe" mặc dù chúng tôi biết chúng thực sự là như vậy.
3. Thiết kế lớp để cho phép thay đổi số lượng bánh xe, chỉ trong trường hợp, mặc dù rất có khả năng khả năng này sẽ không bao giờ cần thiết, được sử dụng hoặc được kiểm tra đúng cách.

Dạy về OOP thường tập trung vào việc xây dựng các nguyên tắc phân loại khổng lồ - ví dụ, các mẩu và phần của thứ sẽ là một hệ thống phân cấp khổng lồ của tất cả sự sống đã biết trên trái đất, hoặc một cái gì đó theo thứ tự đó. Điều này đặt ra hai vấn đề: đầu tiên và quan trọng nhất, nó có xu hướng khiến nhiều người hướng tới việc tập trung vào một lượng lớn thông tin hoàn toàn không liên quan đến câu hỏi trong tay. Tại một thời điểm, tôi đã thấy một cuộc thảo luận khá dài về cách mô hình các giống chó, và liệu (ví dụ) "poodle thu nhỏ" có nên thừa hưởng từ "poodle kích thước đầy đủ" hay ngược lại, hoặc liệu có nên có một cơ sở trừu tượng "Poodle không "đẳng cấp, với" poodle kích thước đầy đủ "và" poodle thu nhỏ "đều được thừa hưởng từ nó. Điều mà tất cả họ dường như bỏ qua là ứng dụng này được cho là để đối phó với việc theo dõi giấy phép cho chó,

Thứ hai, và gần như quan trọng, nó dẫn đến việc tập trung vào các đặc điểm của các vật phẩm, thay vì tập trung vào các đặc điểm quan trọng cho nhiệm vụ trong tay. Nó dẫn đến việc mô hình hóa mọi thứ như hiện tại, trong đó (hầu hết thời gian) những gì thực sự cần thiết là xây dựng mô hình đơn giản nhất sẽ đáp ứng nhu cầu của chúng ta và sử dụng sự trừu tượng để phù hợp với các lớp con cần thiết để phù hợp với sự trừu tượng mà chúng ta đã xây dựng.

Cuối cùng, tôi sẽ nói một lần nữa: chúng ta đang dần đi theo cùng một con đường được cơ sở dữ liệu thực hiện trong nhiều năm. Cơ sở dữ liệu ban đầu theo mô hình phân cấp. Khác với việc tập trung hoàn toàn vào dữ liệu, đây là sự kế thừa duy nhất. Trong một thời gian ngắn, một vài cơ sở dữ liệu theo mô hình mạng - về cơ bản giống với nhiều kế thừa (và nhìn từ góc độ này, nhiều giao diện không đủ khác biệt so với nhiều lớp cơ sở để chú ý hoặc quan tâm).

Tuy nhiên, từ lâu, các cơ sở dữ liệu chủ yếu tập trung vào mô hình quan hệ (và mặc dù chúng không phải là SQL, nhưng ở mức độ trừu tượng này, cơ sở dữ liệu "NoQuery" hiện tại cũng có quan hệ). Những lợi thế của mô hình quan hệ đã được biết rõ rằng tôi sẽ không lặp lại chúng ở đây. Tôi sẽ chỉ lưu ý rằng sự tương tự gần nhất của mô hình quan hệ mà chúng ta có trong lập trình là lập trình chung (và xin lỗi, nhưng mặc dù tên, chung chung Java, chẳng hạn, không thực sự đủ điều kiện, mặc dù chúng là một bước nhỏ trong đúng hướng).

OOP đòi hỏi khả năng suy nghĩ trừu tượng; một món quà / lời nguyền mà ít người, ngay cả các lập trình viên chuyên nghiệp, thực sự có.

Tôi nghĩ bạn có thể tóm tắt những khó khăn cơ bản theo cách này:

// The way most people think.
Operation - object - parameters
// Example:
Turn the car left.

// The way OOP works conceptually
Object - operation - parameters
// Example:
Car.Turn(270);

Chắc chắn, mọi người có thể quen với việc ánh xạ "bên trái" là 270, và vâng, nói "Car.Turn" thay vì "quay xe" không phải là một bước nhảy vọt lớn như vậy. NHƯNG, để đối phó tốt với các đối tượng này và để tạo ra chúng, bạn phải đảo ngược cách bạn thường nghĩ.

Thay vì thao túng một đối tượng, chúng ta đang bảo đối tượng thực sự tự làm mọi việc. Nó có thể không cảm thấy khó khăn nữa, nhưng nói với một cửa sổ để mở chính nó nghe có vẻ kỳ lạ. Những người không quen với lối suy nghĩ này phải đấu tranh với sự kỳ quặc đó nhiều lần cho đến khi cuối cùng nó trở nên tự nhiên.

Bất kỳ mô hình nào cũng đòi hỏi một sự thúc đẩy nhất định "vượt ra ngoài" để nắm bắt, đối với hầu hết mọi người. Theo định nghĩa, đó là một chế độ tư duy mới và do đó, nó đòi hỏi một lượng nhất định buông bỏ những quan niệm cũ và một lượng nhất định nắm bắt hoàn toàn lý do tại sao các khái niệm mới lại hữu ích.

Tôi nghĩ rằng rất nhiều vấn đề là các phương pháp được sử dụng để dạy lập trình máy tính nói chung là khá kém. OOP rất phổ biến hiện nay đến mức nó không đáng chú ý, nhưng bạn vẫn thấy nó thường xuyên trong lập trình chức năng:

• Các khái niệm quan trọng được ẩn đằng sau các tên kỳ lạ (FP: Đơn vị là gì? OOP: Tại sao đôi khi chúng gọi chúng là các hàm và các phương thức khác?)

• Các khái niệm kỳ quặc được giải thích bằng phép ẩn dụ thay vì về những gì họ thực sự làm, hoặc tại sao bạn sử dụng chúng, hoặc tại sao mọi người từng nghĩ sử dụng chúng (FP: Một đơn vị là một không gian, nó bao bọc một số mã. OOP: An Đối tượng giống như một con vịt, nó có thể gây ra tiếng động, đi lại và thừa hưởng từ Động vật)

• những thứ tốt khác nhau tùy theo từng người, vì vậy không rõ ràng đâu sẽ là điểm bùng phát đối với bất kỳ học sinh nào và thường thì giáo viên thậm chí không thể nhớ. (FP: Ồ, các đơn vị cho phép bạn ẩn thứ gì đó trong chính loại đó và tiếp tục sử dụng mà không cần phải viết rõ ràng những gì đang xảy ra mỗi lần. OOP: Ồ, các đối tượng cho phép bạn giữ các chức năng cho một loại dữ liệu với dữ liệu đó.)

Điều tồi tệ nhất của nó là, như câu hỏi chỉ ra, một số người sẽ ngay lập tức hiểu được lý do tại sao khái niệm này tốt và một số thì không. Nó thực sự phụ thuộc vào điểm tới hạn là gì. Đối với tôi, nắm bắt rằng các đối tượng lưu trữ dữ liệu và phương thức cho dữ liệu đó là chìa khóa, sau đó mọi thứ khác chỉ phù hợp như một phần mở rộng tự nhiên. Sau đó, tôi đã nhảy như nhận ra rằng một cuộc gọi phương thức từ một đối tượng rất giống với việc thực hiện một cuộc gọi tĩnh với đối tượng đó làm tham số đầu tiên.

Những bước nhảy nhỏ sau này giúp tinh chỉnh sự hiểu biết, nhưng đó là bước đầu tiên đưa một người từ "OOP không có ý nghĩa, tại sao mọi người lại làm điều này?" thành "OOP là tốt nhất, tại sao mọi người lại làm gì khác?"

Bởi vì lời giải thích cơ bản về OOP có rất ít liên quan đến cách sử dụng nó trong lĩnh vực này. Hầu hết các chương trình để dạy nó đều cố gắng sử dụng một mô hình vật lý, chẳng hạn như "Hãy nghĩ về một chiếc xe như một vật thể, và bánh xe như các vật thể, và các cánh cửa, và truyền tải ...", nhưng bên ngoài một số trường hợp mơ hồ của lập trình mô phỏng, các đối tượng thường được sử dụng nhiều hơn để biểu diễn các khái niệm phi vật lý hoặc để giới thiệu cảm ứng. Hiệu quả là nó khiến mọi người hiểu nó bằng trực giác một cách sai lầm.

Dạy từ các mẫu thiết kế là một cách tốt hơn để mô tả OOP, vì nó cho các lập trình viên thấy một số vấn đề mô hình thực tế có thể bị tấn công hiệu quả với các đối tượng, thay vì mô tả nó một cách trừu tượng.

Tôi không đồng ý với câu trả lời của dsimcha trong hầu hết các phần:

1. Dạy OO ngay từ đầu không thực sự là một ý tưởng tồi trong chính nó, cũng không phải là dạy ngôn ngữ thủ tục. Điều quan trọng là chúng tôi dạy mọi người viết mã rõ ràng, ngắn gọn, gắn kết, bất kể OO hay thủ tục.

2. Các phương pháp riêng lẻ trong các chương trình OO tốt KHÔNG có xu hướng xem xét thủ tục. Điều này ngày càng trở nên đúng với sự phát triển của các ngôn ngữ OO (đọc C # vì khác với C ++ là ngôn ngữ OO duy nhất khác mà tôi biết) và cú pháp của chúng ngày càng phức tạp hơn (lambdas, LINQ cho các đối tượng, v.v.). Điểm giống nhau duy nhất giữa các phương thức và thủ tục OO trong các ngôn ngữ thủ tục là bản chất tuyến tính của mỗi phương thức, điều mà tôi nghi ngờ sẽ thay đổi bất cứ lúc nào sớm.

3. Bạn không thể thành thạo một ngôn ngữ thủ tục mà không hiểu cấu trúc dữ liệu. Khái niệm con trỏ cũng quan trọng đối với các ngôn ngữ thủ tục như đối với các ngôn ngữ OO. Truyền tham số bằng tham chiếu, ví dụ, khá phổ biến trong các ngôn ngữ thủ tục, đòi hỏi bạn phải hiểu con trỏ nhiều như yêu cầu để học bất kỳ ngôn ngữ OO nào.

4. Tôi không nghĩ rằng các mẫu thiết kế nên được dạy sớm trong lập trình OO, bởi vì chúng không phải là nền tảng cho lập trình OO. Một người chắc chắn có thể là một lập trình viên OO giỏi mà không biết gì về các mẫu thiết kế. Trong thực tế, một người thậm chí có thể sử dụng các mẫu thiết kế nổi tiếng mà không hề biết rằng chúng được ghi lại như vậy với tên riêng và các cuốn sách được viết về chúng. Những gì cần được dạy một cách cơ bản là các nguyên tắc thiết kế như Trách nhiệm đơn lẻ, Đóng mở và Phân chia giao diện. Thật không may, nhiều người tự coi mình là lập trình viên OO ngày nay không quen thuộc với khái niệm cơ bản này hoặc chỉ chọn bỏ qua nó và đó là lý do tại sao chúng ta có quá nhiều mã OO rác ngoài kia.

Để trả lời câu hỏi của người đăng ban đầu, vâng, OO là một khái niệm khó hiểu hơn so với lập trình thủ tục. Điều này là do chúng tôi không nghĩ về các tính chất và phương pháp của các đối tượng trong cuộc sống thực. Ví dụ, bộ não con người không dễ dàng nghĩ "TurnOn" là một phương thức của TV, nhưng xem nó như một chức năng của con người khi bật TV. Tương tự như vậy, đa hình là một khái niệm xa lạ với bộ não con người thường nhìn thấy từng đối tượng trong đời thực chỉ bằng một "khuôn mặt". Kế thừa một lần nữa không phải là tự nhiên đối với bộ não của chúng ta. Chỉ vì tôi là một nhà phát triển không có nghĩa là con trai tôi sẽ là một. Nói chung, bộ não con người cần được đào tạo để học OO trong khi các ngôn ngữ thủ tục tự nhiên hơn.

Tôi nghĩ rằng nhiều lập trình viên gặp khó khăn với thiết kế trả trước và lập kế hoạch để bắt đầu. Ngay cả khi ai đó làm tất cả các thiết kế cho bạn, vẫn có thể tách ra khỏi các nguyên tắc OOP. Nếu tôi lấy một loạt mã spaghetti và đổ nó vào một lớp, đó có thực sự là OOP không? Một người không hiểu OOP vẫn có thể lập trình bằng Java. Ngoài ra, đừng nhầm lẫn khó hiểu với việc không sẵn sàng tuân theo một phương pháp nhất định hoặc không đồng ý với nó.

Bạn nên đọc đối tượng Không bao giờ? Vâng, hầu như không bao giờ. (Cần có tư cách thành viên ACM) bởi Mordechai Ben-Ari, người cho rằng OOP rất khó khăn, bởi vì đó không phải là một mô hình thực sự tự nhiên để mô hình hóa bất cứ điều gì. .

Bản thân việc lập trình hướng đối tượng không khó.

Phần khó khăn trong việc làm tốt nó. Nơi để đặt cắt giữa mã để bạn có thể dễ dàng di chuyển mọi thứ đến đối tượng cơ sở chung và mở rộng chúng sau này? Làm thế nào để làm cho mã của bạn có thể được sử dụng bởi những người khác (mở rộng các lớp, bọc proxy, phương thức ghi đè) mà không cần nhảy qua các vòng để làm như vậy.

Đó là phần khó, và nếu được thực hiện đúng có thể rất thanh lịch, và nếu làm xấu có thể rất vụng về. Kinh nghiệm cá nhân của tôi là nó đòi hỏi rất nhiều thực hành trong tất cả các tình huống mà bạn MUỐN CÁCH rằng bạn đã làm khác đi, để làm điều đó đủ tốt trong lần này .

Tôi chỉ xem một video của Richard Feynman thảo luận về cách mọi người thực sự có thể có những phương pháp hoàn toàn khác nhau đang diễn ra trong đầu họ khi nghĩ - ý tôi là hoàn toàn khác.

Khi tôi thực hiện thiết kế cấp cao, tôi tình cờ hình dung được các đối tượng, tôi có thể nhìn thấy chúng, xem giao diện của chúng và xem thông tin đường dẫn nào cần phải đi qua.

Tôi cũng gặp khó khăn khi nhớ các chi tiết và thấy OO là một trợ giúp tổ chức tuyệt vời - dễ dàng tìm thấy chức năng hơn là quét qua danh sách các chương trình con được tổ chức lỏng lẻo.

Đối với tôi OO là một lợi ích tuyệt vời, nhưng nếu bạn không hình dung theo cùng một cách hoặc không làm kiến ​​trúc cấp cao, điều đó có thể là vô nghĩa và gây phiền nhiễu.

Tôi đã thực hiện lập trình GW-Basic và Turbo Pascal một cách công bằng trước khi được giới thiệu vào OO, vì vậy ban đầu, DID làm đầu óc tôi.

Không biết đây có phải là điều xảy ra với người khác không, nhưng với tôi nó là như thế này: quá trình suy nghĩ của tôi về lập trình hoàn toàn là thủ tục. Như trong: "như vậy và như vậy xảy ra, sau đó sẽ xảy ra như vậy", v.v. Lập trình là "dòng chảy của hành động".

Tôi cho rằng những gì không dễ nắm bắt (ngu ngốc như bây giờ đối với tôi), là ý tưởng rằng dữ liệu / biến thực sự quan trọng , theo nghĩa sâu sắc hơn là chỉ diễn viên trong chương trình "chảy". Hoặc nói theo cách khác: Tôi tiếp tục cố gắng hiểu nó thông qua những gì xảy ra , thay vì thông qua những gì là , chìa khóa thực sự để nắm bắt nó.

Tôi không nghĩ nó khó hiểu nhưng có thể có rất nhiều lập trình viên truy vấn là mới đối với khái niệm này, đến từ các ngôn ngữ thủ tục.

Từ những gì tôi đã thấy / đọc rất nhiều người (ít nhất là trong các diễn đàn) tìm kiếm một "kết quả" từ OOP. Nếu bạn là một lập trình viên thủ tục không quay lại và sửa đổi mở rộng mã của họ, có lẽ khó có thể hiểu được lợi ích.

Ngoài ra, có rất nhiều OOP xấu ngoài kia, nếu mọi người đang đọc / nhìn thấy điều đó thì thật dễ dàng để biết lý do tại sao họ có thể thấy khó khăn.

IMO bạn cần đợi cho đến khi nó 'nhấp chuột' hoặc được dạy bởi một người có kiến ​​thức thực sự, tôi không nghĩ bạn có thể vội vàng.

Tôi nghĩ lý do OOP gây khó khăn cho nhiều người là vì các công cụ không thực sự tạo điều kiện thuận lợi cho nó.

Ngôn ngữ máy tính ngày nay là một sự trừu tượng của những gì đang diễn ra trong máy tính.

OOP là một cách trừu tượng để thể hiện sự trừu tượng.

Vì vậy, chúng tôi đang sử dụng một sự trừu tượng để xây dựng sự trừu tượng với sự trừu tượng hóa. Thêm vào đó là những gì chúng ta đang trừu tượng hóa thường là những tương tác vật lý / xã hội rất phức tạp và, tốt, không có gì lạ.

Tôi thực sự có một blog tên là "Đấu tranh trong lập trình hướng đối tượng", được sinh ra từ một số cuộc đấu tranh của tôi với việc học nó. Tôi nghĩ nó đặc biệt khó hiểu đối với tôi vì tôi đã dành quá nhiều thời gian để sử dụng lập trình thủ tục và tôi đã có một thời gian khó khăn để nghĩ rằng một đối tượng có thể được đại diện bởi một tập hợp các thuộc tính và hành vi (tôi đã từng chỉ đơn giản là một tập hợp các biến và phương thức).

Ngoài ra, có rất nhiều khái niệm làm cho đối tượng ngôn ngữ được định hướng - kế thừa, giao diện, đa hình, thành phần, v.v ... Thực sự có rất nhiều điều để tìm hiểu về lý thuyết của nó trước khi bạn thực sự có thể viết mã hiệu quả và theo hướng đối tượng cách, trong khi với lập trình thủ tục, đơn giản chỉ là vấn đề hiểu những thứ như cấp phát bộ nhớ cho các biến và gọi điểm vào các phương thức khác.

Động lực. Thật khó để học một cái gì đó khi bạn không hiểu tại sao, và cả khi bạn không thể nhìn vào những gì bạn đã làm và tìm hiểu xem bạn đã làm đúng hay chưa.

Điều cần thiết là các dự án nhỏ sử dụng OO để làm những việc hữu ích. Tôi khuyên bạn nên xem qua một cuốn sách về các mẫu thiết kế và tìm ra một cuốn sách rõ ràng hữu ích và hoạt động tốt với OO. .

Tôi nghĩ rằng nó phụ thuộc vào tuổi tác (tuổi như một proxy cho kinh nghiệm) và quan trọng hơn là sự quan tâm. Nếu bạn "trẻ" (nghĩa là màu xanh lá cây, có lẽ) và bạn chưa bao giờ nghĩ cách nào khác, điều đó có vẻ khá đơn giản. Mặt khác, nếu bạn nghĩ đó là điều tuyệt vời nhất bạn từng thấy - đã xảy ra với tôi ở tuổi 28 hoặc một điều gì đó - thật dễ dàng để mò mẫm.

Mặt khác, nếu bạn nghĩ, như nhiều sinh viên Java của tôi đã làm, "tại sao chúng ta học cái này, nó chỉ là mốt nhất thời", thực tế không thể học được. Điều này đúng với hầu hết các công nghệ.

Bất kể mô hình nào (OOP, chức năng, v.v.) bạn chọn, để viết chương trình máy tính, bạn cần biết chương trình của mình sẽ làm những bước nào.

Cách tự nhiên để xác định một quy trình là viết ra các bước của nó, cho các nhiệm vụ lớn hơn, bạn chia nhiệm vụ thành các bước nhỏ hơn. Đây là cách thủ tục, đây là cách máy tính hoạt động, đây là cách bạn đi qua danh sách kiểm tra từng bước.

OOP là một cách nghĩ khác. Thay vì nghĩ về một danh sách kiểm tra các nhiệm vụ cần được thực hiện từng bước, bạn nghĩ về các đối tượng, khả năng và mối quan hệ của chúng. Vì vậy, bạn sẽ viết rất nhiều đối tượng, phương thức nhỏ và chương trình của bạn sẽ hoạt động một cách kỳ diệu. Để đạt được điều này, bạn cần phải thay đổi suy nghĩ của mình ...

Và đây là lý do tại sao OOP khó khăn. Vì mọi thứ đều là một đối tượng, tất cả những gì họ làm là yêu cầu các đối tượng khác làm một cái gì đó, và những đối tượng khác về cơ bản làm một số. Vì vậy, điều khiển trong chương trình OOP có thể nhảy qua lại giữa các đối tượng.

Là một người hiện đang học lập trình và có một số vấn đề trong lĩnh vực này, tôi không nghĩ rằng nó quá khó hiểu đến mức khái niệm này là những triển khai cụ thể của khái niệm này. Tôi nói điều này bởi vì tôi có ý tưởng về OOP và tôi đã sử dụng nó trong PHP khoảng một năm, nhưng khi tôi chuyển sang C # và xem xét cách sử dụng các đối tượng của các lập trình viên khác, tôi thấy rằng nhiều người làm như vậy theo cách mà tôi không hiểu Chính điều này đã đưa tôi xuống con đường tìm kiếm sự hiểu biết tốt hơn về các nguyên tắc của OOP.

Tất nhiên, tôi nhận ra rằng vấn đề rất có thể là do tôi thiếu kinh nghiệm với ngôn ngữ OOP vốn có, và khi thời gian trôi qua, tôi sẽ tìm ra những cách mới để sử dụng các đối tượng sẽ không rõ ràng đối với một lập trình viên mới như tôi hiện đang trải nghiệm. Jerry Coffin đã chạm vào điều này một vài lần, đặc biệt là trong bình luận của anh ấy:

Điều này trở nên đặc biệt khó khăn khi một mặt bạn nói rằng một lợi thế lớn của OOP là mô hình hóa thực tế chặt chẽ hơn, nhưng bạn bắt đầu bằng cách nhìn những gì trông rất khủng khiếp như một quan điểm lấy cảm hứng từ LSD về những phần cơ bản và rõ ràng nhất của thực tế.

Tôi thấy điều này rất chính xác, vì đó là ấn tượng tôi thường nhận được khi thấy ai đó tạo ra các lớp học cho những thứ không thực sự - một ví dụ cụ thể thoát khỏi tôi, nhưng gần nhất tôi có thể nghĩ ra là cách xử lý khoảng cách như một đối tượng (tôi sẽ chỉnh sửa vào lần tới khi tôi thấy thứ gì đó gây ra sự nhầm lẫn tương tự này). Đôi khi, OOP dường như tạm thời bỏ qua các quy tắc riêng của mình và trở nên ít trực quan hơn. Điều này thường xuyên hơn không xảy ra khi các đối tượng đang tạo ra các đối tượng, kế thừa từ một lớp đang gói gọn chúng, et cetera.

Tôi nghĩ đối với một người như tôi, sẽ giúp nghĩ đến khái niệm các vật thể có nhiều khía cạnh, một trong số đó bao gồm việc đối xử với một thứ giống như một vật thể khi nó không tồn tại. Một cái gì đó như khoảng cách, chỉ với một chút thay đổi mô hình, có thể đi qua như một đối tượng lý thuyết, nhưng không phải là một thứ có thể cầm trên tay bạn. Tôi phải nghĩ về nó như có một tập các thuộc tính nhưng một tập hợp các hành vi trừu tượng hơn, chẳng hạn như truy cập các thuộc tính của nó. Tôi không tích cực rằng đây là chìa khóa cho sự hiểu biết của tôi, nhưng dường như đó là nơi các nghiên cứu hiện tại của tôi đang dẫn đầu.

Thuật ngữ là cú va chạm của tôi khi học các nguyên tắc lập trình hướng đối tượng (POOP). Đó là khi bạn nắm được các nguyên tắc cơ bản mà các mảnh bắt đầu rơi vào vị trí. Cũng giống như tất cả những điều học các khái niệm mới là một chút khó khăn.

Đồng ý rằng các mẫu thiết kế nên được nghĩ ít nhất là song song với OOP.

Bước nhảy chính đối với tôi chỉ là hiểu khái niệm trừu tượng của OOP. Bây giờ tôi rất mới đối với lập trình nói chung Tôi đã lập trình được một năm đến một năm rưỡi rồi nên việc giới thiệu về OOP của tôi là với Hành động và Xử lý. Khi tôi lần đầu tiên học mã hóa Actioncript, nó không có trong OOP. Tôi đã học cách viết mã trực tiếp vào bảng Hành động và đó là cách tôi học các nguyên tắc cơ bản cơ bản của lập trình (biến, hàm, vòng lặp, v.v.). Vì vậy, tôi đã học được nó khi làm một cái gì đó trực tiếp lên sân khấu trong Flash hoặc Xử lý.

Khi OOP xuất hiện, việc nhận ra rằng tôi có thể tạo các phương thức và thuộc tính trong một đối tượng để có thể sử dụng và tái sử dụng là một chút khó khăn đối với tôi lúc đầu. Mọi thứ đều rất trừu tượng và khó xử lý nhưng bản thân các ngôn ngữ lập trình tốt hơn rất nhiều nhưng nó đã tạo ra một bước nhảy vọt về niềm tin để tạo ra những kết nối đó lúc đầu.

Công thức

Hiểu biết tốt về OOP = Người cố vấn tốt hoặc Sách hay Cả hai + Sở thích cá nhân + Thực hành.

Sở thích cá nhân

Từ kinh nghiệm cá nhân của tôi, lợi ích cá nhân đi một chặng đường dài để vượt qua cầu nối từ lập trình thủ tục sang OOP với đầu vào phù hợp từ những người cố vấn hoặc những cuốn sách hay hoặc cả hai kết hợp .

Thực hành, thực hành và thực hành

Người bạn tốt nhất của tôi để hiểu rõ hơn về OOP không gì khác ngoài thực hành. Điều này chắc chắn sẽ thúc đẩy khả năng OOP của bạn.

Như người ta nói, không có gì thay thế cho công việc khó khăn và không có lối tắt để thành công.

Chúc may mắn!