[
https://issues.apache.org/jira/browse/SAMZA-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16312132#comment-16312132
]
Yi Pan (Data Infrastructure) commented on SAMZA-1160:
-----------------------------------------------------
[~fji], thanks for bringing up this point. +1 on the overall idea to change it
to composition rather then inheritance. The only additional point is that we
would need to be careful about public config classes in samza-api for backward
compatibility verification.
> Migrate MapConfig inherited Java classes to use composition over inheritance
> ----------------------------------------------------------------------------
>
> Key: SAMZA-1160
> URL: https://issues.apache.org/jira/browse/SAMZA-1160
> Project: Samza
> Issue Type: Task
> Reporter: Fred Ji
> Assignee: Fred Ji
> Fix For: 0.15.0
>
>
> In Samza code, we have a lot of classes with the name "*Config" which
> inherits from MapConfig but only intending to exposing the APIs for the
> specific configuration.
> For example, JavaStorageConfig, it currently extends MapConfig, but it only
> intends to manage/fetch storeNames and store related configs, but not other
> configs. With the inheritance, it does not have good encapsulation and it
> allows the object JavaStorageConfig to call any public API from MapConfig as
> well, for example, javaStorageConfig.get("yarn.resources.package.path"). With
> it, it mixes up the business logic for different types of Config.
> A proposal for addressing this is to do composition over inheritance, each
> type of Config, for example, JavaStorageConfig can have a member variable
> config which can leverage the interface of Config class (or the
> implementation of MapConfig) but not exposing the APIs of Config further
> down.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
