Is there a way to implicitly reference an object in a has-a relationship without explicitly using the object name?

Question

I want to use a contained object "implicitly", as an alias, like if it were "this" relationship. Does C# support anything like this or what design pattern might come closest to the intent expressed? The alternative I am looking at is to define a delegate and implement it in the MyHasA class.

Pseudo example A

 public class MyClass
    {
    public MyHasA hasA;

    public void MyMethod()
    {
      implicit(hasA)->
     {
       Print("Hello World"); // vs hasA.Print("Hello World") 

     }
    }
  }

Pseudo example B

 public class MyClass
    {
    public MyHasA hasA;
    using implicit hasA;
    public void MyMethod()
    {
       Print("Hello World"); // vs hasA.Print("Hello World")          
     }
    }
  }

I'm not aware of any such mechanism. But why are you trying to do this? What's the problem you're hoping to solve? — David, May 21 '19 at 11:44
This is smelling a bit like an [XY Problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). Can you explain what you're *actually* trying to achieve (rather than how you're trying to achieve it), there might be a different way. — Jamiec, May 21 '19 at 11:44
Actually, this looks like an anti-pattern to me. That would make code really really confusing. — Fildor, May 21 '19 at 11:45
This isn't a pattern. What you posted delegates calls to an implementation object. This technique can be used to *implement* behavioral patterns like the State pattern. What problem are you trying to solve with this? It's quite likely there are other ways to do it — Panagiotis Kanavos, May 21 '19 at 11:46
Or do you mean something like this: https://stackoverflow.com/q/7692826/982149? (static import) — Fildor, May 21 '19 at 11:46
The problem attempted to solve is that I am trying to create a "pattern" of containment within a parent class where the inner class needs to access all of the functionality of the parent class. Deriving from same type does not achieved desired functionality because parent object has object state set outside my context. The other solution I'm looking at, as such, is to define delegate and implement it in the parent class. — Curtis White, May 21 '19 at 11:49
@CurtisWhite cant you pass a reference to the parent into the child? As a nested class it has access even to private members of the parent. — Jamiec, May 21 '19 at 11:50
@CurtisWhite C# has inner classes and they do have access to the functionality of the outer class. I doubt that's what you want though. You still haven't explained what you want to do, only how you think it can be done. Why not use the common way to implement eg State with interfaces and/or generic types? — Panagiotis Kanavos, May 21 '19 at 11:50
@CurtisWhite local methods have access to the surrounding scope too. They can be used to curry other function and provide access to the parent's environment. — Panagiotis Kanavos, May 21 '19 at 11:54
@Jamiec Thank you for the suggestion. However, in my case it is more natural to reference the methods without an instance reference. I am using NinjaScript (C#) and have references like Close[0]. Technically, yes I can do baseStrategy.Close[0] but I'd rather use the syntactical form Close[0]. — Curtis White, May 21 '19 at 12:05
This sounds like a nearly identical problem. The recommended solution was partial classes. Thinking about whether or not this makes sense. https://ninjatrader.com/support/forum/forum/ninjatrader-8/strategy-development/102514-strategy-inheritance-in-nt8 — Curtis White, May 21 '19 at 12:39
When we talk about "referencing" something, it helps to think of it from the POV of the client. Does the client gain anything from this? Probably not. The client just needs to know the interface (public members) on which it depends. Instead of defining anything unusual, step back and think of a) what interface does a client need, and b) how do I adapt the class I have to that interface? Looking at everything from the client's POV helps us to focus on *why* we're building something and leads us away from peculiar ways to build classes. — Scott Hannen, May 21 '19 at 13:10

Curtis White · Answer 1 · 2019-05-26T08:41:13.120

0

This problem is related to scoping of has-a relationship variables. The typical solution would be to derive from a base class and use implicit this reference. This problem occurs when one cannot derive from a base class because of inaccessible instantiating logic or has large amounts of code that they do not want to have to syntactically change, i.e. form of "myObject.DoSomething" vs "DoSomething".

The recommended solution found were inner classes and partial classes. Partial classes allow creating a logical containment. The final solution involved creating a partial class with a delegate/eventhandler in the outer class and initializing it in the inner class to a method in the outer class. The combination of partial class and delegate provides for a layer of logical containment while still retaining most of the benefits of object oriented design.

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/partial-method https://ninjatrader.com/support/forum/forum/ninjatrader-8/strategy-development/102514-strategy-inheritance-in-nt8

edited May 26 '19 at 08:41

answered May 21 '19 at 13:30

Curtis White

6,213
12
59
83

It looks like you might have found your answer, which is good, but it's not clear at all how this relates to the question or what problem it solves. That means it's going to be difficult for anyone to tell if your answer fits well or whether a different approach would help. That includes future users who see the question and answer. – Scott Hannen May 21 '19 at 14:36
@ScottHannen I guess it is about scope * code re-use. The original question was basically let's say you want to scope syntactically to "is-a" relationship when you cannot derive from it. It is just a syntactics. But the problem the structures I inquired about would solve is that you could move large blocks of code from "is-a" to "has-a" relationship without having to use a syntactic reference. Closest thing is LINQ. The solution as presented is to split up the "is-a" class into logical file units "partial class". I went with combination of inner and partial classes. – Curtis White May 21 '19 at 21:34
Perhaps a code sample would help, along with an example of how it makes something better. – Scott Hannen May 21 '19 at 22:04
@ScottHannen Let's say you have a lot of code-- and if move it to "has-a" relationship then you have to add the syntactical prefix object reference. It would be nice if we could scope to the "this" reference to avoid typing. There is a way around this I thought of. You have to clone the base class, the one that cannot be derived from or doesnt work, into a proxy with identical methods and then in the proxy, you reference the object. – Curtis White May 24 '19 at 15:22

Is there a way to implicitly reference an object in a has-a relationship without explicitly using the object name?

1 Answers1