Menu
Background: I notice that in many projects almost all classes in the internal code are public and not final, even if they don't need to be. However, it seems sensible to me to make this decision not by default, but only make classes public if they are actually meant to be used from other parts of the system. Having package protected classes is an easy mechanism to enforce boundaries between modules, and serves as a documentation on the intended use of a class.
If there was a (preferrably free :-) tool to protect all classes that can be protected without breaking the program, and maybe make everything final that has no subclasses, that would be a good starting point to start a conscious use of protection mechanisms. (Of course you need to tweak things afterwards.) Do you know such tool?
Caveat: I am aware that there are better modularization mechanisms like OSGI and the planned superpackages and so forth. But in many current projects this is not an option, and using the plain old Java mechanisms is something you can easily do. Also, this works only if you have shared code ownership (such that everybody can change things back to public as needed) and if you are developing an endproduct, not a library for use by others. I am also not too sure about the benefits of making things final - this prevents AOP and mocking.
CLARIFICATION: As I said, I am not talking about libraries that are thrown over the fence to someone who can't change it, but about internal code of medium sized projects where everybody is encouraged to change and refactor everything as needed. When I am talking about package protected or final think of it as "protected until someone feels a compelling need to lift those restrictions". If someone feels the need to lift the restrictions set by the tool, he is welcome to do so.
463
The package java has subpackages awt , applet , io , lang , net , and util , but no compilation units. The package java. awt has a subpackage named image , as well as a number of compilation units containing declarations of class and interface types.
The private modifier specifies that the member can only be accessed in its own class. The protected modifier specifies that the member can only be accessed within its own package (as with package-private) and, in addition, by a subclass of its class in another package.
The protected access modifier is accessible within package and outside the package but through inheritance only. The protected access modifier can be applied on the data member, method and constructor. It can't be applied on the class. It provides more accessibility than the default modifer.
Even if there was such a tool, (there isn't), a good programmer wouldn't use it... access specification is a design issue best understood and settled by the programmer himself. Think about it... you make a program and run the tool and get everything sorted (Assuming the tool is super-intelligent in the first place to actually understand your program).. then you decide to modify it... extend some classes, etc.. and you end up extending final classes and making objects of private classes.. (and these are few of the many problems you'll face)...
Thing is.. when the tool does its job, you would no longer even understand your own program.
Bottomline.. stop looking for tools to solve your design issues.. (its like asking for tools that will automatically debug your program)
194
You can have a look at ATL from Eclipse. Although ATL is used to create model to model transformations between different kinds of models, there is no restriction that source and target model are not of the same type. You could create a transformation from Java to Java that makes your current classes protected or final. MoDisco is a toolset of Eclipse makes use of that, just if you want to see examples.
35
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
