Task Oriented Programming

We have come through a long journey to understand the OOD and OOP with
design patterns. In contrast we are coding the computer in order to do
a task. We are breaking a task into several parts and naming it as
objects where as we consider the objects are the prelimanary building
block for a solution. If we can develop a language to support task
breaking and programming; the entire processes will be very easy to
accomplish. Under this topic we have to use a task pattern like
Task<-based on <- task1<-based on <- task3 (prellimanry task)
Task<-rely on<- task2<- rely on <- task4 (dependancy task)
Task<-work on<-task1<-work on<-task2<-task3<-task4 (working rule)
Task->handles by ->task1->handles by->task2-> and so on (handling
rule)

I think the time has arrived to re-think a new way of software
programming, which may develop the next generation.

Conventional structured programming is the "Task Oriented Programming".

Object Oriented Programming moves us away from this apporach by
focusing on the tasks as interactions between objects that represent
real-world objects.

Deepa
--
http://www.EventHelix.com/EventStudio
EventStudio 2.5 - Generate sequence diagrams from plain text input

Conventional structured programming is the "Task Oriented Programming".

Object Oriented Programming moves us away from this apporach by
focusing on the tasks as interactions between objects that represent
real-world objects.

Deepa
--
http://www.EventHelix.com/EventStudio
EventStudio 2.5 - Generate sequence diagrams from plain text input

"EventHelix.com" <eventhelix@gmail.com> wrote in
news:1102389371.079074.160380@c13g2000cwb.googlegroups.com:

> Conventional structured programming is the "Task Oriented Programming".
>
> Object Oriented Programming moves us away from this apporach by
> focusing on the tasks as interactions between objects that represent
> real-world objects.

Blech. That "real-world object" stuff is nonsense, and a Task has as much
right to be an object as anything else.

> > Object Oriented Programming moves us away from this apporach by
> > focusing on the tasks as interactions between objects that represent
> > real-world objects.
>
> Blech. That "real-world object" stuff is nonsense, and a Task has as much
> right to be an object as anything else.

You are correct. We must be able to represent Task as object in our model
space. And there is nothing in OO that stops you from doing that.
Objets are real world entities and includes both physical as well as
conceptual entities.

regards,
Shashank