What is the relationship between the common wall and the rooms next to it?

Question

I want to know what is connected between the common wall (located in the next room) and the rooms.
How do I know the relationship between a room and its walls 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 the best approach to modeling is the connection between the common wall and the rooms located next to it?

It would be highly appreciated if you can provide your advice 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, the general wall class is inherited from the wall class

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

Approach4: I'm a developer, not a designer :) so here 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 { //... } 

// somewhere:

  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 only for more clarification:

The question is to find out what is the best template or approach to model the relationship for an object that is a component of two other objects at the same time .

and about my example: “I mean“ room? ”Of course, I mean a closed square room with 4 walls and one door. But in this case one of these walls is a common wall and is divided between two neighboring rooms.

Answer 1

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

I believe your script uses aggregation. Can a wall exist without a room? Of course it is possible. You can destroy a room by destroying three walls, but this remaining wall stands on its own. I think that now we are stopping semantics. This answer may vary depending on how you view the walls in your scenario.

This link shows a concise way to think about it:

• A "belongs" B = Composition : B has no meaning or purpose in a system without A
• A uses "B = Aggregation : B exists independently (conceptually) of A

The same here :

Aggregation refers to a relationship in which a child can exist independently of the parent. Example: class (parent) and student (child). Delete class and students still exist.

Composition implies a relationship in which the child cannot exist independently of the parent. Example: Home (parent) and Room (child). The rooms do not exist separately from the house.

From wikipedia :

Aggregation differs from the usual composition in that it does not imply ownership. In the composition , when the owner object is destroyed, as well as the contained objects. In aggregation, this is optional. For example, a university owns various departments (e.g. chemistry), and each department has several professors. If the university closes, there will be no more departments, but professors in these departments will continue to exist. Therefore, a university can be considered as a composition of departments, while departments have a totality of professors. In addition, a professor could work in more than one department, but the department could not be part of more than one university.

Answer 2

There are many different relationships between a room and a wall. (One wall can be used in two rooms, and in one room there can be many walls.

Instead of having a class like “CommonWall”, I would suggest allowing many for many to do this using the 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 of a room, it should be aggregation.

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

Aggregation Model

You are building a wall that defines your rooms, your room is just the space between the walls.

Thinking in this way, there is no need to have 4 walls in the room, it's just an arbitrary set of walls: an open room can have 3 walls, and a closed room of L shapes can have 6.

This is a view that an architect or builder will accept.

Composition model

You want to see the room as a space with walls, what you really need is a view of the wall from the inside of the room. In this case, you do not transport the car, if there is a common wall in the other room, when you destroy your room, the inside of the wall disappears along with it.

A common wall becomes a combination of two wall rooms.

This may be the right idea if you are planning an exhibition and want to determine where the paintings will be displayed.

The model that best suits your needs

In the end, you model the view and, therefore, simplify it. Similarly, there is no right or better answer when modeling your presentation; you must model your presentation after your needs.

If you want to buy a car, you usually define a book consisting of its pages, at its disposal you have all the pages. If you want to print a book, you usually deal with spare parts, which, like a collection of folios consisting of pages, if the folio is sealed, you can take another copy for assembly in the final book.

Answer 4

It depends. There are always two sides of the wall .; -)

In this scenario, I would use either property injection or constructor injection, for example.

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

And then use a creation template, such as a designer template , to build rooms using common walls.

Answer 5

How you relate to rooms and walls depends on the task.

I will illustrate this with two examples, and then return to giving an answer to the actual "point" of your question.

First approach (Navigation in a 1-story building):

Purpose: I want to say that the robot will move from its current location to the Copy room.

I determine the dimensions of a building, say 100 feet, per 100 feet. Select an axis and make a grid of points. A robot can start from a place (50.50). Then I create a Graph where each edge represents one step north, east, south, or west from this node to the corresponding node. The nodes separated by the wall have infinite weight, that is, they cannot be passed.

The graph is presented in the adjacency list.

Now I define the room as a polygon and a list of its vertices. To check if the robot is in the room, it must be in the area defined by the polygon of the room. In this case, the rooms may overlap, especially since in real life standing in the doorway could mean that you are in any room.

Now my robot can move around the building, move furniture and everything he wants to do.

Second approach: (object oriented)

• Construction
  • The properties
    • Width, length, height, geospatial coordinates, age, etc.
  • Outerwalls
    • may be BrickWall, GlassWall, ConcreteWall, etc. inherited from OuterWall
    • Properties: location, thickness, etc.
    • Methods: DemolishWall (), PaintExterior (Color C), etc.
  • Interiorwall
    • Maybe NorthSouthWall or EastWestWall.
    • Properties: hasDoorway, N / E color, S / W color, etc.
  • room
    • Properties: name, location, width, length, etc.

Please note that in none of these examples are the numbers directly related to their walls.

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

Concurrent programming deals with shared resources in various ways.

• Give each object a link to a shared resource, make sure that you synchronize or otherwise use parallel behavior on the shared resource.
• Make a shared resource available for each object in the form of a global variable or through a singleton object or a static resource in another class or even in a specific place in memory or in the file system.
• Transfer the shared resource between parallel parts in a predetermined order or at predetermined times.

Imagine a hotel with a shared bathroom between 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 example above, how does the bathroom know which two HotelGuests have their own key?

• create a database with current visitors and their keys, and the bathroom can request a database (or list).
• Store references to A and B in the properties of the bathroom. (imagine a whiteboard in the bathroom listing its tenants).

Answer 6

If this were something close to the real problem, I don’t think I want to make a room out of simple Walls. Most likely, I will have a collection of RoomComponents or IRoomComponents that will be injected using constructor injection or property injection. There is also the possibility of using an injection frame to compose a room, so the structure takes care of the life of the objects.

If for a second I think that the problem was really so simple that there were only rooms and walls, then I assume that your approach number 4 looks like a way. I am not sure what would be the right name, since you have both Aggregation and Composition. Another way is to set the common wall as a property (nesting properties as described above), instead of going through the constructor.

And finally, if I go to a fantasy world, like some others in this topic, then I quickly realized that all your walls should be common walls! Say someone is building three more walls around one of the walls of the existing room → bam, you have a new room and a new common wall. What to do now? You probably want to change the existing wall to the new CommonWall? Therefore, in this case, the presence of walls as properties seems inevitable, otherwise every time you decide to build a neighboring room, you will have to recreate all the neighboring rooms.