Best practice for accessing Parent object data from child objects

Question

1.00/5 (2 votes)

See more:

I hope my question is worded correctly. Please correct me if I am wrong.

I have a Class object called "Device". It contains several properties and methods. It also contains several other classes called Service1, Service2, and Service3. These classes also have several properties and methods.

My question is, what is the best practice to access the properties in the Device class from inside one of the ServiceX classes.

Here is my example

C#

public class Device
{
    public string Name { get; set; }
    public string IPAddress { get; set; }
    public string Port { get; set; }
    public Service1 service1 = new Service1();
    public Service2 service1 = new Service2();
    public Service3 service1 = new Service3();

}

public class Service1
{
    public string Identifier { get; set; }
    public string controlUrl { get; set; }

    public void executethis(string command)
    {
        string URL = @"http://" + Device.IPAddress + ":" + Device.Port + this.controlUrl
    }
}

public class Service2
{
    public string Identifier { get; set; }
    public string controlUrl { get; set; }

    public void executethis(string command)
    {
        string URL = @"http://" + Device.IPAddress + ":" + Device.Port + this.controlUrl
    }
}

public class Service3
{
    public string Identifier { get; set; }
    public string controlUrl { get; set; }

    public void executethis(string command)
    {
        string URL = @"http://" + Device.IPAddress + ":" + Device.Port + this.controlUrl
    }
}

So, if I use this is my application,

C++

Device.Service2.executethis("VolumeUp");

This or course does not work at all.

I have over come this by sending the parent object with it, like this:

C#

public class Device
{
    public string Name { get; set; }
    public string IPAddress { get; set; }
    public string Port { get; set; }
    public Service1 service1 = new Service1();
    public Service2 service1 = new Service2();
    public Service3 service1 = new Service3();

}

public class Service1
{
    public string Identifier { get; set; }
    public string controlUrl { get; set; }

    public void executethis(Device parent,string command)
    {
        string URL = @"http://" + parent.IPAddress + ":" + parent.Port + this.controlUrl
    }
}

public class Service2
{
    public string Identifier { get; set; }
    public string controlUrl { get; set; }

    public void executethis(Device parent,string command)
    {
        string URL = @"http://" + parent.IPAddress + ":" + parent.Port + this.controlUrl
    }
}

public class Service3
{
    public string Identifier { get; set; }
    public string controlUrl { get; set; }

    public void executethis(Device parent, string command)
    {
        string URL = @"http://" + parent.IPAddress + ":" + parent.Port + this.controlUrl
    }
}

now I use this:

C++

Device.Service2.executethis(Device, "VolumeUp");

But I'm sure this is not the correct way.

Posted 27-May-15 12:30pm

HKHerron

Add a Solution

3 solutions

Solution 3

Best practice is YOU DON'T!

The child object should not care about it's parents data AT ALL. The scope the child object should be concerned with is it's own data and that's it. Nothing else.

Posted 27-May-15 13:13pm

Dave Kreskowiak

Comments

Sergey Alexandrovich Kryukov 27-May-15 23:16pm

Sorry my friend, really sorry. This is what I call dogmatism, and this is what I think is bad.
The access to the parent is the decision which may depend on a number of different factors. Basically, you have some graph, a tree or not, need to travel on it using different algorithms and on different purposes. Consider all these operations, performance and memory costs, and then decide what to reference from what and what not.
I cannot believe I down-vote you answer; probably it happened for the fist time. Hope you can understand my frustration. Really sorry.
—SA

Dave Kreskowiak 27-May-15 23:43pm

I understand. I was taught the a child never should know anything concrete about it's parent. Sure, it can have a reference to it, for example, linked lists or trees, but the child should never give a crap about it's parents data.

I've been writing code with that in mind for quite a long time and have never violated the 'rule'. :)

Sergey Alexandrovich Kryukov 28-May-15 0:43am

What you have been taught does not have to be true in all cases.

Just few examples (which of course don't prove anything, just illustrations). 1) Whole relational model is based on the idea that only the child knows about parent, and parent does not know about children, just because a table has fixed number of columns; there is the attribute "parent"; and this is how integral picture is assembled; 2) System.Windows.Forms.Control.Parent.
How come they violated the "rule"? This is false rule, I tell you. Sorry.

But maybe three of us did not simply understand each other. The reference to the parent is the way "the child objects cares about parent's data". If you did not mind this reference, you simply expressed yourself in a misleading way. Do you think that anyone has such a crazy idea that the parent has, say, property "A", and all the children may have copies of the attribute "A", which are yet to be synchronized, and so on. I could not imagine that anyone in sober mind could ever come to such idea. This would be the most idiotic way of violating Single-Point-Of-Truth (SPOT) principle, which is of course purely rational and not dogmatic at at all, should not be violated (don't mix it up with redundancy which can be very useful).

This is not so simple. Let's again look at the relational model. What is "parent" in the children table? It is represented by the foreign key pointing to one or another parent. But in the parents table, this corresponds to some attribute, such as "id". So, in this sense, this attribute as a foreign key is "copied" in the children. But this is logically equivalent to a reference: a child has a reference to the parent. And not visa versa.

—SA

Dave Kreskowiak 28-May-15 12:19pm

Well, it looks like I lied a little bit. I did use the pattern when I wrote 'Runtime movable controls'. The control needs the parent container for some stuff. :) Opps.

Really, under OOP, should a child know anything about the data structures of its parent? I'm not saying it isn't useful at times. I'm just asking if it is really "best practice" for a child to care? I'm my humble opinion, no.

Sergey Alexandrovich Kryukov 28-May-15 12:38pm

It is a good practice (through references, of course), in some cases, and never having references to parents is a good practice for other cases. It all depends, first of all, on required set of operations, the ways you have to navigate.

And having those references is by far more typical than not having them. I would say, overwhelmingly more typical. I already gave you two examples. Here are two more:
XML DOM, XMLNode: https://msdn.microsoft.com/en-us/library/system.xml.xmlnode.parentnode%28v=vs.110%29.aspx
JavaScript DOM interface: https://developer.mozilla.org/en-US/docs/Web/API/Node/parentElement.

And those 4 (yes, 4 now) examples of tree representations are themselves some of the most used objects in programming. Again, it does not prove anything, but is very illustrative.

—SA

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2015-05-27T12:47:00

Solution 1

First of all, all our consideration only applicable to the trees of objects, not to arbitrary object graphs.

I don't see a specific problem. If you navigate from children up to the parent more or less frequently, the "best practice" would be having Parent references in all nodes of the tree, without exclusion.

One big potential problem is polymorphism, and hence the question: what type should be the type of Parent? It is possible that some child node can be composed in two or more difference parent types. Breaking OOP with dynamic cast (down-casting) is a kind of nasty thing. But in your case, you have only one Device type. So, there is really nothing to discuss here.

—SA

Posted 27-May-15 12:47pm

Sergey Alexandrovich Kryukov

Comments

Sascha Lefèvre 27-May-15 19:10pm

+5. I expanded on your second paragraph a bit.
/Sascha

Sergey Alexandrovich Kryukov 27-May-15 23:12pm

Thank you, Sascha.
—SA

HKHerron 28-May-15 8:54am

Thank you Sergey Alexandrovich Kryukov for your explanation and response. +5
I am selecting Solution 2 as the accepted answer as it expands on your thoughts, while providing the best explanations, alternatives and options.

Sergey Alexandrovich Kryukov 28-May-15 9:59am

You are very welcome. By the way, you don't have to "select" a solution to accept; you can accept any subset of solutions, accept any number of them; you decide, of course.
Good luck, call again.
—SA

Sascha Lefèvre · Accepted Answer · 2015-05-27T13:05:00

In addition to solution 1:

You could:

1) Introduce a field "Parent" in your Service-classes; of type Device (or, bearing Sergey's comment on polymorphism in mind, maybe rather an interface that Device implements).

2) Don't initialize the fields for the Service-instances in Device in the class-body but instead in the constructor.

3) Introduce an argument to the constructors of the service-classes; of type Device (or that interface) and provide it in form of the this-keyword in the constructor of Device when initializing the fields for the Service-instances.

If you can't follow me here, please ask.

Unrelated suggestions:
- Avoid public setters (for properties), here: Name, IPAddress, Port. Make them protected or private.
- Change the fields for the Service-instances in Device to properties (again, with non-public setters).
- Use C# naming rules: PascalCasing (starting with a capital) for all class members: Fields, Properties, Methods. camelCasing only for local identifiers.

edit: Picking up on Dave's answer, I think it could make sense to change your design a bit. Because this:

C#

Device.Service2.executethis("VolumeUp");

..looks a bit fishy. Essentially it's the Service here that you're using, not the Device. And the Service is using the Device. But why is the Service then a member of Device? If you flipped this around, making Device a member of Service, it would look like this:

C#

Device device1 = new Device(name, ipaddress, port);
Service2 service2 = new Service2(device1);
service2.executethis("VolumeUp");

..and you wouldn't have to access a parent's members from its child objects.