OO Development

A lot has been written about how to develop software. In this post I want to summarise the basic concepts. That is, those concepts that many drown in rivers of jargon and buzz-words.



To develop an application, regardless in which environment, you need to have as clear as possible what it needs to do (requirements) and when you must have it ready (deadlines). Then, you can think about how to do it (design) and actually do it (implementation), which includes testing it and delivering it. In practice, things do not usually run so smoothly, and you go through a series of iterations for what concerns all those aspects.

Requirements and deadlines are not independent. Usually, you have to find a compromise between the functionality you deliver and the time of delivery. Setting the right priorities is essential in order to find the best possible compromise.

There is also usually a trade-off between functionality and performance. The general guideline in this area is that it is almost always better to deliver something that runs like a dog and improve it later, rather than to try to make it at once very fast but fail to deliver it!

Especially if you don't love written documentation, you should develop your applications in steps, so that you can often show new bits and pieces to your customer[s] and react to their feedback (buzzwords: RAD = Rapid Application Development, JAD = Joint Application Development, XP = eXtreme Programming).

Requirements
To define what your application should do my advice to you is to start from outside in, rather than inside out. In particular for a web application, the functionality hangs from its user interface, not the other way round!

Just to give you an example, suppose that your application should make possible for the users to post their video clips to your web site.

Start by listing what a user should be able to do. You will most likely come up with a list similar to the following one:
•    Register a valid email address with the web site and choose a userID.
•    Change user access password and personal data.
•    Upload and remove video clips.
•    Search for, select, and view video clips.
•    Contact other users.

Next, write down what a site administrator (e.g., you) should be able to do. For example:
•    Get site statistics (accesses, uploads, ...).
•    List users.
•    Get user history/statistics (registration, uploads, disk space...).
•    Remove individual clips.
•    Disable individual users.

You should go back to these lists and update them whenever you realise that something is missing. The best strategy (the only one acceptable if you work in a team) is to place the lists under source control, so that all changes are traceable and reversible.

There are many requirements that are not covered by these lists, some of them implicitly accepted. For example, associated with the use of particular tools and techniques, set by your company for whatever reason. But there are also likely going to be several requirements other than those of a technical nature. For example, sponsors and advertising mechanisms might impose restrictions on the "look and feel" or the layout of the user interface. Still other requirements might have to do with money/budgeting issues. Finally, beside functional, technical, and budgetary requirements, you might have performance requirements (e.g., related to response time and number of simultaneous users).

One thing is clear: the more requirements you write down, even just in a plain text file, the less likely you will be to make bad (and perhaps costly) discoveries down the line!

Design
From all the usually's and generally's that I have used so far, it must be clear to you that there is no silver bullet in OO development.  That is, nothing that will work in all circumstances. Nevertheless, your best bet when designing OO applications is to start by identifying and defining the key objects and their expected behaviour.

Keys in such an application are the users themselves and the video clips. Why? Because you see that the words "user" and "clip" appear in most requirements!

The questions you have to pose yourself then are: What are the properties of these objects? What must I be able to do with them in order to satisfy the requirements?

You should start with the properties and initially limit yourself to what is visible from the outside. You will probably find out that you need additional attributes when designing and coding individual methods, but those are implementation-dependent attributes, not intrinsic properties of the objects you are dealing with. That is, they are not directly determined by the requirements. It is best if you try not to mix them up from the very beginning. For example, the initial property list for the User class could look as follows:
•    Email address (mandatory).
•    UserID/nickname (mandatory).
•    First name (optional).
•    Middle name (optional).
•    Last name (optional).
•    Street address (optional).
•    ZIP code (optional).
•    State (optional).
•    Country (optional).
•    Password (mandatory).
•    Status: new, enabled, disabled (mandatory).

Don't be afraid to write down attributes about which you are not sure. Just flag them with "unsure" and move on. Once you cannot come up with more attributes, think about the methods.

Beside get and set methods for each attribute, what higher level operations need to be performed? Instead of looking directly at methods, you should consider what dynamic web pages your application needs, and deduce the methods from them. For example:
•    User: register.
•    User: login, including the "forgot password" button.
•    User: change personal data, including password.
•    User: update own clips (upload, delete).
•    User/Admin: select, display, and sort clips (owner, keywords, creation date, format).
•    User/Admin: send email to another user.
•    Admin: select, display, and sort users (userID, registration date, status).
•    Admin: display individual user's history.
•    Admin: change individual user's status.
•    Admin: reset individual user's password.
•    Admin: delete individual user's clips.
•    Admin: send email to all users.

These lists are certainly incomplete, but it should give you an idea of what I am talking about. Once you have listed the properties and the pages associated to each class, you should be able to define the methods of each class, including their parameters, without much struggling.

Implementation
Only one recommendation: if you have the choice, start developing the user interface first, and let that drive the rest of the application. At the beginning, it will be a mock-up with no functionality behind, but you should show it to possible interested parties (customer[s], colleague[s], friend[s], etc.) as soon as possible. This will maximise the probability that your application will be consistent and user-friendly. The sooner other people see what you are doing, the better.