The constituents of an Object-oriented application
For my fellow students/programmers (and tutees):
Object-oriented applications rely on these four groups to create a unified whole that is flexible, diversifiable, and easily deconstructed and reconstructed to fit the current situation. In fact, it is a reflection of the present-day urban business.
Consider that businesses have a similar set of layers:
In fact, parallels could be drawn between programs and nearly anything due to the fact that applications are systems and everything can be interpreted as a system using the broadest interpretation of system.
That being that systems have:
Programs, specifically, are information manipulation systems.
When we also consider that every activity furthers our understanding of Existence (and we all hope for the better), that programs often refine data into information to enhance that understanding, and that programs are systems and, therefore, can virtually parallel anything (pun intended?), their diversity and reusability is paramount.
But let's come back down to Earth again. Our programs need to be practical and deal with the here and now because that's where we're at. As such, it is best when creating every program to start with something very specific and not as reusable since we're often facing deadlines and it keeps things simpler when we code this way. However, as your experience as a programmer progresses, you'll start seeing parallels in your code. Specifically, code blocks that are repeats of work you've done before. That's your cue to create a more general block of code that you only need create once (more) and then call (make use of) in your other programs.
That's precisely where our philosophy and reality meet in the object-oriented model (and programming in general to an extent).
We create the user interface as a separate set of code so if we need to migrate our application from a console to a GUI operating system or even to the web, we can simply deconstruct our application by pulling our UI layer out and putting a different one in.
We use the same idea with our data access layer. We may need to migrate our application between a file system, a database, or other external datastream like a raw data-collection device such as the LEAP I mentioned before.
The reason I separated the control layer from the class library is that we may also want to move and reuse our business virtual objects to another application. Or perhaps we have multiple applications relying on working with the same entities our business deals with. Ensuring consistency in how they are conceived and manipulated goes a long way towards creating a reliable system for the entire business.
Effectively, the only thing that is "stable" then, is what is often called our business logic which should be contained entirely in the control layer. This makes sense as once we have a singular business process created in code, it is unlikely to change as our business's stability is relying on the rules that govern it as its foundation. In case you don't think that's true, then it is likely the process you are considering is actually more than one process. Recall what I stated before about our objects. It also holds true to their methods:
"One of the major philosophies behind object oriented programming is a separation of processing into re-usable bundles that handle anything and everything related to a particular entity, be it a cultural or natural category, but no more. Indeed, what is put into practice is often less and that is a good thing as it increases the likelihood of reusability and you can always add more later."
Hence, a singular business process should go unchanged. Rather a collection of processes may increase their number or order of execution to handle new challenges or broaden their scope of capability.
So how does this all look in practice? I did promise to show how they interact...
Basically, the control layer is entirely a coordinator of active processes that are required to accomplish a particular series of tasks to enact a particular business practice.
As an example, since the current trend is towards web-based applications, even for in-house operations, the current model of processing is event-driven. This basically means that an application looks for particular events to occur and then launches processes that handle or respond to those events. The reason this is the case is the underlying logic and physical properties of the web.
Specifically, the web model includes a page that is inactive until the user triggers an event that requires a response from the server providing the web page. Then a new page is generated (for dynamic content web pages) or simply sent (for static content web pages).
The controller layer then determines what should be done based upon the information sent to it by the UI layer. It may have to call upon the data access layer to get information required to generate the appropriate response or instantiate new objects in the class library or likely both. It then controls the processing the data access and class library should do and finally constructs a set of information to send back to the UI. The control layer may even tell the UI to change which page or format the UI should display the information in. The UI then generates the newly received information from the control layer into the format the control layer specified.
Notice that the user interface layer, the data access layer and the class library never have direct communication with one another. This means that any of those pieces can be replaced with new pieces as needed to handle the current demands of the business. Visually, the interaction should look like this:
Next time: Besides reusability, programs rely upon repetition. Indeed, systems and computers especially are used primarily to do repetitious work and do it fast. Hence, I'll next talk about looping logic.
- User Interface Layer
- Controller Layer
- Data Access Layer
- Class Library
Object-oriented applications rely on these four groups to create a unified whole that is flexible, diversifiable, and easily deconstructed and reconstructed to fit the current situation. In fact, it is a reflection of the present-day urban business.
Consider that businesses have a similar set of layers:
- Public Relations (Customer Service, Human Resources, etc)
- Management (Executives, Board of Directors, Middle-management, etc
- Storage (Warehousing staff, Database Administrators, Distribution, etc
- Business-specific staff (stockers, clerks in retail; laborers in manufacturing, etc
In fact, parallels could be drawn between programs and nearly anything due to the fact that applications are systems and everything can be interpreted as a system using the broadest interpretation of system.
That being that systems have:
- Inputs/Outputs - points of interaction between itself and its environment
- Governance - rules that determine its behavior
- Liminality - an internal environment or threshold state for the media it works upon
- Internals - The internal constituents/structure that enacts change
Programs, specifically, are information manipulation systems.
When we also consider that every activity furthers our understanding of Existence (and we all hope for the better), that programs often refine data into information to enhance that understanding, and that programs are systems and, therefore, can virtually parallel anything (pun intended?), their diversity and reusability is paramount.
But let's come back down to Earth again. Our programs need to be practical and deal with the here and now because that's where we're at. As such, it is best when creating every program to start with something very specific and not as reusable since we're often facing deadlines and it keeps things simpler when we code this way. However, as your experience as a programmer progresses, you'll start seeing parallels in your code. Specifically, code blocks that are repeats of work you've done before. That's your cue to create a more general block of code that you only need create once (more) and then call (make use of) in your other programs.
That's precisely where our philosophy and reality meet in the object-oriented model (and programming in general to an extent).
We create the user interface as a separate set of code so if we need to migrate our application from a console to a GUI operating system or even to the web, we can simply deconstruct our application by pulling our UI layer out and putting a different one in.
We use the same idea with our data access layer. We may need to migrate our application between a file system, a database, or other external datastream like a raw data-collection device such as the LEAP I mentioned before.
The reason I separated the control layer from the class library is that we may also want to move and reuse our business virtual objects to another application. Or perhaps we have multiple applications relying on working with the same entities our business deals with. Ensuring consistency in how they are conceived and manipulated goes a long way towards creating a reliable system for the entire business.
Effectively, the only thing that is "stable" then, is what is often called our business logic which should be contained entirely in the control layer. This makes sense as once we have a singular business process created in code, it is unlikely to change as our business's stability is relying on the rules that govern it as its foundation. In case you don't think that's true, then it is likely the process you are considering is actually more than one process. Recall what I stated before about our objects. It also holds true to their methods:
"One of the major philosophies behind object oriented programming is a separation of processing into re-usable bundles that handle anything and everything related to a particular entity, be it a cultural or natural category, but no more. Indeed, what is put into practice is often less and that is a good thing as it increases the likelihood of reusability and you can always add more later."
Hence, a singular business process should go unchanged. Rather a collection of processes may increase their number or order of execution to handle new challenges or broaden their scope of capability.
So how does this all look in practice? I did promise to show how they interact...
Basically, the control layer is entirely a coordinator of active processes that are required to accomplish a particular series of tasks to enact a particular business practice.
As an example, since the current trend is towards web-based applications, even for in-house operations, the current model of processing is event-driven. This basically means that an application looks for particular events to occur and then launches processes that handle or respond to those events. The reason this is the case is the underlying logic and physical properties of the web.
Specifically, the web model includes a page that is inactive until the user triggers an event that requires a response from the server providing the web page. Then a new page is generated (for dynamic content web pages) or simply sent (for static content web pages).
The controller layer then determines what should be done based upon the information sent to it by the UI layer. It may have to call upon the data access layer to get information required to generate the appropriate response or instantiate new objects in the class library or likely both. It then controls the processing the data access and class library should do and finally constructs a set of information to send back to the UI. The control layer may even tell the UI to change which page or format the UI should display the information in. The UI then generates the newly received information from the control layer into the format the control layer specified.
Notice that the user interface layer, the data access layer and the class library never have direct communication with one another. This means that any of those pieces can be replaced with new pieces as needed to handle the current demands of the business. Visually, the interaction should look like this:
Next time: Besides reusability, programs rely upon repetition. Indeed, systems and computers especially are used primarily to do repetitious work and do it fast. Hence, I'll next talk about looping logic.
posted by rhacer at 4:53 PM
0 Comments:
Post a Comment
<< Home