As a teacher of some computer programming languages and database for some time now, I cannot help but notice the difficulty of students during the initial learning of programming in Java. These difficulties are related to the amount of resources, rules and details of Java itself. However, once these main difficulties are overcome, the student has an excellent working tool to demonstrate their full potential and explore the almost endless possibilities only limited by his/her creativity.
The second part of this article explorer the pitfalls and difficulties found by learners related to conceptual aspects of the Java, including the virtual machine concept, the object oriented programming paradigm and specification and implementation tasks.
One of the first topics presented when talking about Java is the virtual machine. When the teacher introduces the concept of code that runs in an environment which does not interact directly with the operating system, as opposed to a program in C or Pascal for instance, many students have a hard time to understand this concept. This difficulty is related to the lack of visualization of a virtual machine, especially if the teacher mentions the Java's slogan: Write Once Run Anywhere. The simple fact that it is necessary to install the JRE to run programs is not very intuitive. There are also hard to show in class virtual machines other than the one that is installed on the PC.
In these situations what I do is to appeal to a common mobile phone. Today it is uncommon to find a student who doesn’t have a handheld that does not support Java, apart from some smartphones. Either way, when I show the logo of the Java virtual machine appearing when a game or application is started on the phone I demonstrate an example of a virtual machine running on another platform making easier to understand the concept of virtual machine and the Java slogan.
Another key concept that is intrinsically related to Java is the basic principles of object oriented programming (OOP). But in this case the difficulty is the paradigm shift: the student is probably used to procedural programming concepts taught in previous logic programming courses and can't traduce it's algorithmic sequential thought to the world of object orientation, especially when it comes in its four basic principles: abstraction, polymorphism, inheritance and encapsulation.
The classical approaches to explain object oriented concepts start from the concept of class, instance, modeling and abstraction, always focusing on practical examples such as cars, blueprints, characteristics and behavior of an object, and other analogies. Understanding the fundamentals of object orientation is one of the theoretical issues that require more mental effort from the student. This means that the students must begin to 'see' the world around them through the perspective of object orientation, just as the character Neo in the Matrix movie begins to see the source code that is representing what is around he either being people, buildings or bullets. Again, the idea here is to differentiate the view of seeing from the understanding which requires much effort, practice and a heavily dose of examples and analogies.
One of the hardest concepts to be understood by students when they are learning the object oriented paradigm is the idea of interface. Until now students often do not have much experience in mental organization in order to first specify and design what should be done and only then do what is necessary to be done. This is a central point and usually I try to mention the example of companies whose business model is to specify requirements only while other companies get this specification and assemble or build exactly what was designed. In terms of software it is uncommon to find a company that makes everything from scratch, i.e., it is very common practice to divide the development time in the specification and development phases. This division creates implications to job positions as systems analysts are more attached to the specification while developers are more related to the execution or implementation of the specification. The idea of specification and implementation also lead to the concepts of interface and objects in Java.
However, the traditional example of a contract to explain the use of interfaces is not very intuitive. The idea is to say that the interface is a contract with clauses and any class that implements the interface (sign the contract) must necessarily have a region of the code for each of the contract's clauses, i.e. fills in the code methods and has the other elements the interface. What makes this analogy difficult to understand is the fact that the interface contains no implementation and some students never saw a contract like that before. The students who saw a contract like that sometimes cannot imagine anything that implements the contract because in real life the contract takes the form of a set of sheets with text that is signed by two parties.
To aid the understand of the interface concept I try to use the following analogy that works with most students: I suggest students to think in a child's toy where they have to fit certain pieces in certain holes, like the toy shown in Figure 1. This toy has several holes in different shapes such as squares, stars, triangles, and so on. The holes represent the toy interfaces, i.e. the picture format that can be embedded in that specific hole. The figure itself can have any color, size and texture, but if you want to fit a figure in a square hole this figure has to necessarily take the form of a square. To sum up: a box with holes would be a set of Java interfaces. In programming terms, we could imagine that the figure Green Square implements the interface Hole Square, as this figure can be seated in the hole that has a square shape. Note that another figure, let's say Black Square, also implements the interface Hole Square and also can fit in the square hole of the box. However, the figure Blue Star implements only the interface Hole Star and cannot be embedded in any square hole because it does not implement the interface Hole Square.
Figure 1. A toy that represents an analogy between interfaces and classes in Java.
Java also contains a number of new abbreviations that are not so simple to be known and to get acquainted. You must know what is the meaning of JDK, JRE, J2SE, attributes, assessors, classes, interfaces, methods, abstraction, properties and other concepts that did not exist in structured programming. In fact, many students find it difficult to relate concepts. For instance, to change the name of a programming block from function to method and the possibility of a variable to store constant values, objects, or even a reference to another object. Here the trick is to try to explain one a concept at a time, repeat several times what is the concept behind the word and say that the specific terms are important when talking with other Java developers, when you read the documentation or even when it is necessary to properly express an idea within the universe of technologies related to Java and other object-oriented programming.
This article discussed some aspects related to the difficulty of beginners in Java programming. The focus of this article was to present what are the difficulties encountered by beginners as well as some solutions to facilitate the learning of Java programming. The article pointed out some ideas for solving conceptual and technical difficulties that students and learners encounter when they are starting to program in Java.
The second part considered conceptual aspects and demonstrate some alternative to help the students understand hard to grasp ideas such as the principles of object oriented programming that are found in Java and other implementation details like the use of interfaces.
In part three we will see Technical difficulties in Java.
To see part one, go to: http://mrbool.com/p/The-classroom-environment-Beginners-difficulties-in-Java-Part-1/22915
The Karatsuba algorithm used for the multiplication of two integers.