 Up to now, I've been developing all the programs in files that happen to go in the same directory. This is great when the programs are small. However, as programs get more complicated, you might want to put related classes into directories to help organize your code. You can indicate that classes belong together by adding a package specifier to the code. The package name is the same as the directory name, and it must be the first non-blank, non-comment line in the file. By convention, package names begin with lowercase letters. If you don't specify a package name, your files go into the default package. Any properties or methods you define in a class in the default package are accessible by that class, or any other class that's also in the default package, but not accessible to any other package. This hasn't mattered so far because we haven't defined other packages. Once you start defining packages, you may wish to change who can access properties and methods that you've defined. If you proceed a property or method with public, that means your class, any class in the same package as yours, or any class in any other package has access to it. If, on the other hand, you proceed a property or method with private, then only the class that defined it can access it. The link in the description of this video leads to a zip file that demonstrates these levels of visibility and access. Along with the default, private, and public visibility modifiers, there's another one, protected, which we'll get to in Chapter 11. So, you may be asking yourself, why not keep everything default or public? What good is private? Take a look at this code for a class called circle, where everything has been declared public. Our setRadius method makes sure that the radius can't be negative by taking the absolute value of whatever value you pass to it. However, because it's public, there's nothing preventing you from directly setting the radius property to a negative number. Let's compile and run it, and you'll see our bad radius of negative 2.5. To prevent this, we can change the radius from public to private. Now, when we compile, we get an error. The radius has private access in circle. We can't set the radius directly. Instead, we must use the setRadius method, and that will ensure a non-negative number. We can compile, and now it's 2.5. This is called encapsulation. We have walled off the underlying implementation. Because programmers can't get to our data directly, we're free to change the representation of our properties, and the client programs don't have to change. In general, you should always make your data fields private. In a UML diagram, you proceed private data fields with a minus sign to indicate that they are private. Public properties and methods are preceded with a plus sign. The constructor must be public. In order to allow access to the private properties, you need to write public methods that access that data. These are called getters or accessors. By convention, these begin with the word get, followed by the name of the field, except for booleans, which begin with the word is. You'll also need to write public methods to set the values of the private properties. These methods are called setters or mutators. The Eclipse Interactive Development environment has an option to generate these getters and setters for you automatically. Such a deal! In summary, encapsulate your data by making properties private. It prevents programmers from accessing them directly. Instead, they have to use your getters and setters. This also gives you more flexibility to change underlying implementation without breaking your customers' programs.