Skip to main content
Software Engineering

Return to Answer

added 623 characters in body
Source Link
Ixrec
Ixrec
  • 27.7k
  • 15
  • 84
  • 87

Making "wrapper properties" like this is fine if it's the cleanest way to implement the API that you want this class to have.

However, the specific example you posted does look questionable to me, mostly because the user of your class can now do exactly the same thing in two different ways: myAmyPage.bMainParagraph.Text and myAmyPage.TextMainText. Since the user doesn't (and shouldn't) know that one simply wraps the other, this raises all sorts of questions he shouldn't have to ask. Yes, documentation can help, but in my opinion the confusion and complication added by this duplicate outweighs the convenience of not having to type those extra two characters.

What you probably want to do is completely hide the BTextBlock object, and provide wrappers for only those properties that you want the APage user to have access to. Then if you later decide BTextBlock is not the best implementation of APage, it's much easier to change things. Alternatively, you can leave the BTextBlock completely exposed with no wrappers, if you think that telling the user "this is how you get the BTextBlock object that APage uses" is a better choice for your API.

Edit: Now that you've updated the question, and I can see that your Page class contains two TextBlock objects, I would lean very strongly towards making the two TextBlocks public and having no wrappers. Any attempt to wrap them immediately leads to potential confusion with disambiguating the MainParagraph wrapper from the Footer wrapper from the Header wrapper you'll probably add in version 3.0 from any of the actual TextBlock properties they're all implemented with. It's so much simpler to just expose both and let the TextBlock API do its job.

Making "wrapper properties" like this is fine if it's the cleanest way to implement the API that you want this class to have.

However, the specific example you posted does look questionable to me, mostly because the user of your class can now do exactly the same thing in two different ways: myA.b.Text and myA.Text. Since the user doesn't (and shouldn't) know that one simply wraps the other, this raises all sorts of questions he shouldn't have to ask. Yes, documentation can help, but in my opinion the confusion and complication added by this duplicate outweighs the convenience of not having to type those extra two characters.

What you probably want to do is completely hide the B object, and provide wrappers for only those properties that you want the A user to have access to. Then if you later decide B is not the best implementation of A, it's much easier to change things. Alternatively, you can leave the B completely exposed with no wrappers, if you think that telling the user "this is how you get the B object that A uses" is a better choice for your API.

Making "wrapper properties" like this is fine if it's the cleanest way to implement the API that you want this class to have.

However, the specific example you posted does look questionable to me, mostly because the user of your class can now do exactly the same thing in two different ways: myPage.MainParagraph.Text and myPage.MainText. Since the user doesn't (and shouldn't) know that one simply wraps the other, this raises all sorts of questions he shouldn't have to ask. Yes, documentation can help, but in my opinion the confusion and complication added by this duplicate outweighs the convenience of not having to type those extra two characters.

What you probably want to do is completely hide the TextBlock object, and provide wrappers for only those properties that you want the Page user to have access to. Then if you later decide TextBlock is not the best implementation of Page, it's much easier to change things. Alternatively, you can leave the TextBlock completely exposed with no wrappers, if you think that telling the user "this is how you get the TextBlock object that Page uses" is a better choice for your API.

Edit: Now that you've updated the question, and I can see that your Page class contains two TextBlock objects, I would lean very strongly towards making the two TextBlocks public and having no wrappers. Any attempt to wrap them immediately leads to potential confusion with disambiguating the MainParagraph wrapper from the Footer wrapper from the Header wrapper you'll probably add in version 3.0 from any of the actual TextBlock properties they're all implemented with. It's so much simpler to just expose both and let the TextBlock API do its job.

Source Link
Ixrec
Ixrec
  • 27.7k
  • 15
  • 84
  • 87

Making "wrapper properties" like this is fine if it's the cleanest way to implement the API that you want this class to have.

However, the specific example you posted does look questionable to me, mostly because the user of your class can now do exactly the same thing in two different ways: myA.b.Text and myA.Text. Since the user doesn't (and shouldn't) know that one simply wraps the other, this raises all sorts of questions he shouldn't have to ask. Yes, documentation can help, but in my opinion the confusion and complication added by this duplicate outweighs the convenience of not having to type those extra two characters.

What you probably want to do is completely hide the B object, and provide wrappers for only those properties that you want the A user to have access to. Then if you later decide B is not the best implementation of A, it's much easier to change things. Alternatively, you can leave the B completely exposed with no wrappers, if you think that telling the user "this is how you get the B object that A uses" is a better choice for your API.