Mã thủ tục so với mã OOP

Tôi đã hoàn thành một dự án trong PHP gồm hơn 13000 dòng theo Phong cách thủ tục [vì tôi rất quen với điều đó, mặc dù tôi biết OOP] và dự án đang chạy hoàn hảo.

Nhưng tôi có nên chuyển đổi nó thành OOP không? [ vì thế giới bận rộn với OOP ]

Mã của tôi không cần bất kỳ tính năng nào của OOP [đóng gói, kế thừa về cơ bản ...]!

Vậy tôi phải làm sao?

Và tôi sẽ nhận được sự giúp đỡ nào nếu tôi chuyển đổi nó thành OOP?

Mã của tôi không cần bất kỳ tính năng nào của OOP

Bạn đã trả lời câu hỏi của riêng bạn - nếu bạn không cần OOP trong trường hợp này và dự án của bạn đang hoạt động thì đừng chuyển đổi nó.

Tuy nhiên, bạn nên xem xét việc sử dụng OOP cho dự án tiếp theo của bạn - nhưng chỉ khi nó phù hợp.

Về bản chất không có gì sai với lập trình thủ tục - miễn là nó được sử dụng ở nơi thích hợp.

Không và không chỉ vì bạn không cần OOP.

Nếu chương trình của bạn đã hoàn thành và hoạt động thỏa đáng thì hơn 90% thời gian, thật lãng phí thời gian để viết lại mã thành phẩm vì bất kỳ lý do gì.

OOP không phải là tất cả mạnh mẽ, có rất nhiều nơi không nên sử dụng OOP vì vậy đừng chỉ sử dụng nó vì OOP là xu hướng.

Tổng quát của tôi về các mô hình (và tại sao không có một trong ba mô hình chính là cách đúng hoặc sai cách lập trình):

Lập trình thủ tục là tốt khi bạn gặp một vấn đề đơn giản ở mức cao (mặc dù nó có thể phức tạp ở mức thấp) và muốn viết mã tuyến tính, đơn giản tương ứng. Có thể dễ dàng viết và hiểu hơn OO và chức năng nếu vấn đề không cần phải phân tách mạnh ở bất cứ đâu. Ví dụ: Mã số, hầu hết các tập lệnh nhỏ, hầu hết các bài toán con nhỏ một khi bạn đã phá vỡ mọi thứ bằng cách sử dụng OO hoặc chức năng.

Mã hướng đối tượng là tốt khi bạn cần phân tách mạnh các mối quan tâm bởi vì bạn có thể có nhiều hơn một triển khai một số mối quan tâm. Ví dụ: Hầu hết các phần mềm kinh doanh lớn. Ví dụ, bạn có thể muốn tách mạnh logic kinh doanh khỏi logic trình bày bởi vì có lẽ họ sẽ cần phải thay đổi độc lập.

Lập trình kiểu chức năng là tốt khi bạn cần tách mạnh cơ chế khỏi chính sách. Có chức năng cơ chế chấp nhận chức năng chính sách là một mẫu đẹp. (Tôi đã tìm hiểu về nó bằng cách xem mô-đun std.alacticm của ngôn ngữ lập trình D. ) Tóm tắt trạng thái có thể thay đổi ở ranh giới giữa mã chính sách và mã cơ chế nói chung giúp API dễ dàng suy luận hơn. Nếu trạng thái có thể thay đổi được sử dụng riêng trong một trong hai, đây là một chi tiết thực hiện. Thế mạnh khác của lập trình chức năng là đồng thời, vì lý do rõ ràng.

Mã không bao giờ "cần OOP". Đó là những lập trình viên, trong chừng mực họ có thể suy nghĩ ở các chế độ khác nhau, họ hình dung rằng vấn đề này hoặc vấn đề cụ thể đó "cần" $ PARADIGM hoặc được giải quyết tốt nhất theo cách đó.

Nó thường là trường hợp mà các lập trình viên chỉ biết một mô hình nghĩ rằng mô hình của họ là lớn nhất. Một kích thước phù hợp với tất cả, và tất cả chúng ta đều phải ngủ trên giường của Procrustes, nếu cái này hay cái đó hiện đang là mốt.

Bạn chỉ nên chuyển đổi dự án của mình thành OOP nếu có dấu hiệu rõ ràng về nhu cầu OOP. Các tình huống có thể xảy ra trong đó có thể xảy ra (trong số những trường hợp khác):

• nhân rộng dự án
• thêm nhiều nhà phát triển vào nhóm

và ngay cả trong các kịch bản này, có thể vẫn không cần thiết phải chuyển đổi dự án của bạn sang OOP.

Cả hai đều có thể tốt, cả hai đều có thể xấu. Nhưng trang bị thêm một cái để trông giống cái kia không bao giờ là một ý tưởng hay.

Nếu bạn nghĩ lại lý do tại sao OO được phát minh, bạn sẽ thấy rằng bạn hoàn toàn không cần OOP, nhưng đôi khi nó giúp cuộc sống của bạn dễ dàng hơn rất nhiều.

Quay trở lại thời kỳ mã hóa C, một chương trình rất lớn có thể trở nên khá lộn xộn và khó tiếp tục hoạt động. Vì vậy, họ đã phát minh ra cách chia nó thành các phần mô-đun. OOP sử dụng cách tiếp cận này và làm cho nó trở nên mô đun hơn, đặt dữ liệu với các đoạn logic chương trình đó để chúng thậm chí tách biệt hơn với phần còn lại của mã.

Điều này cho phép bạn viết các chương trình lớn hơn và lớn hơn, an toàn rằng bạn đã thay đổi một con voi khổng lồ của một nhiệm vụ thành một trăm nhiệm vụ cỡ chuột. Phần thưởng thêm vào là bạn có thể lấy một số 'chuột' này và tái sử dụng chúng trong các chương trình khác!

Tất nhiên, thế giới thực không hoàn toàn như vậy và việc tái sử dụng đối tượng không bao giờ hoàn toàn bị cuốn theo cách nó được dự định, nhưng điều đó không có nghĩa đó là một mô hình vô dụng.

Điều vô dụng là sự phụ thuộc quá mức vào một trong hai phong cách mã hóa. Bất cứ ai làm OO với hàng ngàn lớp học nhỏ, không đáng kể đều không thực sự đúng - họ đang tạo ra cơn ác mộng bảo trì cho chính họ (hoặc người khác). Bất cứ ai viết một ứng dụng thủ tục chỉ có 3 chức năng cũng khiến cuộc sống trở nên khó khăn. Cách tốt nhất là mặt đất trung gian, các vật thể lớn (đôi khi được gọi là các thành phần mà chúng ta sẽ tìm thấy một lần) có thể cung cấp một lượng lớn mã và dữ liệu độc lập có nhiều khả năng được sử dụng lại trong sự cô lập với phần còn lại của ứng dụng của bạn.

Lời khuyên của tôi cho lần tới: hãy thử viết mã thủ tục thông thường của bạn, nhưng tạo một đối tượng duy nhất trong cấu trúc dữ liệu chính của bạn. Xem cách bạn thấy rằng làm việc với nó dễ dàng hơn là truyền dữ liệu từ chức năng này sang chức năng khác.

Mã của tôi không cần bất kỳ tính năng nào của OOP [đóng gói, kế thừa về cơ bản ...]!

Làm sao bạn biết điều đó?

Bạn có cần phải duy trì dự án này? Có bất kỳ tính năng mới theo kế hoạch? Sẽ có những người khác sẽ phát triển cùng bạn? Bạn đã lặp lại chính mình? Là mã khó nắm bắt?

Nếu câu trả lời là "có", có lẽ bạn nên bắt đầu suy nghĩ về việc thiết lập bộ xương OOP và đi theo cách này.