An example I've seen of "modifying" the access of a property is in a class where theres no setter.
I've seen fake classes in a unit test where the fake makes the setter public so that it can be set in the unit test. On Wed, Aug 4, 2010 at 5:03 PM, Winston Pang <[email protected]> wrote: > Well I don't think they would want to expose it as public if it adds no > complete value to the whole picture, it may very well be marked as protected > so that child classes have a set of "helper" methods so to speak, for them > to extend the parent to more interesting levels. That's about the most > logical reason I have in regards to marking it as protected. > > Rehashing on other people's replies, reducing functionality is a major > violation to the principal, I mean in essence it's really to help you avoid > doing dumb things. > > On Wed, Aug 4, 2010 at 2:55 PM, Arjang Assadi <[email protected]> > wrote: >> >> On 4 August 2010 13:32, David Richards <[email protected]> >> wrote: >> > Wouldn't increasing access technically just be adding a member to the >> > subclass? A member that, publicly anyway, the superclass didn't have. >> Yes, but I have seen cases where a member is declared protected and to >> access that >> a new subtype is derived with the only intention of declaring that >> protected member public! >> >> Now if that member was meant to be protected for internal use, why >> widen it's access in the decendent class? >> wouldn't it make more sense to have it public to begin with? I come >> across this somewhere as a trick being used to access a protected >> member of a class ( first time I saw this in Delphi 17 or so years ago >> ) now it has it's surfaced ugly head in C#. >> >> > What happens internally is pretty irrelevant. >> Internally yes, but from design point of view, when we compare the >> Parent and inherited class, we find the members that for some unknown >> reason at one level are meant to be protected and next shzaam! they >> are public. >> I am not concerned with security at all, just the design paradigm >> seems to be inconsistent. >> >> Of course one can argue that what if we don't have access to the >> original class and the idiot who designed it should have made it >> public. In that case increasing the access seems like the poor man's >> patch, rather than fixing the problem at it's source (pun intended). >> >> Regards >> >> Arjang >> >> >> >> > >> > In my book, decreasing is always bad. I've seen it happen in some >> > Microsoft classes. It was really annoying. I can't imagine when this >> > would be a good idea. >> >> Never, as Michael pointed out it breaks polymorphisim. > >
