We will start by looking at how OOP differs from conventional and functional programming. Before OOP, software programs were increasingly becoming very large and complex. These systems needed many architects and engineers to develop the software, and more time and money were spent on maintenance. Often, if new features or policies needed to be added or changed to reflect the business model, it would take several weeks or even months to modify the software while it took much less time building a new application.
These applications became so large that tracking bugs became a serious problem. Tracing old functionality took longer than applying the modifications, and code started becoming extremely disorganized as the number of programmers involved in a project also increased. A poor design from the start, which is often a constraint with non-OOP languages like C or Fortran, was one of the major factors. With all major corporations investing a lot of time and money into developing electronic solutions to run their companies, there was a strong need for improving the software design and construction process.
This is when many computer scientists, philosophers, biologists, and software architects, most notably Alan Kay for his efforts on introducing Smalltalk and Grady Booch for his modern-day object-oriented principles, developed the basic frameworks for constructing software using an entirely new method, which was eventually named "Object-Oriented Programming".
The goal was to solve the software crisis through an easy-to-use, intuitive framework. These OOP pioneers discovered that by developing a few heuristics to accompany the new technique, it's possible to solve a lot of problems with the software crisis automatically, with little extra thought required by the programmer. OOP forces the programmer to look at problems and their solutions from a different perspective. It comes with a small cost as a slight decrease in performance but maintenance is very easy.
The trade off between performance and. maintainability has already become apparent. For some real-time or performance intensive applications, migrating to an OO solution is not even an option due to their strict time constraints. However, when OOP can be used, the programmer can start architecting highly reusable and more intuitive programs than ever before. This improves code reusability, maintainability, traceability, and readability.
With the development of OOP, new methodologies in software project management and software engineering came about, such as the infamous "eXtreme" Programming and the Unified Process. It's now easier to assess and schedule projects, allocate programming resources, reutilize code, and test and review code on large projects. Indeed, the introduction of OO has had a great impact in today's electronically driven world. Technologies such as Java have pushed OO to the extreme, offering a single, OO solution for developing software for appliances, applications for desktops, and powerful web applications through its enterprise API.
So what makes OOP different from functional programming? When we code an application with functions, we create programs that are code-centric. These applications call function by function consecutively. The data is first sent as the input, the function does the actual transformation, and then it returns the corresponding output. OOP takes the opposite approach since it is data-centric. Objects, which represent their data internally, contain functionality called methods.
A method is a service (very similar to an implementation of a function) that an object guarantees to provide to its clients (other objects). When an object requests a service from another, it basically passes a message and receives a response. Here is a comparison of the two approaches:
Input enters the function a(), which then calls the function b() using the output of a(). Function b() then calls c() using the output of b(). c() then returns its output to b() which then returns its output to a(). Function a() finally produces the program output. Function a() would be the main function of a typical C program. In the object-oriented model, objects request the services of others, easily seen when Object 1 requests the service of Object 3. Object 3 in turn requests the service of Object 4 and so on, until Object 1 receives a reply from Object 3 containing the end result.
What's happening is that each object uses the services provided by the others within the program to receive information so it can do its own work, that is, make its own decisions based on information provided by other objects. The passing of these messages is the flow of the program in itself. The data and the methods or the functionality of the object are contained in one central location.
The difference between the two approaches is that objects contain all the data and behavior that should exist together while the data and functions are clearly separated in the functional paradigm. This makes object-oriented code very easy to trace during maintenance and increases the modularity of the project.
Now, this doesn't mean that functional programs aren't maintainable, because they can be. It just requires a lot more thinking and organization on the architect's part to ensure that everything is located in the proper location. They ensure that there are no global variables being manipulated in many of the project files, if any should exist. The best thing about object-oriented programming is that we just make the objects as they make sense, follow some guidelines, and things should be pretty organized. With more complex applications, the use of special patterns can strengthen the design of our systems so we can reap added benefits.
What's important for you, as an application programmer, is that you must realize that OOP is nothing more than a technique; meaning, it's not a language or platform in itself. PHP, C++, and Java are all OOP languages since they all implement the same approach in their own, unique way, but programming in either C++ or Java is quite different since you'll need some proficiency with the syntax and semantics of either language.
Since all OOP languages implement the same paradigm, the concepts are very much the same across all OOP languages. That's why it's very important to learn OOP conceptually first, then tackle the implementation of a language of your choice afterwards. In the case of PHP, we will learn that it only supports a subset of features you would expect from a object-oriented programming language. The limitations will be discussed throughout the chapter and will be covered near the end of the chapter.