Lập trình hướng đối tượng là một giải pháp cho sự phức tạp? [đóng cửa]

Bạn có nghĩ Lập trình hướng đối tượng là một giải pháp cho sự phức tạp. Tại sao? Chủ đề này có thể gây tranh cãi một chút nhưng ý định của tôi để biết câu trả lời Tại sao từ các chuyên gia ở đây!

Không có giải pháp cho sự phức tạp.

Trong "Tháng huyền thoại", Fred Brooks thảo luận về sự khác biệt giữa sự phức tạp tình cờ và thiết yếu trong lập trình. Sự phức tạp ngẫu nhiên là do các công cụ và phương pháp của chúng tôi gây ra, chẳng hạn như phải viết và kiểm tra mã bổ sung bằng ngôn ngữ vì chúng tôi không thể diễn đạt trực tiếp ý tưởng của mình và những thứ tương tự. Các phương pháp và kỹ thuật mới có thể làm giảm sự phức tạp tình cờ. Tôi có thể viết chương trình nhanh hơn và tốt hơn tôi có thể hai mươi lăm năm trước, bởi vì tôi có ngôn ngữ và công cụ tốt hơn.

Sự phức tạp thiết yếu xuất phát từ thực tế là những gì chúng ta cố gắng thực hiện với lập trình vốn đã phức tạp và có một sự phức tạp không thể khắc phục được. "Cần thiết", trong bối cảnh này, có nghĩa là "liên quan đến bản chất của sự việc" chứ không phải là "rất cần thiết".

Do đó, ông tuyên bố rằng sẽ không có viên đạn bạc, phần mềm viết sẽ tiếp tục gặp khó khăn.

Tôi thực sự khuyên bạn nên đọc cuốn sách của anh ấy: cụ thể, tôi đề nghị phiên bản Kỷ niệm Bạc, với một bài tiểu luận bổ sung "Không có viên đạn bạc". Trong đó, ông xem xét các giải pháp đề xuất cho sự phức tạp và xem xét tác động của chúng. (Thứ anh ta thấy hiệu quả nhất là phần mềm thu nhỏ - viết một cái gì đó phức tạp một lần và bán hàng ngàn hoặc hàng triệu bản.)

Bây giờ, lập trình hướng đối tượng giúp, khi được thực hiện đúng, bằng cách tạo ra sự trừu tượng và che giấu sự phức tạp. Một đối tượng của một lớp có một hành vi được xác định nhất định mà chúng ta có thể suy luận từ đó, mà không quan tâm đến sự phức tạp của việc thực hiện. Các lớp được viết đúng có khớp nối thấp với nhau, và phân chia và chinh phục là một cách tuyệt vời để đối phó với sự phức tạp nếu bạn có thể thoát khỏi nó. Chúng cũng có sự gắn kết cao, trong đó chúng là một tập hợp các chức năng và dữ liệu có liên quan rất chặt chẽ với nhau.

Tôi hy vọng bạn sẽ sớm nhận được một số câu trả lời tốt hơn, nhưng đây là một câu trả lời đơn giản:

OOP giúp * với sự phức tạp bằng cách mô hình hóa phần mềm theo cách gần với cách chúng ta mô hình hóa mọi thứ khác trên thế giới. Nhìn chung, việc hình ảnh một vật thể bóng tương tác với vật thể trên tường thường dễ dàng hơn so với tưởng tượng một loạt các thói quen và cấu trúc dữ liệu để làm điều tương tự, vì nó gần với cách chúng ta tương tác với thế giới thực.

* Bởi vì không có gì có thể 'giải quyết' sự phức tạp

Tôi nghĩ định nghĩa chính của OOP hiện tại không phải là một giải pháp tốt để quản lý sự phức tạp.

Nếu bạn quay trở lại cội nguồn của nó, tôi tin rằng Alan Kay bị ảnh hưởng bởi "lisp" rất nhiều.

Bởi vì Lisp đã không bị hỏng bởi việc áp dụng chính thống, nên có lẽ nó đã cố gắng bảo tồn các giá trị cốt lõi của nó. Vì vậy, tôi nghĩ rằng việc xem xét cách giải quyết vấn đề phức tạp này có thể giúp chúng ta hiểu rõ hơn và chúng ta có thể sử dụng nó như một cơ sở để đánh giá mức độ hữu ích của OOP trong việc xử lý sự phức tạp.

Nếu bạn nhìn vào phần cuối của "Bài giảng 3a: Ví dụ về Henderson Escher" của SICP , Hal Abelson đề xuất rằng sự phức tạp được quản lý không phải bằng cách phá vỡ nhiệm vụ thành các nhiệm vụ nhỏ hơn, mà bằng cách tạo ra các lớp trừu tượng. Ở cấp độ cao nhất, bạn thể hiện giải pháp cho vấn đề phức tạp về mặt giải pháp cho mức độ trừu tượng thấp hơn.

Tôi nghĩ ban đầu OOP được dự định là một cơ chế để tạo ra các lớp trừu tượng này.

Thật không may, ngày nay, OOP được sử dụng để viết mã / cấu trúc spaghetti.

Tôi sẽ tạo một ví dụ: một game nhiều người chơi FPS.

Ở cấp độ cao nhất, trò chơi hoạt động bằng cách có một nhóm người chơi chạy quanh bản đồ và bắn nhau bằng vũ khí.

Ở cấp độ thấp hơn tiếp theo, chúng ta phải nói về bản đồ và vũ khí và người chơi. Có lẽ chúng ta có thể nói về chúng như những vật thể tương tác trong thế giới của trò chơi.

Ở cấp độ thấp hơn tiếp theo, chúng ta có thể nói về cách các đối tượng tương tác vật lý (chuyển động, va chạm, v.v.).

Vân vân và vân vân.

Điều này có nghĩa là gì, (và tôi sắp xếp trích dẫn từ SICP ..), là ở mỗi lớp, chúng tôi không chỉ giải quyết một vấn đề cụ thể, mà còn là một loại vấn đề rơi vào hàng xóm của vấn đề chúng tôi ' Đang cố gắng giải quyết. Vì vậy, nếu có một thay đổi nhỏ trong mô tả của vấn đề, thì có thể chỉ cần một thay đổi nhỏ trong giải pháp.

Vì vậy, cách khôn ngoan để sử dụng OOP là tạo các lớp trừu tượng, ở mỗi cấp độ trừu tượng, bạn giải quyết vấn đề trong tay bằng cách sử dụng các "đối tượng" từ cấp độ ngay bên dưới.

Đây là đoạn tôi đã trích dẫn từ bài giảng: http://www.youtube.com/watch?v=CYtrfncMqHQ

Như thường lệ tôi không đồng ý với mọi người. Khác xa với việc cung cấp cho bạn các công cụ để quản lý sự phức tạp, OOP tạo ra một số lượng phức tạp rất lớn bởi vì đây là một mô hình không có thật và không có tính toán học. Nó gây nhầm lẫn cho các lập trình viên không có hồi kết, để cố gắng mô hình hóa mọi thứ với OOP không thể được mô hình hóa bằng OOP.

Theo quan điểm của tôi, công việc tinh thần ở đây là Xây dựng phần mềm hướng đối tượng của Meyer. Nó mô tả chi tiết một loạt các yêu cầu, bao gồm một yêu cầu quan trọng: Nguyên tắc đóng mở. Điều này nói rằng một thứ phải được mở để mở rộng nhưng đồng thời đóng lại để sử dụng.

Meyer tiến hành rút ra Định hướng đối tượng từ những yêu cầu này, như được thể hiện ở Eiffel. Đóng gói cung cấp sự đóng cửa, tính kế thừa mở và "điều" được đề cập là lớp.

Tôi coi công việc này là khoa học tốt bởi vì Meyer đã sai lầm nghiêm trọng, và có thể vì chất lượng công việc của anh ta, để xác định lỗi và sửa lỗi.

Lỗi là làm cho lớp, hoặc loại, đơn vị của mô-đun. Điều đó sai, và chắc chắn là như vậy. Ngay cả Meyer cũng nhận ra vấn đề (được gọi là vấn đề hiệp phương sai), rằng OOP không thể xử lý các mối quan hệ của arity cao hơn một (nghĩa là OOP hoạt động tốt đối với các thuộc tính nhưng thất bại trong quan hệ nhị phân). Ở Eiffel, vấn đề này dẫn đến một sự bất ổn trong hệ thống loại!

Giải pháp khá rõ ràng. Đơn vị của mô-đun phải lớn hơn một loại. Nó phải bao gồm một số loại và các phương pháp liên quan đến chúng.

Không có gì đáng ngạc nhiên khi mô hình trừu tượng này được hỗ trợ bởi lý thuyết trừu tượng toán học, cụ thể là lý thuyết phạm trù: các loại là đối tượng của một thể loại và các phương thức (hàm) là mũi tên.

Với mô hình này, các biểu diễn của một số loại được biết đến với một tập hợp các hàm. Các đại diện được ẩn khỏi công chúng, vì vậy đây là sự mã hóa, nhưng chúng tôi sử dụng các mô-đun, không phải các lớp.

Ngôn ngữ meta chuẩn (SML) và Ocaml được dựa trực tiếp vào mô hình này. Ocaml cũng có các lớp và OOP: nó không vô dụng vì OOP cung cấp cho bạn công văn về các thuộc tính, còn gọi là ràng buộc động. Tuy nhiên, hầu hết các vấn đề trong thế giới thực liên quan đến các mối quan hệ và hầu như không có gì đáng ngạc nhiên khi các lớp không được sử dụng nhiều trong Ocaml.

Kế thừa hầu như không đáng ngạc nhiên hầu như không được sử dụng trong thư viện mẫu C ++ Standard.

Một thực tế đơn giản là, OOP không cung cấp cho bạn các công cụ phù hợp để xử lý sự phức tạp, thậm chí nó còn không cung cấp cho bạn các công cụ để xử lý các vấn đề thực sự đơn giản, thay vào đó, nó đã đánh lừa và nhầm lẫn hai thế hệ lập trình viên. Khác xa với sự giúp đỡ, OOP là điều xấu xa và tồi tệ nhất đã xảy ra với lập trình kể từ khi C, Fortran và Cobol bắt đầu mệt mỏi.

Lập trình hướng đối tượng có nguồn gốc có thể bắt nguồn từ những năm 1960. Khi phần cứng và phần mềm ngày càng phức tạp, khả năng quản lý thường trở thành mối quan tâm. Các nhà nghiên cứu đã nghiên cứu các cách để duy trì chất lượng phần mềm và phát triển lập trình hướng đối tượng một phần để giải quyết các vấn đề phổ biến bằng cách nhấn mạnh mạnh vào các đơn vị logic lập trình rời rạc, có thể tái sử dụng.

Do đó, một chương trình hướng đối tượng có thể được xem như một tập hợp các đối tượng tương tác, trái ngược với mô hình thông thường, trong đó một chương trình được xem như một danh sách các nhiệm vụ (chương trình con) để thực hiện. Trong OOP, mỗi đối tượng có khả năng nhận tin nhắn, xử lý dữ liệu và gửi tin nhắn đến các đối tượng khác. Mỗi đối tượng có thể được xem như một "cỗ máy" độc lập với vai trò hoặc trách nhiệm riêng biệt. Các hành động (hoặc "phương thức") trên các đối tượng này được liên kết chặt chẽ với chính đối tượng đó.

http://en.wikipedia.org/wiki/Object-oriented_programming

Sự phân tách mối quan tâm này, cùng với các tính năng khác của Định hướng đối tượng như đa hình, kế thừa, truyền thông điệp, tách rời và đóng gói, cung cấp một khung logic và khái niệm mà theo đó sự phức tạp của các chương trình lớn có thể được quản lý theo cách hiệu quả cao.

Có nhiều loại phức tạp để phát triển phần mềm. Ở cấp độ lập trình, OOP tìm cách giải quyết sự phức tạp bằng cách sử dụng các đối tượng và các lớp để mô hình hóa miền vấn đề. Một guru nổi tiếng cho biết giải quyết vấn đề chỉ là đại diện cho vấn đề để giải pháp là chính đại diện. Do đó, bằng cách trừu tượng hóa bằng cách sử dụng các lớp, đóng gói bằng các phương thức và phương thức truy cập, kế thừa để chỉ định mối quan hệ và tái sử dụng, thành phần trong việc thiết lập mối quan hệ và hợp tác giữa các lớp, đa hình như một phương tiện để đơn giản hóa việc xác định các hành vi khác nhau trong các đối tượng tương tự, có thể quản lý được sự phức tạp.

Ngoài ra còn có các cách khác để quản lý độ phức tạp của phần mềm, ví dụ: lập trình Logic (Prolog) và Chức năng (Haskell).

Ở cấp độ cao hơn lập trình, chúng tôi cần Nguyên tắc và Nguyên tắc Thiết kế để hướng dẫn OOP. Do đó, OOP đang quản lý độ phức tạp ở mức thấp (mã hóa) trong khi các phương pháp này như Mẫu thiết kế và Nguyên tắc hướng dẫn thiết kế giải pháp ở cấp độ cao hơn (hệ thống và ứng dụng) và làm cho việc phát triển và xử lý phần mềm trở nên dễ quản lý hơn.

Để trả lời câu hỏi của bạn, vâng, OOP chỉ là một giải pháp để xử lý sự phức tạp giữa nhiều giải pháp khác. Đó là một giải pháp ở mức độ thấp. Chúng tôi cần các Mẫu và Nguyên tắc Thiết kế để hướng dẫn OOP ở cấp độ cao hơn.

Lập trình hướng đối tượng quản lý sự phức tạp cần thiết và tùy chọn, nhưng cũng không giảm.

Tôi thích định nghĩa được cung cấp bởi Eric Steven Raymond trong Nghệ thuật lập trình Unix , bởi vì nó phân định giữa sự phức tạp cần thiết, tùy chọn và tình cờ. http://www.faqs.org/docs/artu/ch13s01.html#id2964646

OOP không làm gì cho sự phức tạp cần thiết hoặc tùy chọn, chúng là một chức năng của các yêu cầu của chương trình. Nó có thể có ảnh hưởng đến sự phức tạp tình cờ, trong đó đôi khi bạn có thể tạo ra một thiết kế thanh lịch hơn với OOP. Tuy nhiên, đôi khi thiết kế tệ hơn khi sử dụng OOP.

Các vấn đề phức tạp không thể được đưa ra đơn giản hơn thông qua công nghệ, chúng chỉ có thể được quản lý thông qua công nghệ.

OOP là một công nghệ, một khái niệm và một cách để tiếp cận một vấn đề.

OOP cung cấp cho bạn các công cụ để thực thi một thiết kế có thể giúp quản lý sự phức tạp dễ dàng hơn, nhưng bạn có thể dễ dàng có một thiết kế xấu làm tăng sự phức tạp của bạn. Nói cách khác, nếu không được sử dụng đúng cách, bạn có thể gặp phải sự phức tạp do công nghệ gây ra trong các vấn đề của mình.

Hãy nhớ rằng có nhiều khía cạnh khác sẽ quyết định mức độ thành công của dự án của bạn (ví dụ: phong cách quản lý dự án, định nghĩa vấn đề, quản lý thay đổi, v.v ...). Công nghệ bạn sử dụng chỉ liên quan đến mức độ nó sẽ giúp bạn quản lý vấn đề.

Cuối cùng, lập trình hướng đối tượng có thể là một giải pháp cho sự phức tạp; nó chỉ là một công cụ để quản lý nó. (nếu sử dụng đúng cách)

Định hướng đối tượng (như được sử dụng thông thường) là một công cụ hữu ích trong nhiều trường hợp, nhưng nó không phải là một giải pháp đủ cho sự phức tạp.

Đặc biệt, nó thường thêm rất nhiều " sự phức tạp ngẫu nhiên ". Ví dụ là sự phức tạp xung quanh việc kế thừa triển khai, nhu cầu cung cấp rất nhiều "chức năng tiêu chuẩn" như bằng () và hashCode (), v.v. Một bài thuyết trình hay của Stuart Halloway về chủ đề này: " Đơn giản không dễ dàng "

Các đối tượng trong hầu hết các ngôn ngữ cũng có xu hướng gói gọn rất nhiều trạng thái có thể thay đổi - mà trong một thế giới đồng thời đang ngày càng bắt đầu giống như một quyết định thiết kế kém. Một lần nữa, một video thú vị của Rich Hickey xem xét sự khác biệt giữa nhận dạng đối tượng và trạng thái, và làm thế nào có thể là một sai lầm khi kết hợp cả hai.

Lập trình hướng đối tượng là một cách thể hiện một vấn đề, không hơn, không kém. Bản thân nó không phức tạp hơn bất kỳ mô hình lập trình nào khác. Một hệ thống OOP được thiết kế tốt sẽ quản lý và giảm độ phức tạp, nhưng cũng rất dễ dàng để thiết kế một hệ thống phức tạp hơn nhiều so với mức cần thiết và cản trở mọi thứ.

Như đã nói về C ++, OOP cung cấp cho bạn đủ dây để tự treo.

Tôi nghĩ CÓ , chỉ vì nó cho phép bạn cắt độ phức tạp thành các "khối xây dựng" nhỏ chứa các chi tiết, sau đó sử dụng chúng để tạo chức năng bạn cần, từng bước, từng lớp.

Phân chia và chinh phục.

OOP là một nỗ lực tại một giải pháp.

Cách tốt nhất để quản lý sự phức tạp là tạo ra sự trừu tượng. Nếu tôi có thể biến dữ liệu của mình thành các bộ sưu tập hữu ích, với các chức năng dễ nhận biết hoạt động trên các bộ sưu tập đó, tôi có thể bắt đầu nghĩ về các bộ sưu tập dưới dạng "những thứ" rời rạc. Đó là cơ sở cho các lớp học và phương thức. Về mặt đó, OOP được thiết kế đúng có thể giúp quản lý sự phức tạp.

Ở đâu đó, ai đó đã quyết định rằng chúng ta có thể sử dụng OOP để giúp giải quyết vấn đề tái sử dụng mã. Ý tôi là, tại sao lại phát minh lại cái bánh xe? Nếu ai đó đã thực hiện nhiều công việc để giải quyết vấn đề này, hãy tận dụng những gì họ đã làm, thêm các điều chỉnh mà dự án cụ thể của bạn yêu cầu và thì đấy! Bạn đã tạo ra một ứng dụng mạnh mẽ, tinh vi với công việc tương đối ít. Lập trình viên OO có thể là những lập trình viên rất năng suất.

Kết quả cuối cùng là các lập trình viên OO hiện đại cuối cùng trở thành "người học việc của thầy phù thủy", nơi họ liên kết với nhau một loạt các thư viện lớn, khó sử dụng với một vài dòng "keo" và có được thứ gì đó hoạt động. Sắp xếp Kinda. Hầu hết thời gian. Có tác dụng phụ tiềm năng nào từ việc sử dụng thư viện này với thư viện đó không? Có lẽ. Nhưng ai có thời gian để thực sự đào sâu vào mã chứa trong các thư viện đó? Đặc biệt là khi các thư viện đang phát triển. Kết quả là chúng tôi kết thúc với các ứng dụng cồng kềnh, nơi một lập trình viên cần một số lớp và phương thức từ thư viện đó, nhưng ứng dụng phải mang trọng lượng của tất cả những thứ KHÁC họ không cần.

Kết quả cuối cùng là bạn kết thúc với sự phức tạp hơn nhiều so với bạn cần.

Một cơ chế khác để đối phó với sự phức tạp mà bạn muốn tách chức năng. Bạn muốn tất cả các chức năng truy cập dữ liệu của bạn ở một nơi. Bạn muốn tất cả các chức năng giao diện người dùng của bạn ở một nơi. Bạn muốn tất cả các bộ điều khiển của bạn ở một nơi. Vì vậy, bạn tạo các lớp khác nhau để quản lý các phần khác nhau của chức năng. Càng xa càng tốt. Và quy mô này, ở một mức độ; nhà phát triển của bạn có kỹ năng truy cập dữ liệu có thể viết các lớp đó, những người có giao diện người dùng của bạn có thể viết các lớp giao diện người dùng, v.v ... Tất cả đều tốt và tốt.

Cho đến khi bạn phải duy trì một cái gì đó được viết bởi người khác.

Vâng, thật tốt khi biết rằng tất cả các chức năng truy cập dữ liệu được đặt ở đây. Nhưng những gì gọi họ?

Phương thức này đang gọi phương thức đó trên lớp đó. Nhưng khi tôi nhìn vào định nghĩa lớp, không có phương thức nào có tên đó. Ồ, đó là di truyền từ một thứ khác một hoặc hai lớp trong chuỗi thừa kế. Đợi tí; Lớp đó thực hiện một giao diện? Có bao nhiêu lớp khác nhau thực hiện giao diện đó? Và chúng tôi đang sử dụng một số hệ thống thời gian chạy phức tạp (tôi đang nhìn vào bạn, Spring) để "kết nối" các lớp trong thời gian chạy? Trường hợp BẤT K class lớp nào thực hiện giao diện đó có thể được sử dụng?

Bạn kết thúc với rất nhiều phương pháp nhỏ, riêng biệt làm những việc chính xác. Nhưng cái này gọi cái đó, trong một lớp khác. Mà gọi cái đó, trong một lớp khác. Mà gọi cái đó, trong lớp vẫn khác. Mà gọi cái đó, trong một lớp bổ sung. Mà trả về một kết quả của một loại cụ thể. Trên đó bạn phải gọi một phương thức để làm một việc nào đó. Mà trả về một kết quả của loại khác. Vân vân.

Có một thuật ngữ cho việc này: mã spaghetti.

Bạn kết thúc với một hệ thống rất phức tạp chỉ cần soạn mã. Do đó các IDE như Visual Studio, Eclipse và NetBeans. Tất cả đều có một đường cong học tập đáng kể. Thật vậy, nhiều trong số chúng có thể đóng gói / tổng hợp nhiều công cụ, được phát triển bởi các nhóm khác nhau, mỗi nhóm có đường cong học tập RIÊNG của chúng.

Đây là quản lý phức tạp?

Mã gỡ lỗi khó gấp đôi so với viết nó. Chúc may mắn gỡ lỗi một số thứ này. Đặc biệt là nếu nó sử dụng nhiều thư viện, "kết nối với nhau" trong thời gian chạy bằng cách sử dụng một số loại hệ thống tiêm phụ thuộc.

Tóm lại: OOP cung cấp những gì trông giống như một công cụ đầy hứa hẹn để giúp quản lý sự phức tạp. Thực tế là mã kết quả có xu hướng nở rộ khủng khiếp (vì bạn không thể trích xuất chỉ những phần bạn cần từ tất cả các thư viện được liên kết đó) và bạn cần các công cụ tinh vi chỉ để điều hướng mã. Nó nhanh chóng trở thành một cơn ác mộng bảo trì.

IMHO, đó là một mất mát ròng; nó thêm phức tạp hơn nó loại bỏ. Nó cho phép bạn làm những việc cực kỳ khó khăn, thậm chí là không thể, nếu không có nó. Nhưng bất kỳ dự án lớn nào cũng nhanh chóng phát triển thành một mớ hỗn độn không thể nhầm lẫn.

Nếu bạn đã biết nó hoạt động như thế nào và bạn có thể nhớ điều đó, bạn có thể có cơ hội duy trì nó.

Hãy nhớ áp dụng Luật Eagleson: bất kỳ mã nào của riêng bạn, mà bạn đã xem trong sáu tháng, cũng có thể được viết bởi người khác.

Đến một mức độ nào...

Tại sao? Bởi vì nó tạo điều kiện cho mô-đun rất logic. Ít nhất là so với lập trình thủ tục, nơi tất cả đều quá hấp dẫn khi chỉ viết những đống mã spaghetti khổng lồ.

Lý do lập trình hướng đối tượng dường như giúp chúng ta xử lý sự phức tạp là vì nó buộc chúng ta phải viết mã theo một kiểu cụ thể thay vì nhiều cách khác nhau. Lập trình hướng nhiệm vụ trực quan hơn nhiều, đó là lý do tại sao lập trình bắt đầu theo cách đó. Hướng đối tượng cần đào tạo và thực hành để hiểu và sử dụng hiệu quả, nhưng bằng cách hạn chế lập trình vào một đường dẫn nhất định, nó cho phép những người được đào tạo duy trì hiệu quả mã được viết.

Nó không logic hay thế giới thực hơn bất kỳ phương pháp nào khác, đó chỉ là một cách tập trung giải quyết vấn đề của chúng tôi thông qua các ống kính tương tự. Rất nhiều chuyên ngành kỹ thuật sử dụng mô hình của một phương pháp cứng nhắc không trực quan để xử lý sự phức tạp của các nhiệm vụ của họ.

Một phương pháp thứ ba để xử lý sự phức tạp sẽ là lập trình chức năng và có thể sẽ có các phương thức mới khác trong tương lai.

Tôi nghĩ rằng đó là một giải pháp cho khả năng bảo trì, bởi vì, là một lập trình viên, bạn phải đặt các phương thức trong đó bạn có dữ liệu, do đó tạo ra một mô hình đối tượng của ứng dụng của bạn.

vâng, đó cũng là một giải pháp cho sự phức tạp bằng cách cung cấp một mô hình để bạn "nhìn" mã của mình một cách tự nhiên, như các đối tượng có các thuộc tính và hành động có thể