I totally agree that jigsaw is a much cleaner solution than using package scopes but in reality jigsaw is mostly used for green field projects and old projects are rarely refactored to use jigsaw. That you can use it for your projects is just a nice side effect. The main reason why JAVA got jigsaw was to modularize the JDK. So you say it's better to use public instead of package private. In your blog post you said that you agree with oracles recommendation on using the most restrictive access level but in the next sentence you say Life will be much easier for your project if everything will be public/private. quite the contrary, it showed me when my domain design wasn't good. Like comment: Like comment: 5 likesĬan you give me an example of anything that becomes annoying when you use package private? the web interface, business logic / service layer, DAO layer of one domain should be in one package and only provide functions to other packages through interfaces. I have seen a lot of people tend to create too many packages and sub packages but a java package should contain all classes of a specific domain/context. It's also important to organize your packages in a proper way. The simplest way to achieve this is with package private scope. In case of DDD you have different contexts and you only want to provide access to a domain through a well defined interface. In a lot of architectural styles like clean architecture, layered architecture, hexagonal architecture and domain driven design (DDD) it is important to have clean boundaries between your modules. The more restricted your access level the less chances to create unnecessary dependencies that will end up in a big ball of mud. In my opinion package private should be used frequently and should always be used if you don't have to make a class public. So as you can see in 2019 (soon 2020!) there are not so much reasons to go with package-private visibility. Unless your library should be compatible with java8 or less! Otherwise I encourage to use JPMS (Project Jigsaw) in your libs, which will give you much better control over your exposed API's and internal implementation compared to package-private You are supporting library with lots of users.
JAVA REFLECTION GET SUBPACKAGES CODE
Anyways modifiers bring some noise to the code and access visibility doesn't matter so much in tests as it does in production code. It's relatively new trend to not to write access modifiers for test code. No matter that in latter case it's limited by package, it's still an API which you have to care about. Why not to make them public then?Īt the end both public and package-private expose API of your class. With lots of package-private access it will become immediately annoying to do so. One of the most frequent refactorings in large codebases is Move File/Class. Life will be much easier for your project if everything will be public/private. I am totally agree with this statement, just if we will drop package-private out of this list. Use private unless you have a good reason not to.
Use the most restrictive access level that makes sense for a particular member. It means that it's a perfect candidate for refactoring! Just extract that logic into inner class with well-defined API methods and test them.īut It's better to restrict access to the Object as much as possible! It's being accessed only by same-package classes. First you need to understand that something probably wrong with your design, if there is a some hidden functionality which is hard to get to test. People tend to get somehow access to that private logic, just relax it a little bit and then do dirty testing! It's one of the frequent fallacies which I observe.
There are reasons I've heard so far from different people:
You either choose between public, private or protected. It should be not used unless very-very specific reason. Enter fullscreen mode Exit fullscreen mode
0 kommentar(er)
