OOP question: correct obect composition in C#
-
Hi, I have a question on correct usage of object composition. This is the situation I'm facing:
class Address
{
// An address is composed of several fields
private byte _FieldA;
private byte _FieldB;
private byte _FieldC;// Each field is exposed with a public property public byte FieldA { set { \_FieldA = value; } get { return \_FieldA; } } // ... and so on for the other fields // I have several useful public methods for address manipulation public void SetAddress (byte fieldA, byte fieldB, byte fieldC); public void DoStuff(...) public void DoOtherStuff(...) ...}
class Message
{
// A message contains 2 addresses
public Address SourceAddress = new Address();
public Address DestAddress = new Address();
}A client which instantiates a message should only be able to access the address fields and to invoke SetAddress(). By declaring
SourceAddressandDestAddressobjects as public, I can write things likemessage.SourceAddress.FieldA,message.DestAddress.SetAddress(), with no need for additional code. However, I also expose other methods likeDoStuff()etc, which a message should not be able to call. On the other hand, if I declareSourceAddressandDestAddressas private, I can control what I expose to the client but I'm also forced to add a lot of code: public properties and methods likeSourceAddressFieldA,SourceAddressFieldB,SetSourceAddress(), all duplicated forDestAddress... this means a lot of code duplication, and less flexibility (imagine if I have to add otherAddressfields toMessage...). Is there a "sweet spot"? Is there a correct (or better, preferred) way to expose the behaviour of child objects in C#? Regards, Andrea -
Hi, I have a question on correct usage of object composition. This is the situation I'm facing:
class Address
{
// An address is composed of several fields
private byte _FieldA;
private byte _FieldB;
private byte _FieldC;// Each field is exposed with a public property public byte FieldA { set { \_FieldA = value; } get { return \_FieldA; } } // ... and so on for the other fields // I have several useful public methods for address manipulation public void SetAddress (byte fieldA, byte fieldB, byte fieldC); public void DoStuff(...) public void DoOtherStuff(...) ...}
class Message
{
// A message contains 2 addresses
public Address SourceAddress = new Address();
public Address DestAddress = new Address();
}A client which instantiates a message should only be able to access the address fields and to invoke SetAddress(). By declaring
SourceAddressandDestAddressobjects as public, I can write things likemessage.SourceAddress.FieldA,message.DestAddress.SetAddress(), with no need for additional code. However, I also expose other methods likeDoStuff()etc, which a message should not be able to call. On the other hand, if I declareSourceAddressandDestAddressas private, I can control what I expose to the client but I'm also forced to add a lot of code: public properties and methods likeSourceAddressFieldA,SourceAddressFieldB,SetSourceAddress(), all duplicated forDestAddress... this means a lot of code duplication, and less flexibility (imagine if I have to add otherAddressfields toMessage...). Is there a "sweet spot"? Is there a correct (or better, preferred) way to expose the behaviour of child objects in C#? Regards, AndreaI think the best way is to make Address use an interface which defines the methods you want the Message to have access to. Then do public IPublicAddress SourceAddress = new Address(); This means that the Message class can only access the methods you want it to.
Christian Graus Please read this if you don't understand the answer I've given you "also I don't think "TranslateOneToTwoBillion OneHundredAndFortySevenMillion FourHundredAndEightyThreeThousand SixHundredAndFortySeven()" is a very good choice for a function name" - SpacixOne ( offering help to someone who really needed it ) ( spaces added for the benefit of people running at < 1280x1024 )