Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

re: Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

Patrick — Tue, 19 Oct 2010 15:48:00 GMT

I see potential threat of abusing this cross sibling calls to protected methods of the base class, but there's also similar risk of malicious calls from malicious classes that derive from one of the siblings. I mention calls to methods but it also covers accessing other things like properties.

Here's my example - some software development company structure. Where only people of development background are allowed to give work to developers. Others have to go to the manager to get it vetted.

public class Employee {}

public class Developer : Employee()

{

protected void virtual Develop(Requirements data) { // develop }

}

public class CSharpDeveloper : Developer

{

protected void DoSomeCSharpStuff() {}

override void Develop(Requirements data) {

// implement all code changes, remove from 'data' and delegate rest to other devs }

}

public class DbDeveloper : Developer

{

protected void DoSomeDbStuff() {}

override void Develop(Requirements data) {

// implement all db changes, remove from 'data' and delegate rest to other devs }

}

public class DevelopmentManager : Developer, IAmManager

{

DbDeveloper [] dbDevs;

CSharpDeveloper[] cDevs;

override void Develop(Requirements data) { // are you kidding me?! find relevant developer and delegate work }

IAmManager.RequestWork(Requirements data) { // assess whether relevant to the devs and allocate or bin it }

}

public class Tester : Employee {}

So if sibling calls were allowed then DevelopmentManager would be able to call Develop() on devs in his Team. Developers would be protected from any calls from Testers, they will have to go through proper channels :-)

Now someone could derive malicious class from Developer class and send malicious calls to Develop() method, which relies on access modifier and doesn't validate input as much.

But preventing cross sibling calls doesn't stop malicious class deriving from CSharpDeveloper class and also invoking calls.

'Internal protected' access modifier doesn't solve the problem because it would limit this model to 1 assembly.

re: Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

Patrick — Tue, 19 Oct 2010 15:47:06 GMT

Here's my example - some software development company structure. Where only people of development background are allowed to give work to developers. Others have to go to the manager to get it vetted.

public class Employee {}

public class Developer : Employee()

{

protected void virtual Develop(Requirements data) { // develop }

}

public class CSharpDeveloper : Developer

{

protected void DoSomeCSharpStuff() {}

override void Develop(Requirements data) {

// implement all code changes, remove from 'data' and delegate rest to other devs }

}

public class DbDeveloper : Developer

{

protected void DoSomeDbStuff() {}

override void Develop(Requirements data) {

// implement all db changes, remove from 'data' and delegate rest to other devs }

}

public class DevelopmentManager : Developer, IAmManager

{

DbDeveloper [] dbDevs;

CSharpDeveloper[] cDevs;

override void Develop(Requirements data) { // are you kidding me?! find relevant developer and delegate work }

IAmManager.RequestWork(Requirements data) { // assess whether relevant to the devs and allocate or bin it }

}

public class Tester : Employee {}

Now someone could derive malicious class from Developer class and send malicious calls to Develop() method, which relies on access modifier and doesn't validate input as much.

But preventing cross sibling calls doesn't stop malicious class deriving from CSharpDeveloper class and also invoking calls.

'Internal protected' access modifier doesn't solve the problem because it would limit this model to 1 assembly.

re: Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

Tom — Fri, 07 Aug 2009 19:50:00 GMT

I would take the easy route and give each item a Bulk property and each container a MaxCapacity property to serve as a validation tool for determining which items fit inside which containers. Since containers are items, they too follow this "bulk" policy — as such, a room won't fit inside a sack, but it could fit inside a house or a forest, if you were so inclined to use that level of abstraction. (It also has the lovely side effect of providing an indicator for when a container is "full.")

You might also consider a component design approach, wherein items have components, and components (rather than the class hierarchy) define the item's functionality. But I won't go into that. If you're interested, here's a good link to get you started: http://www.enchantedage.com/node/45. The title says XNA, but the concept is very general.

re: Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

Alexey — Sun, 28 Dec 2008 16:02:58 GMT

I wonder if this problem (maintaining bilateral references) can be solved the way you described if you add a third type: containers that aren't items. For example, a room can contain a box and a torch, a box can contain a sack and a a map, but nothing can can contain a room.

Without multiple inheritance you have to extract the IContainer and IContainable interfaces and implement them in the abstract Item, Container and ContainerItem classes. Okay, you can put the Container class declaration into the Item class declaration, but what if Container is involved in another bilateral relationship?

Can you user partial class declarations to grant access to specific internal members to a specific type?

Protected Member Access, Part Four

Fabulous Adventures In Coding — Fri, 02 May 2008 19:13:51 GMT

In Part Two I asked a couple of follow-up questions, the first of which was: Suppose you were a hostile

Why Can't I Access A Protected Member From A Derived Class, Part Three

Fabulous Adventures In Coding — Thu, 24 Apr 2008 19:46:49 GMT

Holy goodness, I've been busy. The MVP Summit was fabulous for us; thanks to all who attended and gave

re: Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

Weeble — Tue, 22 Apr 2008 19:35:59 GMT

For the immutable question, how about introducing some sort of "view" classes? Items don't actually store upward links to their containers, but a container can create "views" of its children, which are immutable wrappers around the items that also have an upward link back to (a view of?) the container. Of course, it could get nasty making all the view classes.

For that matter, what should be the return value of an immutable container's add or remove method? Suppose we have a bag inside a box, and we do "bag.Add(torch);", what's the return value? Do we get a bag containing a torch? Do we get a bag that's inside a box, and which contains a torch? Do we get a box containing a bag containing a torch? Are we even allowed to do this?

How do we call the remove method? If we're copying the hierarchy in order to make new versions, can we sensibly use a reference to identify the item we want to remove, or do we need to give our objects value semantics?

re: Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

DRBlaise — Thu, 17 Apr 2008 00:16:27 GMT

I noticed no one really addressed Eric's 2nd question about how to "make this hierarchy an immutable collection" I could not really think of any good way to make the hierarchy immutable and have items know their parents without having to rebuild the entire hierarchy every time something changes.

The only thing I could come up with to represent this type of immutible hierarchy was to have the container hold its child items in a binary tree structure.

re: Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

Duarte Cunha Leão — Tue, 15 Apr 2008 20:51:19 GMT

I think that what I show next could be an

elegant solution to the "friend class" design problem:

namespace TwoMutuallyKnownClasses

{

public abstract class Item

//: BaseClass, BaseInterface

friends Bag

//where T : SomeType

{

private Item _parent;

public Item Parent

{

get { return _parent; }

}

// This method is accessible from derived classes (protected) and from friend classes (friends)

protected friends void SetParent(Item parent)

{

_parent = parent;

}

public abstract class Bag : Item

{

private List<Item> _list = new List<Item>();

public void Add(Item item)

{

item.SetParent(this); // Not an error in C# 4.0

_list.Add(item);

}

Something like this captures the special relationship

between these two classes.

The trust relationship that is expressed

does not pervase to the containing assembly's types,

by lack of expressiveness of the language.

That would be the case if the «internal» keyword had to be used,

in this place, to express the same real relationship.

The number of types in an assembly can easily get very large,

and it may not be feasible to assume that they all

share the same level of trust, as the «internal» keyword obliges.

Also it is common that several different people contribute to a given assembly,

possibly at different points in time,

with decreasing knowledge of the original author's intentions.

Personally, I think code accessibility and intent expressiveness

should not (need to) depend on assembly boundaries.

Just like the «internal» keyword denotes all types of an assembly,

the «friends» keyword would denote the set of types considered friends

by a given class.

Notice that the proposed expressiveness is somehow inverse

of that of the C++ language,

where a class «Item» says:

"Method Bag.Add has access to me"

or if Item trusts all of Bags methods:

"Class Bag has access to me".

Instead, in a CIL language (http://en.wikipedia.org/wiki/Common_Intermediate_Language)

we would say:

"My method SetParent may be accessed by (any method of) any of my friend classes"

and that:

"Class Bag is my friend"

Would this be a good approach?

Would it bring any problems with it?

re: Why Can't I Access A Protected Member From A Derived Class, Part Two: Why Can I?

Eamon Nerbonne — Mon, 14 Apr 2008 23:32:22 GMT

The option using "internal" looks reasonable to me - notice that both the "mananger" who consumes and generates must be aware of the classes it manages and that the "black-box" classes must be aware of the manager; that means you're very unlikely to be able to put the manager and the blackbox in separate assemblies anyhow due to circular dependancies. Therefore, putting both in a single "trusted" assembly seems reasonable. Of course, technically, the manager class might provide its encapsulation services to any sort of class (and thus breaking the circular dependancy), but I can't really imagine such a situation in practice...

The following would be an alternative (but it's not pretty...)

public class ManageP

{

private object key=new object();

private static Func<P> trustedMaker;

public static void SetPMaker(P proof, Func<P> suggestedMaker) {

if (proof != null && trustedMaker == null) trustedMaker = suggestedMaker;

}

static ManageP() { P.Initialize(); }

static void Main(string[] args) {

foreach (var i in Enumerable.Range(0,10)) Console.WriteLine(trustedMaker());

}

public sealed class P

{

static int count=0;

private P() { count++; }

public override string ToString() {return "#" + count;}

public static void Initialize() { ManageP.SetPMaker(new P(), () => new P()); }

}