<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Igor Konoplyanko</title>
    <description>The latest articles on DEV Community by Igor Konoplyanko (@cauchypeano).</description>
    <link>https://dev.to/cauchypeano</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F162777%2Fc4e859d1-361c-4d28-928b-af141d583d54.png</url>
      <title>DEV Community: Igor Konoplyanko</title>
      <link>https://dev.to/cauchypeano</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/cauchypeano"/>
    <language>en</language>
    <item>
      <title>Why you should avoid package-private scope in Java</title>
      <dc:creator>Igor Konoplyanko</dc:creator>
      <pubDate>Tue, 26 Nov 2019 13:39:55 +0000</pubDate>
      <link>https://dev.to/cauchypeano/why-you-should-avoid-package-private-scope-in-java-anl</link>
      <guid>https://dev.to/cauchypeano/why-you-should-avoid-package-private-scope-in-java-anl</guid>
      <description>&lt;p&gt;Recently I was discussing in my project about package-private visibility modifier.&lt;/p&gt;

&lt;p&gt;"Wait, what is &lt;em&gt;package-private&lt;/em&gt; in Java?" It's also sometimes called &lt;em&gt;default&lt;/em&gt; or &lt;em&gt;no modifier&lt;/em&gt;.&lt;br&gt;
This is when class or method doesn't have any modifier. For example:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;class SomeObject {
  void doSomething() {
    ...
  }
}
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;There are more details in &lt;a href="https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html"&gt;Java tutorial&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;It should be not used unless very-very specific reason. You either choose between public, private or protected. &lt;/p&gt;

&lt;p&gt;There are reasons I've heard so far from different people:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;But I need it to test method in my object!&lt;/li&gt;
&lt;li&gt;But It's better to restrict access to the Object as much as possible! It's being accessed only by same-package classes.&lt;/li&gt;
&lt;li&gt;I have library with lots of users and want to hide implementation details from them!&lt;/li&gt;
&lt;/ul&gt;

&lt;h2&gt;
  
  
  But I need it to test method in my object!
&lt;/h2&gt;

&lt;p&gt;Don't do package-private just to test that very important method. It's one of the frequent fallacies which I observe. People tend to get somehow access to that private logic, just relax it a little bit and then do dirty testing!&lt;br&gt;
There is a better way. 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. 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. &lt;/p&gt;

&lt;h2&gt;
  
  
  But It's better to restrict access to the Object as much as possible! It's being accessed only by same-package classes.
&lt;/h2&gt;

&lt;p&gt;Official Oracle documentation says:&lt;br&gt;
&lt;code&gt;Use the most restrictive access level that makes sense for a particular member. &lt;br&gt;
Use private unless you have a good reason not to.&lt;/code&gt;&lt;br&gt;
I am totally agree with this statement, just if we will drop &lt;em&gt;package-private&lt;/em&gt; out of this list. Life will be much easier for your project if everything will be public/private. One of the most frequent refactorings in large codebases is &lt;code&gt;Move File/Class&lt;/code&gt;. With lots of &lt;em&gt;package-private&lt;/em&gt; access it will become immediately annoying to do so. Why not to make them public then?&lt;br&gt;
At the end both &lt;em&gt;public&lt;/em&gt; and &lt;em&gt;package-private&lt;/em&gt; expose API of your class. No matter that in latter case it's limited by package, it's still an API which you have to care about. &lt;/p&gt;

&lt;h1&gt;
  
  
  When it still makes sense
&lt;/h1&gt;

&lt;ul&gt;
&lt;li&gt;Tests. It's relatively new trend to not to write access modifiers for test 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. Less typing is better!&lt;/li&gt;
&lt;li&gt;You are supporting library with lots of users. 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 &lt;em&gt;package-private&lt;/em&gt;
&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;So as you can see in 2019 (soon 2020!) there are not so much reasons to go with &lt;em&gt;package-private&lt;/em&gt; visibility.&lt;/p&gt;

</description>
      <category>java</category>
      <category>oop</category>
    </item>
  </channel>
</rss>
