Lập trình hướng đối tượng

Question

Tôi đang phát triển một dự án trong C++. Tôi nhận ra rằng chương trình của tôi không phải là OO.

Tôi có một main.cpp và một số tiêu đề cho các mục đích khác nhau. Mỗi tiêu đề về cơ bản là một tập hợp các hàm liên quan với một số biến toàn cục để giữ lại dữ liệu. Tôi cũng có một windowing.h để quản lý các cửa sổ. Điều này chứa winMain() và winProc(). Nó gọi các hàm nằm trong main.cpp của tôi khi các sự kiện xảy ra (như nhấn vào một nút) hoặc khi nó cần thông tin (như 'lớn như thế nào để tạo cửa sổ này?'). Các hàm này được khai báo trong một tệp .h riêng biệt được bao gồm trong windowing.h.

Có đáng để thay đổi điều này thành OO không? Có đáng để làm việc không. Có cách nào tốt hơn tôi có thể xây dựng chương trình mà không có quá nhiều thay đổi không?

Tất cả phản hồi chào mừng, cảm ơn bạn đã dành thời gian đọc nội dung này.

Answer 1

Không, tôi nghĩ nếu nó không bị hỏng, đừng sửa nó.

Bất kỳ hệ thống cửa sổ nào cũng là OO ở một mức độ. Bạn có một xử lý đến một cửa sổ được quản lý bởi hệ điều hành, và bạn có thể thực hiện một số hoạt động trên nó. Việc bạn sử dụng window->resize() hoặc resize(window) là không quan trọng. Rõ ràng không có giá trị trong việc sắp xếp cú pháp như vậy.

Tuy nhiên, khi ứng dụng phát triển, bạn có thể sẽ thấy rằng nhiều cửa sổ hầu như giống nhau và khác nhau một cách tinh tế. Việc thực hiện tốt nhất là chức năng cơ bản boilerplate với các chức năng đặc biệt kèm theo. Và cách để làm điều đó là với một lớp cơ sở và đa hình.

Vì vậy, nếu bạn có thể cấu trúc lại chương trình để thanh lịch hơn với OO, hãy thực hiện nó. Nếu nó phát triển thành mô hình OO với sự tiến hóa tự nhiên, hãy làm theo các phương pháp hay nhất và để nó như vậy. Nhưng không chỉ cố gắng tuân thủ từ khóa.

Answer 2

Tùy thuộc vào những gì bạn muốn thực hiện với dự án. Nếu không sử dụng các tính năng OO của C++ làm việc cho bạn và không có lý do chính đáng để thay đổi, thì hãy tiếp tục theo cách bạn đang đi. Nếu, mặt khác, bạn muốn tìm hiểu thêm về OOP và bạn có thời gian để áp dụng cho nó, tái cấu trúc nó để có nhiều phong cách OO sẽ cung cấp cho bạn một cơ hội học tập tuyệt vời.

Answer 3

Tôi sẽ thực hiện theo các phương pháp hay nhất để làm việc với bất kỳ trình quản lý cửa sổ nào bạn đang sử dụng. Hầu hết sử dụng kiểu OO, bạn sẽ tự động kế thừa (!) Khi bạn làm theo các mẫu sử dụng của nó.

Answer 4

Hai điều bạn cần suy nghĩ: phân tích chi phí/lợi ích và chi phí cơ hội.

Chi phí thay đổi mã của bạn thành OO là bao nhiêu? Lợi ích là gì? Nếu sau này lớn hơn trước đây, sau đó tôi có xu hướng thay đổi nó.

Chi phí bao gồm các chi phí truyền thống như thời gian, tiền chi tiêu, v.v. Lợi ích bao gồm việc triển khai sạch hơn, dẫn đến việc bảo trì dễ dàng hơn trong tương lai. Bất kỳ chi phí và lợi ích nào khác phụ thuộc vào hoàn cảnh của bạn.

Nhưng một điều thường bị bỏ qua là chi phí cơ hội. Điều này là chi phí phải được tính vào phân tích của bạn. Đó là một thuật ngữ kinh tế có nghĩa là cơ hội bỏ qua.

Nói cách khác, nếu bạn chuyển đổi mã của mình, chi phí của bạn bao gồm không có khả năng làm điều gì đó khác với thời gian đó.

Ví dụ điển hình.Nếu bạn thực hiện chuyển đổi và khách hàng quyết định không mua phần mềm của bạn vì bạn không thêm tính năng họ muốn, thì cơ hội bán hàng bị mất đó là chi phí.