In Chapter 1, Beginning Android and Java, we mentioned that Java was an object-oriented language. An object-oriented language requires us to use object-oriented programming (OOP). It isn't an optional extra like a racing spoiler on a car or pulsating LEDs in a gaming PC. It's part of Java and, therefore, Android as well.
Let's find out a little bit more.
OOP is a way of programming that involves breaking our requirements down into chunks that are more manageable than the whole.
Each chunk is self-contained, yet potentially reusable, by other programs, while working together as a whole with the other chunks.
These chunks are what we have been referring to as objects. When we plan/code an object, we do so with a class. A class can be thought of as the blueprint of an object.
We implement an object of a class. This is called an instance of a class. Think about a house blueprint. You can't live in it, but you can build a house from it; you build an instance of it. Often, when we design classes for our apps, we write them to represent real world things.
However, OOP is more than this. It is also a way of doing things—a methodology that defines best practices.
The three core principles of OOP are encapsulation, polymorphism, and inheritance. This might sound complex but, taken a step at a time, is reasonably straightforward.
Encapsulation means keeping the internal workings of your code safe from interference from the code that uses it, by allowing only the variables and methods you choose to be accessed.
This means that your code can always be updated, extended, or improved without affecting the programs that use it, as long as the exposed parts are still accessed in the same way.
Remember this line of code from Chapter 1, Beginning Android and Java?
locationManager.getLastKnownLocation(LocationManager.GPS_PROVIDER)
With proper encapsulation, it doesn't matter if the satellite company or the Android API team need to update the way their code works. If the getLastKnownLocation method signature remains the same, we don't have to worry about what goes on inside. Our code written before the update will still work after the update.
If the manufacturer of a car gets rid of the wheels and makes it an electrically-powered hover car, as long as it still has a steering wheel, accelerator, and brake pedal, driving it should not be a challenge.
When we use the classes of the Android API, we are doing so in the way that the Android developers designed their classes to allow us to.
Polymorphism allows us to write code that is less dependent on the types we are trying to manipulate, making our code clearer and more efficient. Polymorphism means different forms. If the objects that we code can be more than one type of thing, then we can take advantage of this. Some examples later in this chapter will make this clear. An analogy will give you a more real-world perspective. If we have car factories that can make vans and small trucks just by changing the instructions given to the robots and the parts that go onto the production line, then the factory is using polymorphism.
Wouldn't it be useful if we could write code that can handle different types of data without starting again? We will see some examples of this in Chapter 11, More Object-Oriented Programming.
Just like it sounds, inheritance means that we can harness all the features and benefits of other peoples' classes, including encapsulation and polymorphism, while further refining their code specifically to our situation. Actually, we have done this already, every time we used the extends keyword:
public class MyActivity extends AppCompatActivity {The AppCompatActivity class itself inherits from Activity. So, we inherited from Activity every time we created a new Android project. We can go further than this and we will see how it is useful.
Imagine if the strongest man in the world gets together with the smartest woman in the world. There is a good chance that their children will have serious benefits from gene inheritance. Inheritance in Java lets us do the same thing with another person's code and our own.
When written properly, all of this OOP allows you to add new features without worrying as much about how they interact with existing features. When you do have to change a class, its self-contained (encapsulated) nature means less or perhaps even zero consequences for other parts of the program. This is the encapsulation part.
You can use other people's code (like the Android API) without knowing or perhaps even caring how it works: think about the android life cycle, Toast, Log, all the UI widgets, listening to satellites, and so on. For example, the Button class has nearly 50 methods – do we really want to write all that ourselves, just for a button? It would be much better to use someone else's Button class.
OOP allows you to write apps for highly complex situations without breaking a sweat.
You can create multiple, similar, yet different versions of a class without starting the class from scratch by using inheritance; and you can still use the methods intended for the original type of object with your new object because of polymorphism.
It makes, sense really. And Java was designed from the start with all of this in mind, so we are forced into using all this OOP; however, this is a good thing. Let's have a quick class recap.
A class is a bunch of code that can contain methods, variables, loops, and all the other Java syntax we have learned. A class is part of a Java package, and most packages will normally have multiple classes. Usually, although not always, each new class will be defined in its own .java code file with the same name as the class, as with all of our activity classes so far.
Once we have written a class, we can use it to make as many objects from it as we want. Remember, the class is the blueprint, and we make objects based on the blueprint. The house isn't the blueprint, just as the object isn't the class; it is an object made from the class. An object is a reference variable, just like a string, and later we will discover exactly what being a reference variable means. For now, let's look at some actual code.