By Barry Burd

One of the reasons why object-oriented programming, such as Java, has been so successful is that the truth is that no matter what you want to do, you can find software that does some of it, but not all of it.

Wouldn’t it be nice if every piece of software did just what you wanted it to do? In an ideal world, you could just buy a program, make it work right away, plug it seamlessly into new situations, and update it easily whenever your needs change. Unfortunately, software of this kind doesn’t exist. (Nothing of this kind exists.)

For years, companies were buying prewritten code only to discover that the code didn’t do what they wanted it to do. So what did the companies do about it? They started messing with the code. Their programmers dug deep into the program files, changed variable names, moved subprograms around, reworked formulas, and generally made the code worse.

The reality was that if a program didn’t already do what you wanted it to do (even if it did something ever so close to what you wanted), you could never improve the situation by mucking around inside the code. The best option was always to chuck the whole program (expensive as that was) and start all over again. What a sad state of affairs!

With object-oriented programming, a big change has come about. At its heart, an object-oriented program is made to be modified. With correctly written software, you can take advantage of features that are already built-in, add new features of your own, and override features that don’t suit your needs.

And the best part is that the changes you make are clean. No clawing and digging into other people’s brittle program code. Instead, you make nice, orderly additions and modifications without touching the existing code’s internal logic. It’s the ideal solution.

When you write an object-oriented program, you start by thinking about the data. You’re writing about accounts. So what’s an account? You’re writing code to handle button clicks. So what’s a button? You’re writing a program to send payroll checks to employees. What’s an employee?

In this example, an employee is someone with a name and a job title. Sure, employees have other characteristics, but for now stick to the basics. The code here defines what it means to be an employee.

import static java.lang.System.out;
public class Employee {
    private String name;
    private String jobTitle;
    public void setName(String nameIn) {
        name = nameIn;
    }
    public String getName() {
        return name;
    }
    public void setJobTitle(String jobTitleIn) {
        jobTitle = jobTitleIn;
    }
    public String getJobTitle() {
        return jobTitle;
    }
    public void cutCheck(double amountPaid) {
        out.printf("Pay to the order of %s ", name);
        out.printf("(%s) ***$", jobTitle);
        out.printf("%,.2fn", amountPaid);
    }
}

According to the listing, each employee has seven features. Two of these features are fairly simple. Each employee has a name and a job title. (In the listing, the Employee class has a name field and a jobTitle field.)

And what else does an employee have? Each employee has four methods to handle the values of the employee’s name and job title. These methods are setName, getName, setJobTitle, and getJobTitle.

On top of all that, each employee has a cutCheck method. The idea is that the method that writes payroll checks has to belong to one class or another. Because most of the information in the payroll check is customized for a particular employee, you may as well put the cutCheck method inside the Employee class.