Table of Contents
From Procedural to Object Oriented Thinking
When you move from basic Kotlin syntax to building Android apps, you quickly discover that almost everything you touch is an object. Activities, views, adapters, and even many system components are represented as classes that you create, extend, or interact with. Object oriented programming, often called OOP, is the style of programming that Kotlin and Android rely on most heavily. This chapter gives you the mental model you need before you learn the individual topics like classes, constructors, inheritance, interfaces, and data classes in later chapters.
Instead of focusing on syntax, this chapter focuses on how to think in terms of objects so that the later, more specific chapters make sense in the wider Android context.
Objects as Real World Models
The core idea of object oriented programming is that you model your code on the real world or the problem domain. You group related data and behavior together into units that you can use and reuse. These units are called objects, and each object belongs to a blueprint called a class.
You can think of a class as a plan and an object as a specific thing created from that plan. If you remember just one relationship, remember that an object is an instance of a class. The class describes what data the object can hold and what operations it can perform. The object is a concrete example that you can interact with at runtime.
In Android, Button, TextView, Activity, and RecyclerView are all examples of classes. Every time your app shows a button on the screen, there is an actual object in memory that is an instance of the Button class. You will learn about the exact syntax for defining classes and creating objects in the next chapter in this section. For now, it is important to understand that the Android framework is a large collection of ready made classes that you use to build your own objects.
Encapsulation and Grouping of Responsibilities
One of the most practical benefits of object oriented programming is encapsulation. Encapsulation means that a class hides its internal details and exposes only what other parts of the code need to know. The outside world interacts with an object through a defined set of functions and properties, and does not need to know how these functions are implemented internally.
In an Android app this becomes essential for managing complexity. For example, you might have one class that handles communication with a web service, another class that represents a single row in a list, and another that manages user authentication. Each class encapsulates its own responsibilities. When you want to change how networking works, you change the networking class without touching all your activities or fragments.
You will see how access modifiers like private and public help you enforce encapsulation when you learn about classes in the dedicated chapter. At this stage just remember that encapsulation is the technique that keeps your code organized and prevents all parts of your app from depending on every internal detail of other parts.
Strong encapsulation keeps your code modular, easier to test, and safer to change as your app grows.
Objects, State, and Behavior
Every object in an object oriented program has two major aspects. It has state and it has behavior. The state represents the data that the object holds at a given point in time. The behavior represents the actions that the object can perform.
In Kotlin, the state is usually represented by properties, and the behavior is represented by functions that belong to a class. When you see a class in Android, look for what data it holds and what it can do with that data. For example, a User object might hold data such as name and email. It may also provide behavior, such as validating the email format or creating a short display name. A MediaPlayer object holds the state of what file is being played and whether it is playing or paused, and it exposes behavior such as start(), pause(), and stop().
Thinking in terms of state and behavior helps you decide what belongs inside a class and what should be kept separate. When you design your own Kotlin classes for Android, you will aim to collect the related state and behavior into a clear unit. This makes your app logic less scattered and easier to follow.
Relationships Between Objects
Real applications rarely use a single object on its own. Instead, your code is full of objects that know about each other and collaborate to perform tasks. For example, in a typical Android screen there might be an Activity object that holds references to several View objects on the screen. There may also be a ViewModel object that holds the user data that the activity displays. These objects form a network of relationships.
Some relationships are simple ownership relationships. One object can contain or reference other objects. When the activity is created, it finds and connects to its views. When the activity is destroyed, those views are no longer used. Other relationships are more abstract, such as one object delegating work to another. For instance, a list screen might delegate data loading to a repository object.
These relationships are important for organizing your code into layers. Activity and fragment objects usually handle things that are close to the Android system and the user interface. Other objects, such as repository or model classes, focus on the data and logic of your app. In later chapters that cover architecture patterns like MVVM, you will see how object oriented relationships support clean separation between layers.
Reuse Through Abstraction
Object oriented code often uses abstraction to enable reuse. Abstraction means you focus on what something does, not how it does it. When you interact with a Button in Android, you do not need to know how it handles drawing itself on the screen at the pixel level. You only need to know that you can set its text and listen for click events. The internal details are hidden behind an interface.
This idea appears everywhere in Android. You work with abstract concepts like a list adapter or a layout manager instead of specific low-level implementations. Because of this, you can plug in different behaviors without rewriting all of your code. For example, you can change the layout of a list by swapping the layout manager, or change the data source for a screen without rewriting the activity.
In Kotlin, abstraction is often expressed through interfaces and abstract classes. An interface defines a contract that classes can implement. You will learn the concrete syntax and usage of interfaces in their own chapter. For this high level view, it is enough to understand that abstraction allows you to write code that depends on capabilities rather than on specific concrete classes. This keeps your code flexible when requirements change.
Inheritance and Specialization in Android
Object oriented programming provides inheritance as a way to create specialized versions of existing classes. In Android development you will see this everywhere. A common pattern is to extend a framework class like Activity, Fragment, View, or RecyclerView.Adapter and then override selected functions to customize behavior.
Inheritance can be imagined as a hierarchy. A base class provides general capabilities. A subclass adds more specific behavior or modifies parts of the existing behavior. You will learn the exact syntax for inheritance and polymorphism in a dedicated chapter later in this section. In this introductory context, the most important observation is that many Android components that you create are specializations of framework classes.
While inheritance is powerful, it is also something you must use carefully. You should create subclasses only when your new class truly is a more specialized version of the original. If two classes just happen to share some code, it is often better to share that logic through composition or shared helper classes rather than through an inheritance relationship. This keeps your class hierarchies clear and easier to maintain.
Objects and Lifecycle Awareness
In Android, objects do not live forever. Components like activities and fragments have lifecycles that the system controls. Since most meaningful objects are created, held, and destroyed by or with these components, understanding lifecycle has a direct connection to object oriented design.
A lifecycle method such as onCreate or onDestroy is not just a technical detail. It is the entry and exit point where your object graph is assembled and taken apart. For instance, you might create new objects when an activity starts, then release references to them when the activity is no longer visible to avoid memory leaks. Some objects, such as view models, are designed to outlive a single configuration change. They are created once and then reused by multiple instances of an activity or fragment.
When you plan your objects for an Android app, you must decide where they will be created, who owns them, and how long they should live. This is part of object oriented thinking in a system that is controlled by the framework. Later chapters on lifecycle, view models, and dependency injection will build on these ideas to show you how to manage object lifetimes in a structured way.
Object Orientation as a Foundation for Android Patterns
Many of the modern patterns and libraries that you will use in Android are built on top of object oriented principles. For example, the MVVM architecture uses model, view, and view model objects, each with distinct responsibilities. Dependency injection frameworks such as Hilt manage how objects are created and connected, which is just automated object graph management.
When you work with coroutines, networking layers, or persistence libraries like Room, you still design classes that represent entities, repositories, and services. All of these are regular Kotlin classes that participate in an object oriented design. Even if later Android development includes other paradigms, such as reactive programming or declarative UI with Jetpack Compose, the underlying building blocks remain classes and objects.
Understanding the core ideas of object oriented programming is therefore not a separate academic topic. It is the foundation that allows you to understand how Android components, libraries, and architectures fit together. In the following chapters of this section, you will see how Kotlin expresses these ideas through concrete features such as classes and objects, constructors, inheritance and polymorphism, interfaces, and special types like data classes and enums. Each of those topics will deepen this general picture and make it practical for real Android projects.