我仍在学习 Go 的做事方式，来自 C++ 背景。我正在寻找将 OOP 继承与接口(interface)组合进行对比的反馈。

我在 Go 程序中有一个设计情况，如果我在 C++ 中实现，我将使用抽象基类来解决。

假设我需要一个基类，它有很多实现者。基类具有处理抽象数据项的共享方法。不同的 Worker 实现提供了对不同 item 类型的 CRUD 操作，但是 worker 都使用基类的共享方法进行一般工作。

在 C++ 中我可能会这样做

class IItem
{
    // virtual methods
};

class IWorker
{
public:
    // one of many virtual functions that deal with IItem CRUD
    virtual IItem* createItem() = 0; 

    // concrete method that works on interfaces
    void doWork()
    {
        IItem* item = createItem();
        // do stuff with an IItem*
    }

};


class Toy : public IItem
{

};

// one of many kinds of workers
class ElfWorker : public IWorker
{
public:

    ElfWorker()
    {
        // constructor implicitly calls IWorker()
    }

    IItem* createItem() override
    {
        return new Toy;
    }
};

在 Go 中，您没有抽象虚方法，例如 IWorker::createItem()。具体类需要为基础提供一个接口(interface)或函数来做正确的事情。

所以我认为 ew.ItemCRUD 接口(interface)的 Go 代码必须明确设置一个指向 ElfWorker 的指针。

小 Sprite 知道如何创建 Item()，在他的例子中恰好是 Toy 对象。其他工作人员将为他们的数据对象实现他们自己的 ItemCRUD。

type Item interface {                         
    // various methods                                                                                
}
type ItemCRUD interface {                                                                             
    create() Item                                                                                     
    // other CRUD                                                                                     
}                                                                                                     

type Worker struct {
    ItemCRUD  // embedded interface                                                                                        
}                                                                                                     
func (w *Worker) doWork() {
    item := w.create()                                                                                
    // do stuff with item                                                                          
}

type Toy struct {
}

type ElfWorker struct {                                                                               
    Worker // embedded                                                                                
    // ..
}       

func NewElfWorker() *ElfWorker {                                                                      
    ew := &ElfWorker{}                                                                                
    ew.ItemCRUD = ew // <-- #### set Worker ItemCRUD  explicitly ####                                                  
    return ew                                                                                         
}                                                                                                     

func (ew *ElfWorker) createItem() Item {
    return &Toy{}                                                                                     
}
// more ElfWorker Item CRUD
func bigFunction(w *Worker) {                                                                     
    // ...                                                                                            
    w.doWork()  
   // ..                                                                                       
}   

因此，我正在努力解决的部分是显式设置。如果我希望基 Worker 类在 Items 上提供共享方法，似乎组合的“Go way”确实需要这个显式步骤。

想法？

最佳答案

我自己是新手，这个答案没有多年经验的支持:-)

我不知道，您处理此问题的方式是否正确。 go 允许在没有显式声明的情况下实现接口(interface)。如果您有 Sprite ，并且需要它们执行 ItemCRUD 方法，只需实现它们即可。

然后方法集将匹配接口(interface)，您可以在需要时将小 Sprite 用作 ItemCRUD。

要为任何 elf 对象提供默认的 ItemCRUD 实现，您应该为 ItemCRUD 实现一个适配器，并将适配器与您的抽象 elf 组合在一起。抽象方法可以有一个默认实现，如 log.Fatal("not implemented")

具体的 Sprite 隐藏了适配器的方法，这回答了你的问题:在创建过程中不需要插入对象。

然而，由于 go 没有泛型，因此使用 ItemCRUD 可能不是正确的方法。

关于go - Go 与 C++ 中的抽象基类设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/54011364/