Reading a few posts on the whole Properties vs. fields issue: Properties vs public fields redux..., Public fields and properties are not compatible and properties vs. fields... again (thanks for the links Jimmy) I realize that the way I look at it is not really addressed.
I like having the intent of my code play out in the interfaces. Some people dislike interfaces, some disgust them. I'll leave that uncommented. I feel that conveying my project's architecture and connections using interfaces is a good way to make visible the overall structure. To me fields are largely invisible and should not be public.
Is it good design to 'clutter' your code with a lot of interfaces? Hmmm... negative value word there. I think so! I like interfaces! If you look at only the interfaces you get a very clean view without any implementation details at all!
Also there is the issue of late binding and factories. Say you want to use the design to have a shared project of interface 'contracts' used by say a business layer and supplied by a data layer which do not know about each other. This case would take fields out of the picture completely. Or?
As you can clearly see I am not at all addressing the issues of binary compatibility, more vs. less lines of code or even performance. I am merely making an observation that code design was largely left out of the other posts on the issue.
I'd love to hear from you! Please Comment!
Cheers,
/Magnus
posted @ Thursday, March 22, 2007 8:09 PM