it-swarm-vi.com

Tại sao OOP khó?

Khi tôi bắt đầu sử dụng ngôn ngữ hướng đối tượng (Java), tôi đã sử dụng "Cool" 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ó là 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? Is khó hiểu?

93
gablin

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. Dạy IMHO 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. Các phương thức riêng lẻ trong một chương trình OO có xu hướng trông 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.

120
dsimcha

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ứ 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 con 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ự is 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 xem 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 của ngay cả những phần cơ bản nhất và rõ ràng 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 là không có bất kỳ nơi nào gần với 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 biệt, tạo một class D kế thừa từ một class B có nghĩa là các đối tượng của class D chia sẻ hoàn toàn, tích cực tất cả các đặc điểm của class B. class D có 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 của class B phải còn nguyê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ì điều 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ự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. Thật dễ dàng để thấy rằng rộng lớn phần lớn những gì hầu hết mọi người nghĩ là "xe hơi" có bốn bánh. 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 phân loại khổng lồ - ví dụ: bit 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 thứ 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 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. 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 giống chó, và liệu (ví dụ) " poodle thu nhỏ "nên kế thừa từ" poodle kích thước đầy đủ ", hoặc ngược lại, hoặc liệu có nên có một lớp" Poodle "cơ sở trừu tượng, với" poodle kích thước đầy đủ "và" poodle thu nhỏ "đều thừa hưởng từ nó. bỏ qua là ứng dụng được cho là để đối phó với việc theo dõi giấy phép cho chó và với mục đích trong tay, nó hoàn toàn phù hợp để có một lĩnh vực duy nhất có tên là "giống" (hoặc một cái gì đó theo thứ tự đó) mà không mô hình hóa mối quan hệ giữa các giống ở tất cả.

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ần thiết các lớp con để phù hợp với trừu tượng hóa chúng tôi đã xây dựng.

Cuối cùng, tôi sẽ nói một lần nữa: chúng ta từ từ đ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, ở mức độ trừu tượng hóa này, các 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ệ 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, Java generic, chẳng hạn, không thực sự đủ điều kiện , mặc dù họ là một bước nhỏ theo đúng hướng).

57
Jerry Coffin

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ó.

26
John Kraft

Bất kỳ mô hình nào cũng cần một cú hích nhất định "vượt biên" để 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?"

21
CodexArcanum

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 lập bản đồ "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.

21
John Fisher

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 hơi một đối tượng, và các bánh xe là các đối tượng, và các cánh cửa, và truyền ... ", 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. rằng nó làm cho 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.

15
Dan Monego

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 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 hoặc thủ tục.

  2. Các phương thức riêng lẻ tốt OO chương trình 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 OO ngôn ngữ (đọc C # vì khác với C++, chỉ có ngôn ngữ khác OO 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 với các đối tượng, v.v.). Điểm tương đồng duy nhất giữa OO trong các ngôn ngữ thủ tục là bản chất tuyến tính của mỗi ngôn ngữ, đ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 OO. Truyền các tham số bằng tham chiếu, ví dụ, khá phổ biến trong các ngôn ngữ thủ tục, yêu cầu bạn phải hiểu con trỏ nhiều như yêu cầu học bất kỳ OO.

  4. Tôi không nghĩ rằng các mẫu thiết kế nên được dạy sớm trong OO, bởi vì chúng không phải là cơ bản để OO. là một người tốt OO mà không biết gì về các mẫu thiết kế. 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à sách đó là 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à OO lập trình viên ngày nay không quen thuộc với điều này Khái niệm cơ bản hoặc chỉ chọn bỏ qua nó và đó là lý do tại sao chúng ta có quá nhiều rác OO mã ngoài đó. Chỉ sau khi hiểu rõ về những điều này và các nguyên tắc khác, các mẫu thiết kế mới được đưa ra.

Để trả lời câu hỏi của người đăng ban đầu, có, 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 đặc tính và phương pháp của các đối tượng trong cuộc sống thực. Ví dụ: con người bộ não không dễ dàng coi "TurnOn" là một phương pháp 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ự, đa hình là một khái niệm xa lạ với bộ não con người chỉ nhìn thấy mỗi đối tượng trong cuộc sống thực chỉ bằng một " đối 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à 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 ngôn ngữ thủ tục là tự nhiên hơn đối với nó.

13
SoftwareRockstar

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 đó thực hiện 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 bó 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 khi 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ó.

6
JeffO

Bạn nên đọc Đối tượng không bao giờ? Chà, hầu như không bao giờ. (Yêu cầu thành viên ACM) bởi Mordechai Ben-Ari, người gợi ý rằng OOP rất khó, vì đó không phải là mô hình Điều đó thực sự tự nhiên để mô hình hóa bất cứ điều gì. (Mặc dù tôi có đặt trước về bài viết, vì không rõ tiêu chí nào mà anh ấy cảm thấy chương trình cần phải thỏa mãn để nói rằng nó được viết trên mô hình OOP trái ngược với mô hình thủ tục sử dụng ngôn ngữ OO.)

5
Ken Bloom

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 làm đúng có thể rất tao nhã, và nếu làm xấu thì 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 mà bạn đã làm khác đi, để làm điều đó đủ tốt điều này thời gian.

5
user1249

Tôi đã thực hiện lập trình GW-Basic và Turbo Pascal một chút công bằng trước khi được giới thiệu vào OO, vì vậy ban đầu nó ĐÃ LÀM 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. Tôi không bao giờ coi các biến và dữ liệu là bất cứ điều gì hơn là các tác nhân thoáng qua trong dòng chảy của chương trình. Lập trình là "dòng chảy của hành động".

Tôi cho rằng điều 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ự thực sự quan trọng , trong một ý nghĩa sâu sắc hơn là chỉ là những diễn viên thoáng qua trong "dòng chảy" chương trình. 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ó.

4
Bobby Tables

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ờ trực quan hóa 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ớ chi tiết và thấy OO là một trợ giúp tổ chức tuyệt vời - dễ tìm chức năng hơn nhiều so với 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.

4
Bill K

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 điều xấu OOP 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ể Rush.

3
DBlackborough

Tôi nghĩ lý do OOP là khó khăn đối với 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ạ.

3
ElGringoGrande

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.

2
Tim Claason

Độ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à đưa ra một dự án rõ ràng hữu ích và hoạt động tốt với OO. (Tôi đã sử dụng Chiến lược một lần tôi đã thử nó. Một cái gì đó như Flykg hoặc Singleton sẽ là những lựa chọn tồi, vì chúng là cách sử dụng các đối tượng nói chung, không sử dụng các đối tượng để hoàn thành một cái gì đó.)

2
David Thornley