[
https://issues.apache.org/jira/browse/HDFS-6940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14125224#comment-14125224
]
Todd Lipcon commented on HDFS-6940:
-----------------------------------
I'll only comment on the technical issue at hand here:
I strongly agree that implementation inheritance/subclassing is not a
maintainable extension mechanism for the NameNode. The issue is that, while
composition through interfaces and peer class relationships can be well defined
and documented and typically does not expose implementation details, making
previously private methods public is doing exactly that. When we later want to
reorganize the (implementation-specific) code of the NameNode, the existence of
subclasses makes this very difficult.
This is not an abstract argument. I experienced this pain first hand several
years ago when working on HDFS-1073, and then again working on HDFS-1623. When
methods and members are protected, then doing these kind of refactors becomes
quite arduous -- the implementations of the base (NameNode) and the plugin
(BackupNode in that case) are very tightly coupled, and tight coupling makes
changes difficult.
Can we lay out which specific plug points you need to make ConsensusNode work
and define interfaces for them instead of using overriding/subclasses?
> Initial refactoring to allow ConsensusNode implementation
> ---------------------------------------------------------
>
> Key: HDFS-6940
> URL: https://issues.apache.org/jira/browse/HDFS-6940
> Project: Hadoop HDFS
> Issue Type: Sub-task
> Components: namenode
> Affects Versions: 2.0.6-alpha, 2.5.0
> Reporter: Konstantin Shvachko
> Assignee: Konstantin Shvachko
> Fix For: 2.6.0
>
> Attachments: HDFS-6940.patch
>
>
> Minor refactoring of FSNamesystem to open private methods that are needed for
> CNode implementation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
