OOP trở nên dễ dàng hay khó hơn? [đóng cửa]

Khi các khái niệm về lập trình hướng đối tượng được giới thiệu cho các lập trình viên từ nhiều năm trước, nó có vẻ thú vị và lập trình sạch hơn. OOP là như thế này

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);

Điều đó dễ hiểu hơn với tên tự mô tả.

Nhưng giờ đây, OOP, với mô hình như Đối tượng truyền dữ liệu, Đối tượng giá trị, Kho lưu trữ, Tiêm phụ thuộc, v.v., đã trở nên phức tạp hơn. Để đạt được những điều trên, bạn có thể phải tạo một số lớp (ví dụ: trừu tượng, nhà máy, DAO, v.v.) và Thực hiện một số giao diện

Lưu ý: Tôi không chống lại các thực tiễn tốt nhất giúp Cộng tác, Kiểm tra và Tích hợp dễ dàng hơn

Bản thân OOP đã không thay đổi nhiều kể từ khi thành lập. Một vài góc độ mới cho nó đã được khám phá, nhưng các nguyên tắc cốt lõi vẫn giống nhau. Nếu bất cứ điều gì, kiến ​​thức tập thể được thu thập qua nhiều năm làm cho cuộc sống của lập trình viên dễ dàng hơn thay vì khó khăn hơn. Các mẫu thiết kế không phải là một trở ngại; họ cung cấp một hộp công cụ giải pháp cho các vấn đề tiêu chuẩn, được chắt lọc từ nhiều năm và nhiều năm kinh nghiệm.

Vậy tại sao bạn nhận thấy OOP ngày nay phức tạp hơn so với khi bạn bắt đầu sử dụng nó?

Một lý do có thể là mã bạn đang tiếp xúc trở nên phức tạp hơn - không phải vì OOP trở nên phức tạp hơn, mà bởi vì bạn đã tiến lên nấc thang học tập và đọc các cơ sở mã lớn hơn và phức tạp hơn.

Một lý do khác có thể là trong khi mô hình phức tạp không thay đổi, kích thước và độ phức tạp của một dự án phần mềm trung bình rất có thể có. Với sức mạnh xử lý có sẵn trên các điện thoại di động cấp khách hàng từng là giấc mơ ướt của nhà phát triển trên máy chủ cách đây chưa đầy hai thập kỷ, công chúng nói chung về cơ bản mong đợi GUI hoạt hình mượt mà cho ứng dụng vứt bỏ rẻ nhất và máy tính để bàn cấp thấp mạnh hơn so với "siêu máy tính" năm 1980, chỉ có điều tự nhiên là thanh này đã được nâng lên từ những ngày đầu của Smalltalk và C ++.

Và sau đó, có một thực tế là trong các ứng dụng hiện đại, đồng thời và song song là chuẩn mực chứ không phải là ngoại lệ, và các ứng dụng thường cần phải giao tiếp giữa các máy khác nhau, xuất ra và phân tích toàn bộ sở giao thức. Mặc dù OOP là một mô hình tổ chức tuyệt vời, nhưng nó cũng có những hạn chế của nó, giống như bất kỳ mô hình nào khác: ví dụ, nó không cung cấp nhiều sự trừu tượng cho đồng thời (hầu hết các triển khai đều ít nhiều được đưa ra ngoài hoặc hoàn toàn cho các thư viện) và đó không phải là cách tiếp cận tốt nhất có thể để xây dựng trình phân tích cú pháp và chuyển đổi dữ liệu. Lập trình hiện đại thường xuyên gặp phải những hạn chế của mô hình OOP và các mẫu thiết kế chỉ có thể đưa bạn đến nay. (Cá nhân, Tôi coi thực tế là chúng ta cần các mẫu thiết kế là một dấu hiệu của điều này - nếu mô hình cung cấp các giải pháp này vượt trội, nó sẽ có ý nghĩa hơn đối với các vấn đề này và các giải pháp tiêu chuẩn sẽ rõ ràng. Không có mẫu thiết kế để mô tả kế thừa phương thức, bởi vì nó là một tính năng cốt lõi của OOP; nhưng có một Mô hình Nhà máy, vì OOP không cung cấp một cách tự nhiên rõ ràng để xây dựng các đối tượng đa hình và trong suốt.)

Bởi vì điều này, hầu hết các ngôn ngữ OOP hiện đại kết hợp các tính năng từ các mô hình khác, khiến chúng trở nên biểu cảm hơn và mạnh mẽ hơn, nhưng cũng phức tạp hơn. C # là ví dụ điển hình cho việc này: nó có nguồn gốc OOP rõ ràng, nhưng các tính năng như đại biểu, sự kiện, suy luận kiểu, kiểu dữ liệu biến thể, thuộc tính, hàm ẩn danh, biểu thức lambda, tổng quát, v.v., bắt nguồn từ các mô hình khác, đáng chú ý nhất là Lập trình hàm .

Không, nó trở nên quá kỹ thuật. Và bạn nói đúng trong cuộc trò chuyện SO C ++, chúng tôi thường nói đùa về AbstractSingletonFactoryProxyBeanBridgeAd ModuleQuản lý mà chúng ta thấy trong mã Java.

Nhưng mã tốt không thể hiện tài sản này. Trong mã tốt, bạn vẫn có thể nói

std::stack<int> s;
s.push(5);
s.pop();

Tôi muốn nói rằng các vấn đề với "sự phức tạp" mà bạn đề cập không liên quan gì đến OOP. Nó có nhiều hơn để làm với các mối quan tâm riêng biệt.

Nhiều năm trước tôi đã làm việc trên một hệ thống, trong đó lớp miền có trách nhiệm tự tải từ cơ sở dữ liệu, vd

var userId = Request.QueryString["UserID"].ToInt();
var user = new User(userId);
user.Name = ...;
...
user.Save();

Đây là mã rất rõ ràng. Không có vấn đề trong việc hiểu điều này. Tuy nhiên, vấn đề sẽ nằm ở đơn vị kiểm tra mã. Cụ thể, làm thế nào tôi đơn vị kiểm tra Userlớp mà không phải tải một từ cơ sở dữ liệu? Và làm cách nào để kiểm tra mã xử lý yêu cầu web này mà không cần truy cập vào cơ sở dữ liệu? Nó chỉ đơn giản là không thể.

Đó là lý do tại sao chúng ta có một mẫu giống như một kho lưu trữ, để tách trách nhiệm xử lý logic miền khỏi người dùng khỏi chức năng thực sự tải và lưu một mẫu trong kho lưu trữ dữ liệu. IOC giúp giảm khớp nối, cũng làm cho mã dễ kiểm tra hơn, v.v.

Vì vậy, nếu chúng ta quay lại ví dụ bạn viết, bạn sẽ làm gì với cổ phiếu sau khi bạn tạo nó? Lưu nó trong cơ sở dữ liệu

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);
this.StockRepository.Add(stock);

Thế là xong! Không có sự chuyển động nào trong quá trình tiến triển của OOP cho thấy rằng nó sẽ khó hơn nữa. Thật không may, nếu bạn chọn sử dụng trình ánh xạ OR cho mã truy cập dữ liệu của mình, bạn có thể gặp phải vấn đề mà trình ánh xạ OR đang đặt ra các hạn chế về cách bạn có thể viết hệ thống của mình. Nhưng đó là một vấn đề khác.

Nếu bạn chưa quen với các mẫu này, bạn có thể yêu cầu học một phong cách lập trình mới. Nhưng phong cách lập trình đó không khó hơn lập trình OOP cũ.

Cũng không. Vấn đề của chúng tôi chưa thực sự thay đổi; thanh mã được chấp nhận đã được nâng lên.

Để đạt được những điều trên, bạn có thể phải tạo một số lớp (ví dụ: trừu tượng, nhà máy, DAO, v.v.) và Thực hiện một số giao diện

Bạn không cần phải làm điều đó. Nhưng nếu bạn không gặp vấn đề thì hãy trồng trọt; những vấn đề luôn luôn tồn tại Bây giờ mặc dù, các lập trình viên có đủ kinh nghiệm làm việc đó để xác định những vấn đề đó và cung cấp các cơ chế để giảm bớt chúng (nếu cần). Chúng tôi tìm hiểu thêm về những điều đó và đưa ra các giải pháp tốt hơn (xem - quan điểm của các lập trình viên về singleton chẳng hạn).

Nhưng bạn cũng phải nhận ra rằng việc giới thiệu các lập trình viên cho OO (hoặc bất cứ điều gì cho vấn đề đó) sẽ có xu hướng bóng bẩy trong các trường hợp đặc biệt. Đơn giản là dễ dàng hơn để giải thích con đường hạnh phúc và lo lắng về phần còn lại một khi những người mới bắt đầu có được điều đó. Không có viên đạn bạc; Vì vậy, yeah, tôi cho rằng mọi thứ sẽ luôn luôn có vẻ khó khăn hơn khi mà ảo tưởng bình dị được chia ...

Các ví dụ "giới thiệu về OO" đơn giản hơn nhiều so với ứng dụng trong thế giới thực. Bạn chỉ cần một lớp để đạt được những điều trên. Vấn đề là nó không làm được gì nhiều. Một số mẫu thiết kế cố gắng đến gần (như ActiveRecord.) Nhưng cuối cùng, bất kỳ ví dụ nào không tầm thường sẽ có nhiều hơn một lớp; được thôi.

Các ngôn ngữ lập trình sử dụng OO ngày nay đang cố gắng phục vụ cho các yêu cầu và môi trường phức tạp luôn thay đổi. OO cho phép những người áp dụng của nó che giấu nhiều mức độ phức tạp (trong số các tính năng khác) để mã hóa trở nên rõ ràng hơn và dễ xây dựng và dễ hiểu hơn. Tuy nhiên, tính năng này không phải lúc nào cũng nằm ngoài khả năng này. Trong ví dụ của bạn, OO đã cho phép bạn ẩn một số chi tiết với tôi bằng cách cung cấp phương thức để quản lý các mục trong bộ sưu tập và thậm chí có thể duy trì nó bằng phương pháp "AddItem". Chi tiêu nỗ lực trong việc che giấu sự phức tạp có thể dẫn đến một cách dễ sử dụng và một khuôn khổ có thể sử dụng lại làm cho cuộc sống đơn giản hơn. Ví dụ, nhiều triển khai ORM cho phép bạn giao tiếp với cơ sở dữ liệu mà không cần lập trình viên viết chi tiết SQL. Điều này thực sự mạnh mẽ và làm cho nó đơn giản hơn trên nhà phát triển.

Các mẫu bạn đề cập đến chỉ có vậy. Họ được cho là để làm cho cuộc sống của bạn dễ dàng hơn. Nhưng nó là tùy thuộc vào bạn để áp dụng chúng và điều chỉnh chúng. Thực tế là cần nhiều công việc hơn chỉ vì bạn đạt được nhiều lợi ích hơn. Nó giống như trả nhiều tiền hơn cho một chiếc Ferrari. Nếu bạn muốn các tính năng bổ sung, bạn phải trả tiền cho họ. Vì vậy, nếu bạn quyết định xây dựng một giải pháp N-Tier có thể mở rộng có thể chạy trên một số máy chủ và cơ sở dữ liệu phụ trợ khác nhau, thì sẽ phải trả giá cho việc đó. Nếu ứng dụng của bạn không yêu cầu sự phức tạp này, hãy bỏ qua các phần bổ sung và quay lại giải pháp đơn giản nhất đáp ứng nhu cầu của bạn (KISS & YAGNI).

Vì vậy, để kết thúc, tôi không nghĩ rằng OOP như một khái niệm ngày càng phức tạp hơn, chúng tôi, những người dùng OOP có quyền lựa chọn sử dụng nó theo những cách khác nhau, và đó là một điều tốt.

Câu trả lời ngắn : Có, bởi vì bạn đối phó với các vấn đề khó khăn hơn.

Câu trả lời dài (thiên vị mạnh mẽ) : Đối với tôi các mẫu thiết kế thường chỉ ra rằng một số mô hình có vấn đề trong khu vực nhất định. Các mẫu OOP xử lý các vấn đề của OOP (ở cấp độ thấp hơn các mẫu Java xử lý các vấn đề của Java), các mẫu FP xử lý các vấn đề của FP, v.v.

Trong quá trình lập trình bạn có thể có những ưu tiên khác nhau. Bạn có thể muốn có chương trình chính xác, bạn có thể muốn rút ngắn thời gian tiếp thị, chương trình nhanh nhất có thể, khả năng duy trì dài hạn hoặc khả năng duy trì ngay lập tức bằng cách thuê mới. Tùy thuộc vào độ rậm rạp của bạn, bạn sẽ có sự khác biệt lớn - nếu bạn là người điều khiển lập trình của nhà máy điện, bạn muốn thực hiện ngay lần đầu tiên và không phải sửa lỗi mỗi lần sau đó ("Meltdown có xảy ra mỗi khi bạn nhấn Ctrl+Alt+Delkhông?"). Nếu bạn ở trong HPC, logic có thể đơn giản tương đối nhưng bạn muốn thực thi nó nhanh nhất có thể, v.v. Ngoài ra, một số mô hình phù hợp với một số vấn đề nhất định hơn (ví dụ như lập trình AI và logic, dữ liệu và cơ sở dữ liệu quan hệ).

OOP là một số mở rộng 'quá tốt' trong các trường hợp đơn giản và đó là câu chuyện "mô hình hóa cuộc sống thực". Ví dụ trong cuốn sách đầu tiên về OOP tôi đọc đã có các lớp học Person, Employeevà Managervới is-amối quan hệ. Cho đến nay rất tốt nhưng nếu nhân viên được thăng chức lên quản lý thì sao?

Mặt khác, các mô hình khác có những bài học lần đầu khó hơn - ví dụ như FP với các biến số bất biến (điều buồn cười là những người có kinh nghiệm lập trình thường khó học hơn những người mà đây là ngôn ngữ đầu tiên) - tuy nhiên cuối cùng họ là không khó hơn OOP. Kiểm tra các hàm thuần túy là chuyện nhỏ và trong Haskell / Scala / ... bạn có các công cụ tạo các bài kiểm tra cho mình.

Tái bút Có - câu trả lời thiên vị so với OOP và tôi thừa nhận rằng với một số người mở rộng thì đó là 'phản ứng' với OOP. OOP có công dụng của nó nhưng nó không phải là giải pháp tối ưu duy nhất theo quan điểm của tôi.

PPS. Có - sử dụng các mẫu thiết kế - chúng làm cho việc lập trình OOP đơn giản hơn.

PPPS. Tôi đã sử dụng OOP như từ đồng nghĩa của lập trình mệnh lệnh OOP.

Tôi nghĩ đó là một trường hợp của các tài liệu và ví dụ trở nên thực tế hơn.

Các sách OOP ban đầu (đặc biệt là các sách Java sớm) đã trình bày một quan điểm đơn giản hóa vô lý về lập trình ứng dụng. Các ví dụ "Ghi nợ tài khoản ngân hàng với chương trình Java 10 dòng" luôn đặc biệt khó chịu vì tôi đã thấy các ví dụ thực tế của tác vụ đơn giản này chạy tới 6000 dòng mã COBOL (và nỗ lực thay thế Java chạy tới 3500 dòng trước khi bị bỏ rơi như không khả thi!).

Rất may, các sách OO hiện có xu hướng thừa nhận sự phức tạp của cuộc sống thực và cung cấp các ví dụ hữu ích về cách đối phó với chúng.

Nhưng nếu bạn muốn xem cách chạy tài khoản ngân hàng chỉ trong 15 dòng lập trình chức năng mã là người đàn ông của bạn