Friday, November 17, 2017

Package-private (no explicit modifier)

In recent courses, I was privileged to conduct, I noticed a disturbing trend of student skill degradation. These skill disappearance I trace back to the popularity of mobile devices and the wide use of YouTube videos that skip details.  Video lectures especially lectures by non-lecturers lead to a business venture driven by profit and the aim for keeping within current attention span of young adults create a skill gap that is very hard to reverse.

Mobil devices eliminate the cognitive process of thinking about file names, directory names, proper naming conventions, command line utility usage, utility help interpretation, and security right considerations essential for anyone interested to learn technology related fields like Computer Science. 

YouTube video and online courses aim to restrict video lengths to short precise videos that focus on how to perform a single task without explaining "why" the task is performed or "how" the task, to be performed, was researched by the presenter.

One of this trend I see in Object Oriented Programming (OOP) like Java is the aim to keep all source code in a single file for convenience of not handling multiple source files.  The aim of OOP in a learning environment is to lean problem solving by dividing the problem into specific objects that perform specific tasks for re-usability and sharing. 

In Java, source code can contain many classes, but classes are defined by class access modifiers and only one class can be a public class.  No modifier in class definition makes the class private to its package level, thus other packages can not instantiate those classes.  The compiled code will create a separate byte code file that can be shared, but other than the specified package would not be able to instantiate the class.

Like in the code below, the MyDefaultClass class has no access modifier, thus it is private to the package testing and no other package can instantiate it. This code is easy to talk about, easy to present in a single screen video tutorial, but it is damaging to skill development and to practice file management.  This example should be saved into two separate source files and MyDefaultClass should be made public so every package could instantiate the class in other application if needed.

package testing;

class MyDefaultClass{
    private String msg;
    public MyDefaultClass(String m){
        msg=new String(m);
    }
    public String getMsg(){
        return msg;
    }
}

public class Driver {
    public static void main(String[] args) {
        MyDefaultClass t=new MyDefaultClass("Hello");
        System.out.println("Hello World");
    }
}


As you can see below, we have one source code, but the compiled program produced two byte codes.  So, one of them can be shared.  In this case, MyDefaultClass cold be used in other applications since there is nothing indicating that it is tied to a package, as we'll see later.
 


In order to test this, we can create another package and see if we can instantiate the class in that package. (Note: This is another skill gap I see in courses, students are not taught and not driven to learn how to test concepts or theories. )

So, start a new package, in this case it is testAgain package and create a simple "Hello World" application in the package ( in this case, Driver ).  Now, just copy the MyDefaultClass.class from package testing to package testingAgain.

The source code, in this case, only has one single public class, so instantiating the class MyDefaultClass will happen from the bytecode directly ( if it will work )


 Adding the statement to instantiate the class MyDefaultClass will not work since the class is private to testing package.


 Now, let's create a separate source code for MyPublicClass in package testing. In this case, the class can be set to public, so regardless of the package, the class can be used in any program.


So, copy the MyPublicClass to testAgain package to test in that package.


Importing the class path and adding the statement to instantiate the class woks just fine since the class MyPublicClass access modifier is set to public this time.


Conclusion
Always seek to answer the "WHYs", in coding, in order to become a problem solver.  Video lectures are created for a quick lesson not as an educational resource, don't think that a quick video will be able to teach you what you need to know about the code, they are only a tool to help you overcome simple concept confusions. Videos will never replace search, reading, and critical thinking through collaboration. 


Appendix A - Access level modifiers
Access level modifiers determine whether other classes can use a particular field or invoke a particular method. There are two levels of access control:
  • At the top level—public, or package-private (no explicit modifier).
  • At the member level—public, private, protected, or package-private (no explicit modifier).

No comments:

Post a Comment