> This means that the configuration classes should be public then, right?
Yes, if the parameters they access should be publicly accessible. One might argue that certain parameters are only consumed internally and don't need public accessors, but, more typically, parameter accessors are on public classes.
> And it doesn't matter where the get/setters are.
> Particularly we can combine all of them in one class
> or even place them in the Configuration class. Is it what you want?
They shouldn't be all in one place or all in Configuration for the same reason that we don't put everything in a single file: we should attempt to keep related things together, to localize changes. So an HDFS-specific parameter accessor should be on an HDFS-specific class. How fine-grained we localize isn't clear. Generally, finer is better: find the most-specific public class that encompasses the use and add the accessor there. So if something's only used in the Datanode, but used in a few different classes there, then it might best be on Datanode.
> What I meant is that we keep placing logically independent
> code inside e.g. FSNamesystem, which makes it bigger, while it could easily be made a separate class.
> And configuration is just an example of such logically independent part.
If configuration stuff is not specific to FSNamesystem (i.e., logically independent) then it shouldn't go there. If it is specific to FSNamesystem then it could go there, or perhaps on a new class that's used only by FSNamesystem, e.g., FSNamesystemParams. If it's used equally by FSNamesystem and other classes then it could either go on an existing shared class (e.g., Namenode) or a new shared class (NamenodeParams).