Category: java

A couple of years ago when my son asked me about the book on programming for kids, I could not find one, and have written my own e-book called Java Programming for Kids, Parents and Grandparents. For some reason computer books targeting teenagers are very rare. There are reader-rabbit kind books for very little kids, but 10-16 years old people do not have much of a technical literature, and 17-18 years old are studying computers using boring adult technical books (the Head First series is a lucky exception).

By the time kids are out of school, they know from their own bad experience that computer science is not an exciting career, which eventually will lead to a “death”; of such profession here in the USA.

Adults do not want to admit that kids are smarter than them. They keep saying something like, “My son is not too good at math – he can’t be a programmer”. But most of the programming tasks require only minimal knowledge of arithmetic and algebra skills. To start programming, a kid needs to understand what x = y+2 means. Another important concept is an if-statement. This is pretty much it.

Kids learn much faster than adults, and they do not have “previous programming experience”, which may actually be a good thing, because they do not have to switch from a procedural to object-oriented way of thinking. After learning about inheritance in Java, my son called my wife a super class.

Some people recommend using simple languages to teach people programming. I disagree. Java can be a good first programming language, but you should do it right. That’s why I’ve included lots of color cartoon-like characters that act like a Java-fabric softener.

This e-book was never printed. I “ve got some offers to publish it in black and white because it “s cheaper. I rejected these offers ndash; this book has to be printed in color.

This book was written about three years ago, but it “s about core Java, which did not change that much. I “ve been using Eclipse IDE in the book, but IDE does not really matter ndash; use NetBeans or whatever else you have handy.

You can download The Java Tutorial for Kids, Parents and Grandparents in English or in French from Farata Systems Web site . I hope you “ll enjoy the reading and will introduce your kids to an exciting world of programming.

For years, object-oriented programmers knew that one of the main OOP features is encapsulation: an ability to hide and protect object internals. Private and protected properties were invented to support this. But who are we hiding from? From stupid developers who will decide to use our smart framework classes.

In some OOP languages only descendent classes can access protected variables from the ancestor. Java relaxed this rule a little bit and allows accessing protected variables from classes located in the same package. Recently, I had to extend a class from a particular third party framework, which had a protected variable defined. My class was not located in the same package as that third party component… Let’s look at this example.

The code below works fine:

public class Father {

   protected int abc = 25;

}

public class Son extends Father{

   public Son (){

   System.out.println( "abc= " + abc);

  }

}

public class MyNewClass {

   public static void main(String[] args) {

     Son son = new Son();

     System.out.println( "Son.abc= "+ son.abc);

   }

}

The class MyNewClasss is happily printing

abc=25
Son.abc=25

Now move the Father and Son to the package com.thirdparty.framework.

After adding the import com.thirdparty.framework.*; to MyNewClass, the code still does not compile complaining that son.abc is not visible. Of course, because designers of the third party framework wanted to protect their precious abc variable, and they wanted to force me to inherit MyNewClass from their Father or Son.. Did they achieve their goal? Not at all. They just forced me to create a Grandson in my default package with a public getter to the abc property.

import com.thirdparty.framework.Son;
public class Grandson extends Son {

   public int getAbc(){
  
     return abc;

   }
}

And MyNewClass now looks as follows:

public class MyNewClass {

   public static void main(String[] args) {

     Grandson grandson = new Grandson();

     System.out.println( "Grandson.abc= "+ grandson.getAbc());
   }
}

It’s just annoying that I need to add the GrandSon because designers of the third party framework decided to make the abc protected.

If you want to restrict the access to a property, make it private and give me a public getter, if needed. If you want to let everyone work with a property, make it public.

But who needs this protected access level?