Object Oriented Approach simplifies Teamwork

Because object-oriented programs maintain clear boundaries between different sections of code, they make it comparatively easy to divide the programming workload between different people. As long as the programmers agree on the public interfaces of each class they are working on, they are free to change the private implementation of those interfaces. Remember, changes to the inside are guaranteed not to break code in other classes, so teams do not need to spend as much time in meetings or arguing about whether a proposed change can be made or not. Although designing a system with the object-oriented approach often takes longer than with the procedural approach, coding a system developed with the object-oriented approach is usually quicker.

A further complication is that the requirements of a software system often change during its development, largely because the very existence of a software development project alters the rules of the problem. Seeing early products, such as design documents and prototypes, and then using a system once it is installed and operational are forcing functions that lead users to better understand and articulate their real needs. At the same time, this process helps developers master the problem domain, enabling them to ask better questions that illuminate the dark corners of a system's desired behavior.

Because a large software system is a capital investment, we cannot afford to scrap an existing system every time its requirements change. Planned or not, systems tend to evolve over time, a condition that is often incorrectly labeled software maintenance. To be more precise, it is maintenance when we correct errors; it is evolution when we respond to changing requirements; it is preservation when we continue to use extraordinary means to keep an ancient and decaying piece of software in operation. Unfortunately, reality suggests that an inordinate percentage of software development resources are spent on software preservation.

One of the challenges in managing any multideveloper project is using people's talents to the fullest. Say you are simulating an oil refinery, and some of your developers are chemical engineers. You want them working on code that requires some knowledge of chemical engineering^[1], not the user interface. With an object-oriented approach, you can assign these developers the task of coding Pump and HeatExchanger, and let the user interface team handle the nonengineering parts of the project.
With your responsibilities for each class settled, and a good start on encapsulating the right information with each responsibility, it is time to take a look at the system as a whole and make sure you are solving the right problem.

Click the exercise link below to review the scope of the course project.
Teamwork - Exercise

[1] Chemical engineering is a branch of engineering that uses principles of chemistry, physics, mathematics, biology, and economics to efficiently use, produce, design, transport and transform energy and materials.