Composition vs. inheritance

In object-oriented programming, the most likely way that you’ll create and use code is by simply packaging data and methods together into a class, and using objects of that class. You’ll also use existing classes to build new classes with composition. Less frequently, you’ll use inheritance. So although inheritance gets a lot of emphasis while learning OOP, it doesn’t mean that you should use it everywhere you possibly can. On the contrary, you should use it sparingly, only when it’s clear that inheritance is useful. One of the clearest ways to determine whether you should use composition or inheritance is to ask whether you’ll ever need to upcast from your new class to the base class. If you must upcast, then inheritance is necessary, but if you don’t need to upcast, then you should look closely at whether you need inheritance.

access specifier for class

1. There can be only one public class per compilation unit (file). The idea is that each compilation unit has a single public interface represented by that public class. It can have as many supporting package-access classes as you want. If you have more than one public class inside a compilation unit, the compiler will give you an error message.

2. The name of the public class must exactly match the name of the file containing the compilation unit, including capitalization. So for Widget, the name of the file must be Widget.java, not widget.java or WIDGET.java. Again, you’ll get a compile-time error if they don’t agree.

3. It is possible, though not typical, to have a compilation unit with no public class at all. In this case, you can name the file whatever you like (although naming it arbitrarily will be confusing to people reading and maintaining the code).

Note that a class cannot be private (that would make it inaccessible to anyone but the class) or protected So you have only two choices for class access: package access or public. If you don’t want anyone else to have access to that class, you can make all the constructors private, thereby preventing anyone but you, inside a static member of the class, from creating an object of that class.

import static single class declaration

SingleStaticImportDeclaration:
import static TypeName . Identifier;

The TypeName must be the canonical name of a class or interface type. The Identifier must name at least one static member of the named type.

StaticImportOnDemandDeclaration:
import static TypeName . * ;

Integer compare with ''

There is a tricky bug if you compare a number with empty string and if the number = 0:

                                                                                                    
#!/usr/bin/perl
#use warnings;
use strict;

my $v;

undef $v;

if (!defined($v)) {
    print "Oops! \$v is not defined\n";
}

$v = 0;

if ($v == '') {
    print "Oops! \$v == \'\'\n";
}

__END__

Result:
Oops! $v is not defined
Oops! $v == ''

You can see that if $v = 0, the condition:

$v == ''

will get TRUE!

Of course if you turn on warnings, you will not ignore this bug because compiler will give you this:

Argument "" isn't numeric in numeric eq (==) at ...

SUM(A + B) vs SUM(A) + SUM(B)

In PostgreSQL, a integer plus a null get null, so these two expressions is different not only in result but also in logic:

SELECT SUM(A + B) FROM youtable;
SELECT SUM(A) + SUM(B) FROM youtable;

You can verify this if your A or B has null value.

Compilation unit

When you create a source-code file for Java, it’s commonly called a compilation unit (sometimes a translation unit). Each compilation unit must have a name ending in .java, and inside the compilation unit there can be a public class that must have the same name as the file (including capitalization, but excluding the .java file name extension). There can be only one public class in each compilation unit; otherwise, the compiler will complain. If there are additional classes in that compilation unit, they are hidden from the world outside that package because they’re not public, and they comprise "support" classes for the main public class.

How an object is created

To summarize the process of creating an object, consider a class called Dog:
1. Even though it doesn’t explicitly use the static keyword, the constructor is actually a static method. So the first time an object of type Dog is created, or the first time a static method or static field of class Dog is accessed, the Java interpreter must locate Dog.class, which it does by searching through the classpath.
2. As Dog.class is loaded (creating a Class object, which you’ll learn about later), all of its static initializers are run. Thus, static initialization takes place only once, as the Class object is loaded for the first time.
3. When you create a new Dog( ), the construction process for a Dog object first allocates enough storage for a Dog object on the heap.
4. This storage is wiped to zero, automatically setting all the primitives in that Dog object to their default values (zero for numbers and the equivalent for boolean and char) and the references to null.
5. Any initializations that occur at the point of field definition are executed.
6. Constructors are executed. this might actually involve a fair amount of activity, especially when inheritance is involved.