aspose file tools*
The moose likes OO, Patterns, UML and Refactoring and the fly likes Object Autonomy Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Object Autonomy" Watch "Object Autonomy" New topic
Author

Object Autonomy

Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

Hi folks.

When designing, is it fair to say that keeping Objects as autonomous as possible is a good goal to keep in mind?

I am having trouble reworking my procedural ideas into Objects; specifically where to put my logic.
In other words, if x, then y, then z or a. Assuming that x,y,z, and a are all autonomous objects, how do I tell those objects when to go do their thing? Do I need another object that defines the flow of these worker objects?


‎"The greatest of all weaknesses is the fear of appearing weak." - JB Bossuet
Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

I think maybe my question lacks detail. I'll try and make my question more specific.

Using my example above, I have objects x,y,z, and a. Each has to fire in a particular order. Rather than creating a new y from the end of the x and z from the end of y (and so on) I have a controller object that sequentially creates the next object in line. My thought was that keeping the objects operation autonomous from the the others was a good oop design choice.

Here is where I am having trouble. Each object has a decision to make that will affect how the following objects behave OR a later object must change the way a prior object behaves. Rather than using a bunch of embedded if statements, I chose to use the polymorphism (static factory) technique to implement my logic. This works great. However, lets say that I have to make a change to the instance of x once I have gotten to A, based on some logic in the preceding objects. Aside from passing the instance of X through all of the logic instance calls, the only other option I see is to keep all of the logic in the control class and use nested ifs to proceed through to the final class. Assuming that I have instantiated all of the objects in the control object I would be able to access the original reference to X and do what I need to.
Here, the problem is that if I want to keep the object A going in its current state, but I must create new versions of the other objects as well as the control object (think timers; once you .cancel() them they are gone until a new instance of the containing class is created) then my reference to A is now lost and I'm in limbo. I have fallen victim to cyclical thinking on this and feel like I cannot see the forest for the trees.

Hopefully I haven't made this more confusing; appreciate any help people could offer.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18669
    
    8

The whole idea of objects "firing" and being "later" or "prior" objects just sounds wrong to me.
Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

It probably is. I know I'm stuck thinking procedurally; trying to look at things differently.

Oh, and Hi Paul.
Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

Paul Clapham wrote:The whole idea of objects "firing" and being "later" or "prior" objects just sounds wrong to me.


So maybe this is a better question. Objects do stuff. In programs stuff has to happen in a certain order. Some objects will act differently based on results of carrying out other object's stuff. How do I go about directing this? There has to be some kind of master orchestrator or process flow doesn't there?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18669
    
    8

Sure, the "controller" is a pretty common pattern. A lot of frameworks in the Java world are built on the "MVC" ("Model, View, Controller") pattern.
Madhan Sundararajan Devaki
Ranch Hand

Joined: Mar 18, 2011
Posts: 312

You may use the "Builder" pattern.


S.D. MADHAN
Not many get the right opportunity !
Jan Cumps
Bartender

Joined: Dec 20, 2006
Posts: 2503
    
    8

Madhan Sundararajan Devaki wrote:You may use the "Builder" pattern.

Madhan, Builder is a pattern for object creation. The original poster's question is about how to control objects later on in the program.


OCUP UML fundamental and ITIL foundation
youtube channel
Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

Paul Clapham wrote:Sure, the "controller" is a pretty common pattern. A lot of frameworks in the Java world are built on the "MVC" ("Model, View, Controller") pattern.


Ok good. You mentioned a controller in a previous thread; I didn't know what that was at the time so I went and read about MVC. In fact, I now have a controller class and that pertains to the original question.


I have a scaled down example of what I am trying to do and hopefully my question will be clearer. We'll sense for a cake, frost a cake, check the frosting, then start over.
This first diagram (bigController) shows a giant controller object; this example is simple, but even here you can see the controller is kind of a wreck already with all of the if statements. By the time I got through with all of my actual code, the controller was really hard to read with all of the nested if statements and was easily broken by a change. In addition I struggled , with how to keep the reference variable and pass it when I needed to as well as stopping timer objects and updating the Display. After working on the 2nd method and drawing this out I think I have a better handle on those things now and could fix it if I had to. The controller is still a mess though and I don't think there is much I can do with that.

So in the 2nd attempt (smallController) I decided to use the class factory to break up my conditionals. This creates a lot more classes but I think its easier to navigate. Also, each object doesn't have to return anything to the controller to move forward; I wrote doTask() methods inside of them so that I could define whatever I wanted to happen next. If I want to use them again I can extend them and override the doTask() methods. The down side is that I have to pass several object references through several legs of the factory statements that don't need them in order to get them where I need them since there isn't a global controller directing the band.

So questions I have:
1) Why does the idea of creating objects in a definitive order and referring to them as "later" and "prior" sound wrong in these examples? We have to have a cake before we can frost and frost before we can check the frosting and correct frosting in order to start again. I don't understand how else we could do that.

2) Given both of the examples I have, which is better design (if either of them)? This is a big question for me. I have written my project in 3 ways and they all work. Using static methods/variables (which as we discussed, is totally wrong), using the giant controller, and then using autonomous objects with worker methods that themselves point to the next task in line.

I drew this qucikly so forgive any mistakes I might have made.







[Thumbnail for bigController.jpg]


[Thumbnail for smallController.jpg]

Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18669
    
    8

Cory Hartford wrote:
1) Why does the idea of creating objects in a definitive order and referring to them as "later" and "prior" sound wrong in these examples? We have to have a cake before we can frost and frost before we can check the frosting and correct frosting in order to start again. I don't understand how else we could do that.


In my mental model of that process there's only one object. The cake. Its state changes as time goes on, but there's only a cake. If your model has "unfrosted cake" and then "frosted cake" as two separate objects then I think that's the source of most of your problems.

As for the two pictures you posted, I'm sorry, I couldn't make any sense out of either of them. Normally in object-oriented design you provide a description of an object in terms of what attributes it has and what actions it can perform. I didn't see anything like that.
Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

I feel like I'm in the Matrix.

"There is no spoon".

Let me think about this for a while.

Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

Paul Clapham wrote:
Cory Hartford wrote:
1) Why does the idea of creating objects in a definitive order and referring to them as "later" and "prior" sound wrong in these examples? We have to have a cake before we can frost and frost before we can check the frosting and correct frosting in order to start again. I don't understand how else we could do that.



As for the two pictures you posted, I'm sorry, I couldn't make any sense out of either of them. Normally in object-oriented design you provide a description of an object in terms of what attributes it has and what actions it can perform. I didn't see anything like that.


I thought about drawing them in UML but it made more sense to try and define how the process flowed. Maybe thats what I ought to do; draw the stuff in UML and see if that helps.
Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

Paul Clapham wrote:
Cory Hartford wrote:
1) Why does the idea of creating objects in a definitive order and referring to them as "later" and "prior" sound wrong in these examples? We have to have a cake before we can frost and frost before we can check the frosting and correct frosting in order to start again. I don't understand how else we could do that.


In my mental model of that process there's only one object. The cake. Its state changes as time goes on, but there's only a cake. If your model has "unfrosted cake" and then "frosted cake" as two separate objects then I think that's the source of most of your problems.


If we were drawing a virtual cake then I'd agree.
Picture a real life assembly line with automation. A sensor sends a signal to indicate there is a cake there or there is not. A real life cake is pushed onto a pad with a pneumatic arm. We then have to tell the frosting automation to begin frosting. Once complete, we have to tell the frosting camera to check the frosting quality. If the frosting is good, we wait until the sensor is clear and begin looking for a new cake. If it is not, we tell the frosting automation to go back and repair the error. The cake is fixed, sent on its way and we begin looking for another cake.
My documents attempted to show that real life physical process, how my program would manage those interfaces (voltage conditions, pneumonic commands over socketConjnections etc. Not OO interfaces) as objects and how the either the controller or each interface object would key the next piece of automation.
This really is my biggest problem. I have a hard time understanding how to take real life process and objectify it.
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18669
    
    8

I think the goal of "objectifying" a process is the wrong one. Or at least, I think you may be objectifying things which shouldn't be objects.

In your scenario I see these object classes: assembly line, cake, automaton. The assembly line might have a cake, or perhaps more than one cake. The cake is a cake, which might be frosted or not. The automaton doesn't have any attributes that I can think of right away, but it can be given a reference to a cake and determine whether that cake is correctly frosted.

Now there's a whole process about cakes appearing and being frosted and being checked and disappearing, but none of the steps in that process are necessarily objects.

And there might be more than one kind of automaton. Certainly the idea of having a controller which schedules the actions of the assembly line and the automaton(s) would be the way to go, but don't think of those actions as being objects. Not at the top-level design stage, anyway.
Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

So would those steps reside inside of an object? Or be behaviors of one of the objects that you listed?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18669
    
    8

Cory Hartford wrote:So would those steps reside inside of an object?


Just because you have a noun ("step") that doesn't mean you have to make it an object in your object model. Some nouns make better objects than others.

Or be behaviors of one of the objects that you listed?


Yeah, that's better.
Cory Hartford
Ranch Hand

Joined: May 16, 2011
Posts: 82

Very helpful. Thanks Paul.
 
Consider Paul's rocket mass heater.
 
subject: Object Autonomy