StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
primarykey
Id
7050257
data
AcceptedAnswerId
0
AnswerCount
0
ClosedDate
CommentCount
0
CommunityOwnedDate
CreationDate
2011-08-13T11:57:33.793
FavoriteCount
0
LastActivityDate
2011-08-13T11:57:33.793
LastEditDate
LastEditorUserId
0
OwnerUserId
2603665
ParentId
7049546
PostTypeId
2
Score
1
ViewCount
0
LastEditorDisplayName
text
Body
What I think you have found in your pretty nice example and explanation is that OO does not solve all problems well. As long as the responsibility is well shaped and sharp, everything is fine. And as long each responsibility fits in exactly one bucket (the class), it is pretty easy to design. But here you have a tradeoff: <ul> <li>If I define for each responsibility a separate class, I will get a bloated design that is pretty difficult to understand (and sometimes to maintain).</li> <li>If I include for each separate responsibility at least one interface, I will get more classes and interfaces than I need.</li> <li>If I decide that one of the two classes is responsible for the relation as well, this one object has more knowledge than usual about the other.</li> <li>And if you introduce in each case a mediator or something similar, your design will be more complex than the problem.</li> </ul> So perhaps you should ask the questions: <ul> <li>What is the likelihood that the relation between the 2 objects will change?</li> <li>What is the likelihood that the relation will exist between more 1 type of objects at each end?</li> <li>Is that part of the system a highly visible part, so that a lot of other parts will interface it (and therefore will be dependent on it)?</li> </ul> Take the simplest solution that could possibly work and start with that. As long as the solution is kept simple, it is only your code (you don't design a library for others), there are chances that you can change the design later without hassle. So in your concrete case, <ol> <li>the board field should have access to the whole board XOR</li> <li>the figure on the field should have the responsibility of moving XOR</li> <li>there should be an object type (ChessGame?) that is responsible for the overall knowledge about moving, blocking, attacking ...</li> </ol> I do think that all are valid, and it depends on your special "business case" which one is the most valid.
Tags
Title
singulars
PostAcceptedAnswerId
1. This table or related slice is empty.
PostParentId
1. POOOP: How do I deal with objects that have mutual relations?
 singulars
 PostTypePostTypeId
 PTQuestion
PostTypePostTypeId
1. PTAnswer
UserLastEditorUserId
1. This table or related slice is empty.
UserOwnerUserId
1. USmliebelt
plurals
PostLinksPostIdRelatedPostId
1. This table or related slice is empty.
PostLinksRelatedPostIdPostId
1. This table or related slice is empty.
PostsAcceptedAnswerId
1. This table or related slice is empty.
PostsParentIdCreationDate
1. This table or related slice is empty.
VotesPostIdCreationDate
1. VO
 singulars
 PostPostId
 PO
 UserUserId
 This table or related slice is empty.
 VoteTypeVoteTypeId
 VTUpMod
CommentsPostId
1. This table or related slice is empty.

Querying!

Guidance

A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.