what kind of relationship is there between a common wall and the rooms that located next to it?

Question

I want to know whats the Relationship between a common wall (that are located In an adjoining room ) and the rooms.
As i know the relationship between a room and its walls is Composition not Aggregation (am i right ?)

And according to the definition of Composition the contained object can't be shared between two containers, whereas in aggregation it is possible.

now i am confused that whats the best modeling approach to represent the relationship between a common wall and the rooms located next to it ?

It would be highly Appreciated if you could provide your advices with some code.

|--------|--------|

Approch1:

(wall class ---- room class) /Composition

Approach2:

wall class ----- room class /Aggregation

Approch3:

we have a wall class and a Common wall class , Common wall class inherits from wall class

adjoining room class ---- (1) Common wall class /Aggregation
adjoining room class ---- (6) wall class / composition

Approach4: I am a developer not a designer :) so this is my idea :

class Room 
{
  private wall _firstwall  ;
  private wall _secondtwall;
  private wall _thirdwall  ; 
  private wall _commonwall ;

public Room( CommonWall commonwall)
 {
 _firstwall=new Wall();
 _secondtwall=new Wall();
 _thirdwall=new Wall();
 _commonwall=commonwall;
 }

}

Class CommonWall:Wall
{
 //...
}

// in somewher :

 static void main()
{
  Wall _commonWall=new Wall();
  Room room1=new Room(_commonWall);
  Room room2=new Room(_commonWall);
  Room [] adjacentRoom =new Room[2]{room1,room2};
}

Edit 1: I think this is a clear question but just for more clarification :

The point of the question is to find out whats the best pattern or approach to model a relationship for an object that is a component of two other objects in the same time.

and about my example : waht i mean by a "room" ?,surely i mean an enclosed square room with 4 walls and one door.but in this case one of these walls is a common wall and is shared between two adjacent rooms.

Answer 1

The answer to your question about the room and the wall is the answer to this question: "Can the wall exist without the room?"

I believe your scenario is using aggregation. Can the wall exist without the room? Sure it can. One could destroy the room by destroying three walls, but that remaining wall stands on its own. I think we're down to semantics now. This answer can change depending on how you view the walls in your scenario.

This link shows a concise way to think about it:

1. A "owns" B = Composition : B has no meaning or purpose in the system without A
2. A "uses" B = Aggregation : B exists independently (conceptually) from A

Same here:

Aggregation implies a relationship where the child can exist independently of the parent. Example: Class (parent) and Student (child). Delete the Class and the Students still exist.

Composition implies a relationship where the child cannot exist independent of the parent. Example: House (parent) and Room (child). Rooms don't exist separate to a House

From wikipedia:

Aggregation differs from ordinary composition in that it does not imply ownership. In composition, when the owning object is destroyed, so are the contained objects. In aggregation, this is not necessarily true. For example, a university owns various departments (e.g., chemistry), and each department has a number of professors. If the university closes, the departments will no longer exist, but the professors in those departments will continue to exist. Therefore, a University can be seen as a composition of departments, whereas departments have an aggregation of professors. In addition, a Professor could work in more than one department, but a department could not be part of more than one university.

Answer 2

There is many to many relationship between Room and Wall. (one wall can be used in two rooms and one room can have many walls.

Instead of having a class like "CommonWall", I would suggest resolve this many to many with with Mapping object and two 1-Many relationships.

public class Room 
{
public List<Wall> Walls{get;set;}

}

public class Wall
{
decimal length;
decimal width;
public List<Room> Rooms{get;set;}
}

public class RoomWallMapping
{
public int MappingID;
public Wall {get;set;}
public Room{get;set;}
}

Answer 3

Bob Horn made a point here, when a wall can exist independently from the room it has to be an aggregation.

But remember that you model how you want to see / manipulate them, so you can also decide that you mainly care about your rooms and see the walls as a side effect of the room, then this is a composition.

Aggregation model

You build the wall and that defines your rooms, your room is the just the space between the walls.

Thinking that way, the room does not need to have 4 walls, it's just an arbitrary set of walls: an open room can have 3 walls and a L shapes closed room might have 6.

This is the representation an architect or a builder will adopt.

Composition model

You want to see a room as a space with walls, then what you really care about is the view of the wall from the inside side of the room. In that case you do not car if the other room has a common wall, when you destroy your room, the inside side of the wall disappears with it.

A shared wall becomes an aggregation of two room-walls.

This might be the correct representation if you are planning an exhibition and want define where paintings will be placed.

Model what best fit your needs

In the end you model a representation and thus a simplification. Similarly there is no correct or best answer when modeling your representation, you should model your representation after your needs.

If you want to buy a car you tend to define book as composed of its pages, when you dispose it you dispose every pages. If you want to print a book you tend to spare parts you as aggregating folios composed of pages, if a folio is misprinted you can take another from the stock to assemble to final book.

Answer 4

It depends. There is always two sides to a wall. ;-)

In this sort of scenario I would use either use property injection or constructor injection, e.g.

public class Room
{
    public List<Wall> Walls { get; set; }
    public Room ( IEnumerable<Wall> walls )
    {
        Walls = new List<Wall>(walls);
    }
}

And then use a creational pattern such as a builder pattern to construct the rooms using the shared walls.

Answer 5

How you deal with Rooms and Walls depends on the task at hand.

I'll illustrate this with two examples, and then I'll get back to giving my answer to the actual "point" of your question.

First Approach (Navigating a 1 story Building):

Objective: I want to tell a Robot to move from its current location to the Copy Room.

I determine the dimensions of the building, say 100 ft, by 100 ft. Choose an axis, and make a grid of points. The robot may start at location (50,50). Next, I create a Graph where each edge represents one step to North, East, South, or West from that node to the corresponding node. Nodes separated by a wall have infinite weight, i.e. can't be passed through.

The Graph is represented in an adjacency-list.

Now I define a Room to be a polygon and list its verticies. To test if the robot is in the room, it must be within the area defined by the room's polygon. In this case rooms can overlap, especially since in real life standing in the doorway could mean you are in either room.

My robot can now navigate the building, move furniture, and whatever else it wants to do.

Second Approach: (Object Oriented)

• Building
  • Properties
    • Width, Length, Height, Geo-Spacial Coordinates, Age, etc.
  • OuterWalls
    • may be BrickWall, GlassWall, ConcreteWall, etc inherited from OuterWall
    • Properties: location, thickness, etc
    • Methods: DemolishWall(), PaintExterior( Color C ), etc.
  • InteriorWall
    • May be NorthSouthWall or EastWestWall.
    • Properties: hasDoorway, N/E color, S/W color, etc.
  • Room
    • Properties: Name, Location, Width, Length, etc.

Notice that in neither of these examples do the rooms directly refer to their walls.

Now to the actual point of your question. If two objects have a shared resource how should that be taken care of.

Parallel programming deals with shared resources in a variety of different ways.

1. Give each object a reference to the shared resource, make sure to synchronize or otherwise deal with concurrent behavior on the shared resource.
2. Make the shared resource available to each object as a global variable or through a singleton object, or a static resource in another class, or even a specific location in memory or file system.
3. Pass the shared resource between the concurrent parts in a predefined order or at predefined times.

Imagine a hotel with a shared bathroom between each two rooms:

HotelGuest A = new HotelGuest( new BusinessMan() );
HotelGuest B = new HotelGuest( new Programmer() );

A.Room = 101;
A.Bathroom = 7;
A.BathroomKey = getBathroomKey(7);

B.Room = 102;
B.Bathroom = 7;
B.BathroomKey = getBathroomKey(7);

//Asynchronously
A.RunDoBusinessStuff();
B.RunProgrammerStuff();

//but each has to lock bathroom7 when they use it, or it could be embarrassing.

But in the above example, how does the bathroom know which two HotelGuests have its key?

1. create a database with the current guests and the keys they have, and the bathroom can query the database (or list).
2. store references to A and B in the bathroom properties. (imagine a white-board in the bathroom listing its 'tenants').

Answer 6

If this was anything close to real problem, I don't think I'd want to compose the Room from plain Walls. It's more likely I'd have collection of RoomComponents or IRoomComponents that would be injected using constructor injection or property injection. There is also possibility of using injection framework for composing the Room, so that the framework takes care of lifetime of the objects.

If for a second I'd imagine that the problem was really so simple that there were just Room and Walls, then I guess your approach #4 looks like the way to go. I am not sure what would be a proper name to that, as you have both Aggregation and Composition in there. Another way is to set the common wall as a property(property injection as mentioned above), instead of passing through constructor.

And finally if I go into fantasy world like some others in this thread, then I quickly come to realize all your walls should be common walls! Say someone build another three walls around one of the walls of an existing room -> bam you have a new a room, and a new common wall. What to do now? You would probably want to change the existing wall to a new CommonWall right? So it seems inevitable having walls as properties in this case, otherwise every time you decide to construct a neighbor room, you'd have to recreate all neighboring rooms.