OOP Object Oriented Thinking?
I was first motivated to write this for a buddy of mine who's just starting out in the software development industry, when I quickly realized others can benefit from this as well.
The purpose of this article, is to educate (in not so technical terms) those interested in object oriented design / programming, also known as (OOD OR OOP). This is the fundamental basics to modern software development.
My goal is to share my point of view, including those that contributed to the motive. I will not, however, explain how to use a specific programming language nor tool(s) , but I do intend to help you better understand the general purpose for using them.
The objective to modern software development is to understand the business model of your clients first. This means understanding their terminology, business rules and the entities of their business. Trying to get a the big picture of this model through many meetings with the client can be quite challenging, especially when you don't have the luxury of starting on a project from the beginning.
What I like to do first when I join a project is try to identify the purpose of the application, which they hired me to help develop. So the first question I ask is, "What is the application supposed to do?". Although this may seem like common sense, you would be surprised how easy it is to lose focus on the intent of the application, once you begin to get very involved with the specific requirements. Especially, when "nice" features tend to creap up. After I get my answer, then I have a better understanding of the goal in mind. In order to help get my point across as simple as possible I will use the following scenario.
A client needs an application that can add, edit and search for their customers.
Okay, simple enough. Now I have identified the players in the game. In this case Customer can be identified as an entity. Now lets take a closer look at the requirements.
Add: The application has to be able to add a Customer into the system. Okay. So what type of information should be added into the system? This information is typically represented as properties of a Customer. (ex. Customer Name, Customer Address, Customer Phone number, etc...). There may even be some rules which the application should apply in order for someone to add a Customer. For example, a Customer can't be entered into the system if no name is provided or the Customer must be over 18 years old or has to have a bank account number. You get the point.
Edit: The application has to allow for someone with access and authority to edit Customer information. Although the specifics to this requirement was not so obvious, a company usually doesn't want everyone in the company to have the ability to edit the information. They may require that the application have some security built into it. Which will require a security model to be designed and implemented. A good resource can provide the essential basics to complete this task.
Search: The application has to allow for people to search for Customers. So what should they be able to search on? This could be any property on the Customer right? Sure why not. Although there may be other things like computed values to search on. For example, being able to search on a customer who bought 10 items. This may not be a Customer property. In order to keep track of this you have to know what items the Customer bought. Hmmm... sounds like we have other information you need to store like Products and inventory and prices and more.
The point is that we are beginning to identify the entities of the business.
A modern concept called "Domain" or "Object Model" is used to represent such entities. This should not be confused with any other acronymns out there such as the DOM (Document Object Model for Javascript).
In most of my projects, a domain model was defined with the same names as the names my clients used. Most, if not all my business domain models where stored in a databases, although some have been represented by xml schema(s).
In this case I used a Customer, but there are other examples such as an Employee, Supplier etc... I also defined the properties which were associated to each domain. In the example of the Customer, I had identified properties such as the Customer's Name, Address, Account Number, etc... which were stored as columns in the Customer database table. I defined the interactions between the models with behaviors or so called Events. For example, in order to become a Customer, the business required that the Customer register and create an account. The behavior or event in this example was that once the Customer filled out the proper registration forms, a unique Account Number was created. Now I can validate a Customer with an Account number at any time.
Although this is at a very high level, I hope that you begin to understand the concepts behind Object Orientation Thinking or better known as OOD / OOP.
As you develope using this Object Orientation thinking, you will not be successful until you also understand the foundation that makes this concept work. This includes Inheritence, Encapsulation and Polymorphism the pillars of Object Orientation.
As hard as this may seem to understand at first, once you begin to grasp and nurture this concept, you will begin to realize the potential. However, this doesn't go without saying that you MUST also know how to use modern software developement tool(s) in order to produce mainstream applications. Most systems have proprietary tools and languanges, which usually have a cost associated with it, while others are open source and configurable without any cost. Except effort and time of course.
One final note:
Although, objects and their relationships provide a majority of the characteristics of a DOM, domain object models influenced by events that occur between objects.
