OOP tốt hay xấu?

Question

Giả sử có một lớp trừu tượng với một hàm tạo gọi một phương thức trừu tượng được bảo vệ chưa được lớp con thực hiện. Đây có phải là một ý tưởng tốt hay xấu? Tại sao?

Answer 1

Đây là một ý tưởng tồi.

Về cơ bản, bạn đang tạo ra sự đảo ngược kiểm soát trong một hàm tạo. Phương thức trong lớp cơ sở đang được gọi được gọi trước khi dữ liệu lớp cơ sở được khởi tạo (trong hầu hết các ngôn ngữ), cũng rất nguy hiểm. Nó có thể dễ dàng dẫn đến hành vi không xác định.

Hãy nhớ rằng, trong hầu hết các ngôn ngữ, khi bạn xây dựng một lớp, tất cả các cấu trúc lớp cơ sở sẽ chạy trước tiên. Vì vậy, nếu bạn có một cái gì đó như: MyClass() : MyBaseClass() {}, thông thường, hàm xây dựng của MyBaseClass chạy toàn bộ, thìMyClass của hàm tạo thi hành. Tuy nhiên, bằng cách sử dụng một phương thức ảo trong lớp cơ sở, bạn đang gọi một phương thức cá thể trong MyClass trước khi nó được khởi tạo hoàn toàn - điều này có thể rất nguy hiểm.

Answer 2

Đây là một ý tưởng tồi, bởi vì trong hầu hết các ngôn ngữ OOP, đứa trẻ được khởi tạo sau khi cha mẹ được khởi tạo. Nếu chức năng trừu tượng được thực hiện trong đứa trẻ, sau đó nó có thể hoạt động trên dữ liệu trong các con theo giả định không chính xác rằng nó đã được khởi tạo, mà không phải là trường hợp trong xây dựng cha mẹ.

Ví dụ:

class Base { 
    public: 
     Base() { virtualInit(); } 
     virtual ~Base() {} 
    protected: 
     virtual void virtualInit() {} 
}; 

class Derived : public Base { 
    public: 
     Derived() : ptr_(new SomeObject) {} 
     virtual ~Derived() {} 
    protected: 
     virtual void virtualInit() { 
       // dereference ptr_ 
     } 
    private: 
     scoped_ptr<SomeObject> ptr_; 
}; 

Trong ví dụ trên, Base::Base() được thực hiện trước khi Derived::Derived(), đó là trách nhiệm khởi ptr_. Do đó, khi virtualInit() được gọi là từ Base::Base() nó dereferences một con trỏ uninitialized, dẫn đến tất cả các loại rắc rối. Đây là lý do tại sao ctors và dtors chỉ nên gọi các hàm không phải ảo (trong C++), các hàm cuối cùng (trong Java), hoặc tương đương với ngôn ngữ cụ thể.

Answer 3

Tôi không thể thấy lý do tại sao bạn muốn làm điều này, hãy để một mình hội đủ điều kiện. Có vẻ như bạn đang cố tiêm một số chức năng vào đối tượng. Tại sao bạn không chỉ quá tải constructor hoặc tạo một thuộc tính có thể được thiết lập để bạn có thể inject các chức năng thông qua composition hoặc thậm chí tạo constructor với tham số là đối tượng IOC.

Khi người khác đã đăng, điều đó phụ thuộc vào ngữ cảnh mà trong đó bạn đang cố giải quyết một vấn đề cụ thể. Sự phù hợp tự nhiên sẽ tuân thủ một giao diện, phát triển một lớp trừu tượng và quá tải các hàm tạo trong mỗi lần thực hiện. Nếu không có thêm thông tin, tôi chỉ có thể bình luận về những gì đã được đăng trong câu hỏi của bạn.

Thiết kế này bạn không thể coi là tốt hay xấu. Chỉ đơn giản là từ thực tế rằng nó có thể là cách duy nhất bạn có thể đạt được những gì bạn đang cố gắng làm.

Answer 4

Chỉ sau đó là một ý tưởng TỐT, IFF bạn có thể quản lý nó để không bắn vào chân của bạn. Nhưng dù sao, OOP luôn dễ bị thiết kế xấu; vì vậy nếu ngôn ngữ của bạn cho phép các mô hình khác hơn OOP, để sử dụng OOP trong trường hợp này chắc chắn là một sự lựa chọn BAD.

Ít nhất trong C++, lớp con xác định trình tự tất cả các khởi tạo được tạo; đó là khởi tạo của tất cả các biến thành viên và các hàm tạo của tất cả các lớp cha. Điều này đã được xem xét!

Hoặc, bạn có thể cung cấp cho hàm tạo (như tham số) một con trỏ tới một hàm cụ thể (tôi thích các hàm tĩnh), thay vì gọi hàm trừu tượng thành viên.Đây có thể là một giải pháp thanh lịch và lành mạnh hơn nhiều; và đây là giải pháp thông thường trong (có thể là tất cả) ngôn ngữ không phải là OOP. (trong java: Một con trỏ trỏ tới một hàm hoặc một danh sách các hàm là mẫu thiết kế của một giao diện và ngược lại.)