Object that can live in 3 different objects at same time? 1

[zooxmusic]

HI all, I have a situation that I can't seem to find the correct pattern for. I am wondering if anyone see's this clearly.

I basically have a grid that has named locations.
They are all at the size of the lcd, being 20 foot.
I can have 20 foot objects and 40 foot objects.
A 20 foot object is easy because it lives in only one location.
A 40 foot object actually lives in 3. The 20 foot on the left, the 20 foot on the right and a new virtual location because we need to reference it by one value in one perspective and yet in another we need to see which two twenty foot locations it takes up.

So our naming is like;

odds are the 20 foot and when we put a 40 foot object in 2 twenty location it creates an even location.

I have no clue on how to model this "Holy Trinity"


Right now all I have is

Twenty
----------
id
customName
isoName

Forty
-----
id
customName
isoName

Mixed
-----
fortyId
twentyId




Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[EdwardJS024]

Not sure I am understanding the whole grid thing..From what i can understand:

A Grid is just some abstraction that represents a 20' foot area?

And, you have objects with different lengths -- 20 and 40' that needs to lay in the grid?

Is this right?

 

[zooxmusic]

Hi Ed, thats kind of it, they are actually locations in a yard that are defined at 20 foot intervals but there are 40 foot objects that take up two 20 foot locations. So the problem is a twenty foot object can live in location 1 lets say and another twenty foot object can live in location 3. AND a forty foot object will actually live in location 1 AND 3 but we need to resolve to only one location per object. So what we do is call that location 2. Which really is a virtual name for 1 and 3.

Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[zooxmusic]

you know what, yes that is it. What you said

Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[stevexff]

zoo

'grid' kind of implies a two-dimensional space, like a chess board. But your grid seems to be constrained to one axis, in 20' chunks, more like positions along a ruler. Is this correct? Or is your yard laid out in 20' squares, and a 40' item actually occupies 4 squares?

 

[zooxmusic]

Ed, It is like a chess board. That is a good analogy. my forty foot objects will only take up 2 ajacent squares not four and a twenty will only take up one. It would be like

___________________
| | |
| | |
| | |
----------------------------

(1) (3) (20 foot names)

(2) (40 foot name)


now the 40 will take up both and it needs to be stored as 2 not 1 AND 3 although in some perspectives we do say it is in 1 and 3.


Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[stevexff]

zoo

Because of the odd-even scheme, the first time a 60' thing comes into the yard, your system breaks. Irrevocably.

You need a Yard object that manages a fixed sized collection of YardSlots. YardSlots hold a reference to a Thing if occupied, or null if not. So you can ask a YardSlot what it contains. Yard has a private method for finding empty slots of a given size. Caveat: in our zero-based array chessboard example, slot 7 is NOT next to slot 8 for allocation purposes, it's in the next row...

If a Thing knows how big it is, then the Yard methods would be

Yard.add(thing) // adds Thing
Yard.locate(thing) // returns collection of YardSlots occupied by Thing
Yard.remove(thing) // removes Thing from yard 

Yard.hasroom(thing) // check for space

so a client object can check to see if there is room for Thing in the yard, add it, find it later, and finally remove it. (note that add() should invoke hasroom(): defensive coding, add() can throw an exception if the yard is full.)

This also has the advantage that the allocation of yard space is all inside the Yard class. If you want to get flashy later on, you can add a clever algorithm to stop fragmentation of the yard space that gets invoked under the covers of add(), perhaps allocating 20' things from one end, and 40' things from the other. You could even include a makeroom() method that produces a list of internal thing movements needed to defragment the yard space.

 

[zooxmusic]

Thanks steve,
Actually I have the 60 foot object in mind too but as of now in the world that isn't a reality. The names are just an example. We could use anything, ABC it doesn't have to be odd/even, although it is defined as a standard in my business. I just need to make sure that I can customize the "Virtual" name and resolve it if an object takes up 2 or more locations to only one name/location. I understand what your saying and that is great, makes it much more clear becasue I am stuckin the way we are doing it-MULTI, MULTI, MULTI responsibility!

More info would be that there is infact a Yard object then the Yard is broken into Area's then each Area has a Block and each Block has Rows, Columns and Tiers. So if I said Yard.locate(thing) I would have to return all of it right?

And from another perspective I have a Ship that is kindof the same format except it has Bays, Stacks and Tiers and the client tells me where to put it exactly. I suppose it is two different things yet there is much that is similar.

Brian

Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[zooxmusic]

Hi steve, I need a little more help with explaining this to my boss. I know inherantly that it is not the "thing"'s responsibility to know where it is but she is not so convinced. She is thinking I should say thing.whereAreYou(). Is this also right. Doesn't seem so to me.

Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[stevexff]

Brian

As for returning the whole lot, Tier seems to be the lowest common denominator. Maybe you can just return a collection of zero to n Tiers. The Tier knows where it is in the Location, so Tier.locationstring() = "SS Marie Celeste, bay 23, stack 7, tier 2".

If you always need to resolve to a single location, consider the way that memory allocation gets done. You ask for 200 bytes of memory, the OS returns a start address and maybe a length. The OS manages its memory in pages, usually 4K long. If you ask for 2M, the OS has to find 512 contiguous pages of storage (possibly moving other stuff around, or even off to disk to clear enough space first). But you don't care about this - all you need to know is the start address and the length. Likewise, if you store a 20' thing in a Tier, you know where it is exactly. But if you stored a 40' or 60' thing in the same place, you could still find it by going to the position of the first Tier that it occupies. Once you have found Thing, you can always ask it how big it is...

I'm guessing here that your boss wants to be able to locate Thing wherever it is, in the Yard, on the Ship, etc, without having to ask each of them in turn, which seems a reasonable idea.

Perhaps if we abstract Location, and have Yard and Ship inherit from it? Then we could add a Location reference to each Thing. This gets updated whenever a Thing gets added to or removed from a Location. The Thing doesn't know the details of where it is exactly, just that it's on the Ship, in the Yard or similar. Once we have a reference to Location in Thing, if we need to know the detailed position, we can add a convenience locate() method on Thing. locate() just calls Location.locate(this). Ship or Yard still has the responsibility in the concrete implementations of the finder methods. This means that each conctrete Location can have its own way of cataloguing and finding things. NB this even allows different Locations to have different sized Tiers. If you ask a Ship with 30' Tiers to accommodate a 40' Thing, it will allocate two Tiers, where only one Tier would be needed in the Yard.

I suppose that the client tells you where to put the Thing in the Ship because of the need to balance the load equally. The Thing already knows how big it is. If it knew how much it weighed then you could even allow Ship.add(thing) to manage its own loading, as it could ask the Thing for it's size and weight, and calculate the best place to put it.

 

[zooxmusic]

Thanks steve. So just on the knowing the length point. Lets say I put a 40 foot thing into location 1. Now it really also exists in location 3 (or whatever we call it). Would I know what is in location 3 from the location 3 perspective? And sometimes I want the 40 foot to extend forward or backward depending on how I set up the locations. Meaning I could drop the thing into location 3 and depending on how I set up the location, I may want the extension to defer to location 1.



Spend like you don't need the money,
love like you've never been hurt and dance like no one's watching!

 

[stevexff]

Each of the Tiers has a reference to the Thing it contains. If it's a 40' Thing, then two Tiers will have references to it. If you call Location.locate(Thing), you get back a collection of two Tiers. If you have a Thing, you can find out where it is. If you have a Tier, you can find out what it contains.

All the forwards and backwards stuff is not relevant to the problem space. The whole point of OO is that you encapsulate the Location management within the Location. This makes the coding in your client objects much simpler, as all they need to know is[ul][li]How to add something to a Location[/li][li]How to find it again[/li][li]How to remove it from the Location[/li][li]And maybe a couple of Location methods to list out all the Things it contains, produce a floorplan, or loading statistics[/li][/ul]