Quote:Original post by etothex I don't see what's wrong with method #4 (using a "marry" function)
The problem is that the change in state may actually involve a large amount of internal activity on the part of both Man and Woman. Because that activity is specific to each class, putting it in a Marry method increases coupling between the classes. Even if Man and Woman have separate maintainers, both have to maintain the Marry function.
Hmmm... I suppose it depends on how more "complicated" you would make the system. For example, consider:
// SetWife, SetHusband should be privatevoid Man::SetWife(Woman* wife){ m_wife = wife;}void Woman::SetHusband(Man* husband){ m_husband = husband;}void Marry(Man* husband, Woman* wife) // Friend function of Man and Woman{ husband->SetWife(wife); wife->SetHusband(husband);}
Reasoning being, there is no reason why the wife's function "SetHusband" should have to have anything to do with changing the state of the husband. SetHusband does exactly what it is needed to do - set the wife's husband - and that can be described in the pre/post conditions of those functions (which, since they are private, only need to be known to the maintainer of that class and the marry function)
Quote:Original post by Sneftel Looks like method five, with additional thought paid to "remarriage" (which is a very good point....definitely something that should be a part of any approach). What are your thoughts on the idempotence issue? In fact, the way you've presented it makes it even more pressing: Should remarrying the same woman involve divorcing her first?
I must admit I didn't give that too much thought, I tried to rember how I solved a similar issue before. Right now I'm wondering if it might be possible to come up with a more general Coupling class, or mechanism, which more gracefully handles these problems...
Quote:Original post by etothex For example, consider:
*** Source Snippet Removed ***
Good point. The internal functions could then handle all the dirty work, without requiring complexity in Marry(). The point about SetHusband/SetWife being private is well taken... the reason I accessed the class members directly in my example is that a bare SetHusband/SetWife would violate invariants, but private functions don't need to worry about that.
I'd likely go with the "I heard you the first time" approach, and/or having a separate Marry function. If I was thinking in terms of abstract design aesthetics, I would prefer the Marry() function, since it seems neater and more balanced. If I was thinking about it from the perspective of being a practical programmer who just wants to get on with it in a reasonably safe way, I would probably go with "I heard you the first time" (although in fact it probably doesn't have any practical advantages over a separate Marry function).
If you wanted to be excessively OO about it, you could create a Marriage class to encapsulate the relationship itself*, but I doubt it's worth it, usually, and of course you then have to decide how to design the Marriage class and how to interface it with the Man and Woman classes. Actually, given that you're talking about state dependencies, then perhaps it would be possible to encapsulate the part of the state that is dependent on both objects.
I also found it quite funny that you were talking about "making coupling stronger" being a problem, given your example.
Edit: Oh, I see hymerman already suggested a Marriage class... as did c2_0
Any chance of a more real-world example?
John B
* I'm thinking something along the lines of: Man and Woman could each have a SetMarriage(), and the Marriage object holds references to the Man and Woman involved; so you create a Marriage() object and then SetMarriage() on each person. Marriage should perhaps be called MarriageCertificate.
The best thing about the internet is the way people with no experience or qualifications can pretend to be completely superior to other people who have no experience or qualifications.
Quote:Original post by JohnBSmall * I'm thinking something along the lines of: Man and Woman could each have a SetMarriage(), and the Marriage object holds references to the Man and Woman involved; so you create a Marriage() object and then SetMarriage() on each person. Marriage should perhaps be called MarriageCertificate.
That is definitely a Sixth Way. Probably not appropriate for the hat example, but in situations where the relation has "a life of its own" that may well be an option to consider.
Quote:I also found it quite funny that you were talking about "making coupling stronger" being a problem, given your example.
Yes... the irony of designing a husband and wife to have as little to do with each other as possible was not lost on me. [grin]
I like the third approach, myself. As far as breaking encapsulation goes, OO and encapsulation are there to make coding easier to write/read/maintain. When the code becomes more complex just to avoid "breaking encapsulation", it kind of defeats the purpose.
Quote:Original post by JohnBSmall * I'm thinking something along the lines of: Man and Woman could each have a SetMarriage(), and the Marriage object holds references to the Man and Woman involved; so you create a Marriage() object and then SetMarriage() on each person. Marriage should perhaps be called MarriageCertificate.
The problem I'd see with that is that you could potentially create a Marriage object with no people in it. I was going to suggest having it so that you construct a Marriage object with a Man and a Woman object, and the constructor sets both objects to point to itself, but then I realised that that's really just a rephrasing of method 4 (in the constructor of a friend class, instead of a single friend function).
I think my favourite approach seen here so far is ethotex's one... by making the private function on each object responsible for only updating itself, and then providing a public free function that forces you to call both private functions, I'd say you're actually being /more/ efficient with your code (as all the object-pair wranging is being done in a single shared function, instead of in both Man and Woman). If you don't like the free function aspect of it, you can always add a call-through member to each class (i.e. man->Marry(woman) == Marry(man, woman), and woman->Marry(man) == Marry(man, woman)).
Richard "Superpig" Fine - saving pigs from untimely fates - Microsoft DirectX MVP 2006/2007/2008/2009
"Shaders are not meant to do everything. Of course you can try to use it for everything, but it's like playing football using cabbage." - MickeyMouse
Quote:Original post by etothex For some reason, the idea of a "marriage" object just seems like a nasty solution to me. I think that would be going over the top on the OO. :)
Depends on the situation, I think. For this, I agree.
Of course, if you really wanted to go over the top, you would create a Priest class to perform the ceremony.
John B
The best thing about the internet is the way people with no experience or qualifications can pretend to be completely superior to other people who have no experience or qualifications.
