[jira] [Commented] (SAMZA-1160) Migrate MapConfig inherited Java classes to use composition over inheritance

["Navina Ramesh (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SAMZA-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15937418#comment-15937418 ] 

Navina Ramesh commented on SAMZA-1160:
--------------------------------------

[~fredji] This is a bold proposal considering the number of places where we need to make the change. But you are right that the result of using inheritance has polluted the config scopes. +1 for composition approach, although in-time we should have a more elaborate proposal. Thanks! 

> 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
>
> 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.3.15#6346)