Details
-
Task
-
Status: In Progress
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
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.
Attachments
Issue Links
- incorporates
-
SAMZA-1541 migrate config classes in samza-yarn to use composition over inherence
- Open
-
SAMZA-1542 migrate config classes in samza-core to use composition over inherence
- Open
-
SAMZA-1543 migrate config classes in samza-kafka to use composition over inherence
- Open
-
SAMZA-1544 migrate config classes in samza-azure to use composition over inherence
- Open
-
SAMZA-1545 migrate config classes in samza-elasticsearch to use composition over inherence
- Open
-
SAMZA-1546 migrate config classes in samza-log4j to use composition over inherence
- Open
- relates to
-
SAMZA-40 Refactor Samza configuration
- Open