dongxianghuan3587 2017-05-03 20:39
浏览 51
已采纳

go中的子类型

Coming from OOP paradigms and porting a code from an OOP language, I come across a problem now which is solved in OOP via abstraction so I'm wondering how can I approach the following problem in Go which follows composition instead of inheritance.

In this scenario my ValueObjects (DTO, POJO etc.) are composed of other ValueObjects. I'm populating them through web service calls that returns json so basically my functions/method calls are common for all types and subtypes.

My super type EntityVO

type EntityVO struct {
    EntityName    string
    EntityType    string
    PublicationId string
    Version       string
}

A subtype 1 composed with EntityVO

type ArticleVO struct {
    EntityVO
    ContentSize string
    Created     string
}

subtype 2 composed with EntityVO with it's own unique set of fields

type CollectionVO struct {
    EntityVO
    ProductId string
    Position string
}

I'm calling web services to retrieve data and populate these VOs.

Earlier I had one function to call the web service and populate the data but now I'm duplicating the code for each VO.

type Article struct{}

func (a *Article) RequestList(articleVO *valueObject.ArticleVO) (*valueObject.ArticleVO, error) { 
    // some code
}

Duplicating the same code but changing the signature.

type Collection struct{}

func (c * Collection) RequestList(collectionVO *valueObject.CollectionVO) (*valueObject.ArticleVO, error) { 
    // some code - duplicate same as above except method signature
}

and I've several entities and just because my VO's are different I'm forced to duplicate the code and cater to each type of VO I've. In OOP sub types can be passed to a function accepting super types but not in go, so wondering how it should be done so I don't end up duplicated code that's different in signature only?

Any advice for a better approach in this kind of scenario?

  • 写回答

2条回答 默认 最新

  • duanji5569 2017-05-04 14:39
    关注

    This is where golang interfaces can shine.

    It's worth noting, however, that it's difficult to write subclass/inheritance code in golang. We'd prefer thinking of it as composition.

    type EntityVO interface {
        GetName() string
        SetName(string) error
        GetType() string
        ...
    }
    
    type EntityVOImpl struct {
        EntityName    string
        EntityType    string
        PublicationId string
        Version       string
    }
    
    func (e EntityVOImpl) GetName() string {
        return e.EntityName
    }
    
    ...
    
    type ArticleVOImpl struct {
        EntityVOImpl
        ContentSize string
        Created     string
    }
    
    type CollectionVOImpl struct {
        EntityVO
        ProductId string
        Position string
    }
    
    // CODE
    
    func (e *Entity) RequestList(entityVO valueObject.EntityVO) (valueObject.EntityVO, error) { 
        // some code
    }
    

    In addition, as long as your interface files are shared, I don't think there should by any problem sending/marshalling/unmarshalling the structs over the wire.

    本回答被题主选为最佳回答 , 对您是否有帮助呢?
    评论
查看更多回答(1条)

报告相同问题?

悬赏问题

  • ¥100 任意维数的K均值聚类
  • ¥15 stamps做sbas-insar,时序沉降图怎么画
  • ¥15 unity第一人称射击小游戏,有demo,在原脚本的基础上进行修改以达到要求
  • ¥15 买了个传感器,根据商家发的代码和步骤使用但是代码报错了不会改,有没有人可以看看
  • ¥15 关于#Java#的问题,如何解决?
  • ¥15 加热介质是液体,换热器壳侧导热系数和总的导热系数怎么算
  • ¥100 嵌入式系统基于PIC16F882和热敏电阻的数字温度计
  • ¥15 cmd cl 0x000007b
  • ¥20 BAPI_PR_CHANGE how to add account assignment information for service line
  • ¥500 火焰左右视图、视差(基于双目相机)