Object oriented programming leads to a more layered approach to programming than is available with structured programming. A procedural based application typically will start at line 1 and will continue in a linear manner until line xxxx is reached. Here the application will terminate or, if this is not desirable, the entire application must be nested inside a gigantic loop to restart the process again. Using OO, and more importantly OO design methods, an application can be split into logical elements. For instance, a sales order processing application may be defined as the interaction of a customer, the parts and the accumulation of these to form an order. As there is specific information needed for a customer (name, address, account no.
) this would logically be suitable as an object in its own right. The same could be said for parts (part no. , description, price) and this too would be worthy as a separate object. An order is also a credible object but is merely an accumulation of customer and part objects with some extra information to determine order no. , despatch method etc. Having defined these ‘business’ objects it then needs to be considered how these can be pieced together to form the process of creating a sales order.
There are two elements to this, firstly the users view or screens that are required to operate the process and secondly the logic behind that process. What I have tried to briefly describe is a methodology called MVC (Model, View, Controller).
The Term Paper on The Policy Process Part Iii
Process, Part II University of Phoenix HCS 455 The Policy Process, Part II In the paper the author discussed The Policy Process, Part I on how Medicare part D became a policy. The author discussed the details on the formulation, legislative, and implementation stages of the policy. Now time to look at the final stages of the process, of Medicare Part D. Which are evaluation, analysis, revision, ...
The model being the objects, the view being the screens displayed to the user and the controller is the application logic that handles the interaction between the users input (view) and the objects themselves. The benefits of contracting applications in this manner are great, for example, if an additional piece of information is needed to be stored against a customer (fax number say) this would only affect the customer object and the customer screen (s).
No change would be required to the logic of producing the sales order (the controller).
Similarly if it was decided that the parts of an order had to be entered before the customer was chosen, this would only required a change to the controller or application logic. It also has the benefit of allowing different front ends (web browser or web service) to be served using the same underlying application. For me this represents the most logical way of constructing an application, breaking down the logical elements into their lowest form and keeping each as separate and independant as possible.
