How to create new classes in separate files?

[Ralph]

So essentially if I want to have a "group of strategies" that share a common set of parameters. Then all I need to do is setup my base class which inherits the Strategy class. Then define all my properties. Then make my strategy, and change the StrategyName : Strategy in the file to "StrategyName : MyBaseClass" and then code from there. I will then see all my parameters from my common BaseStrategy.

So I am thinking that I setup a BaseClass for my parameters, and then use the other model for managing my classes that I want to centralize

Exactly, I like that. And think about, what your group of strategies share in common. Try to pull that all into the base class (variables, methods, not just properties). Having different opportunities to place code/variables can improve structure if handled wisely.

Regards
Ralph

[Ralph]

So I am thinking that I setup a BaseClass for my parameters, and then use the other model for managing my classes that I want to centralize.

What was the "other model"?

[r2kTrader]

What was the "other model"?

Well, essentially passing the strategy to my class. The idea was to centralize my code and then pass the strategy to the code during creating of the object from within the strategy. The only problem was that I didn't have a way to set the variables prior to the launching of the strategy. So I stopped that and focused on what I am working on with you now. Namely trying to centralize user defined parameters, but write once use many. The base class, which inherits from Strategy is the play. I just have to remember to change the (StrategyName : Strategy) to (StrategyName : MyBaseClass). That should take care of the parameters.

I have my pieces now. I just need to think it out.


public TestBase(Strategy s) : base(s)
{
this.s = s;


}

So I think I will do the following.

1. Setup my base class with my group of parameters that will serve my group of strategies.

2. Follow my model of passing the strategy to the class as per above. So in my base class, I will provide the code in the constructor that will receive the passed strategy via "this".

My only concern is that it is somewhat "cyclic" in nature. So I have to just re-think this. It would seem that setting up a base class to serve my parameters is sound, but passing the strategy to my class may be redundant/cyclic. I'm just burned out because what may be straight forward for most, is brain grueling for me right now. I'm trying to learn and implement and it's brutal.

I can't thank you enough Ralph for the direction you have provided.

[r2kTrader]

Exactly, I like that. And think about, what your group of strategies share in common. Try to pull that all into the base class (variables, methods, not just properties). Having different opportunities to place code/variables can improve structure if handled wisely.

Regards
Ralph

ooooh! good point. I'm going to setup the macDaddy base Class. Once you get the inheritance down, as well as how it relates to NT, then you can do some real damage.

I'm sorry, but NT should have a how to on this. It would seem anyone who is writing strategies would benefit. Maybe this thread will help others.

Thank you Ralph!

[r2kTrader]

Ralph,

TestPrint was just to have a method in there.

I was using base(s) because I was trying to setup a base class that handled the passing of the Strategy to my class and then just setup one constructor and then inherit that. But I can see it's getting ugly.

If you look closely, I think you will see my code was "outside" of Partial Class. (unless I am missing something).

As I think this through, I think I need to start over and spawn from a base class and go from there. Then examine the other concepts if I can't do what I need. As I learn more, I think a BaseClass that inherits from Strategy, with all my methods, parameters, variables, is the play. I think this was what I should have done from the beginning. Getting closer. Feeling the power

Here are some comments to your UserDefinedMethods implementation, r2kTrader.

I described it already, implement the test classes in a strategy template. Think about this: You put the code of your 2 strategies into Strategy (by partial class). That's ok in general, but: class TestBase inherits from Strategy and is part of Strategy. I can't imagine what that means when executing.

For the reason mentioned I would keep the TestBase constructor protected.

Remove ":base(s)" from this statement: public TestBase(Strategy s) : base(s)
You should not pass data to the Strategy-constructor. This NT-baseclass is out of your control.

Of course I don't know your intention to pass a Strategy-instance to TestStrat: public TestStrat(Strategy s) : base(s). But just for printing you don't need to do that, because TestStrat inherits the complete Strategy-public interface already from "TestBase:Strategy".

Hope that helps
Ralph

PS: Haven't read your previous post yet.

[Ralph]

Well, essentially passing the strategy to my class. The idea was to centralize my code and then pass the strategy to the code during creating of the object from within the strategy. The only problem was that I didn't have a way to set the variables prior to the launching of the strategy.

Hi r2kTrader,

I guess it is the same approach I applied with DataTransferTest in the other thread. There I passed 2 public properties (StrategyName, RegexPattern) when instantiating the class containing the custom code (DataTransferPL) during the construction in DataTransferTest.

Regards
Ralph

[r2kTrader]

Ralph,

How come my public properties show up when I go to start the strategy under the strategy tab (in the control panel), but they don't show up when I go to start the strategy from within a Chart?

Update:
It's a NT issue. Apparently you have to name the properties "Parameters" under description or the chart version of the strategy implentation doesn't show you the parameters. I know there is a thread out there about this, but I can't recall it.

Update II:
I found a thread about this issue.

http://www.ninjatrader-support2.com/vb/showthread.php?t=14958&highlight=parameters+chart+properties

and here:

http://www.ninjatrader-support2.com/vb/showthread.php?t=20297

Thanks,

[r2kTrader]

Ralph,

Shouldn't this be an "abstract" class then?

public abstract class MyBaseClass : Strategy
{
}

UPDATE I:
Also, I setup a default constructor to Instantiate my other classes. This way, when I inherit the BaseClass from MyStrategy, my objects are already instantiated with MyStrategy and then I can access the members of the class straight away.

So by setting the BaseClass as Abstract, and creating a default constructor to instantiate my other class objects, I can hit the ground running after inheriting the BaseClass.

I don't know if any of this is valid or ok, but it works.



Thanks,

Thats correct, the protected constructor prevents instantiation of the base class only (whoever tries it), nothing else. Another important point: Since the base class inherits from Strategy, NT considers it as a fully qualified strategy. You can see that, because it appears in the list of selectable strategies, if you comment the constructor. I am personally prefer to avoid that.

Whenever you implement code in the framework provided by UserDefinedMethods (partial class), your code becomes a part of the Strategy-class implementation (variables, methods,...). I provided you with a base class implementation which serves as a NT-strategy (with your sub-class implementations). This is a fundamental difference and it is important to understand the difference.

Hope it clarifies things
Ralph

[Ralph]

Could you provide me with a code example? Would feel better to see something before I give you an answer.

Regards
Ralph

[r2kTrader]

// Abstract Class ensures this base class can only be
// inherited and also prevents it from showing up under the
// strategy list from within a chart or strategy tab

publicabstractclass MyBase : Strategy
{

// no need to be public, probably better to be protected anyway.
// I just made it public for the purpose of verifying "abstract" over
// "protected"

public MyBase()
{

// Initialize in base class isn't hit, so I use the Default
// Constructor to "Initialize()" my settings for anything
// Which is going to be used across all strategies (which
// inherit this Base Class.
// this way I can have my base class setup 90% of what I need
// for a strategy, including the instantiating of certain
// objects, and settings like COBC, etc.
CalculateOnBarClose = false;



// Setup MySignal so I can access members from Strategy (that inherits
// this base class) without Instantiating first.
// So I can access signal.MyMethod() right out of the gate simply by
// inheriting the MyBase Class.
signal = new MySignal(this);


}

}

publicclass MySignal
{
Strategy s;

// Default constructor with no sig
public MySignal()
{}


public MySignal(Strategy S)
{ s = S;}

public MyPrintMethodTest()
{
Print(s.Close[0].ToString());
} // MyPrintMethod

} // MySignal Class



---------------------
Then from within my Strategy based on this base class.
---------------------

publicclass MyDerived : MyBase
{

protectedoverridevoid OnBarUpdate()
{
// no need to instantiate the Class as this is done automatically in the
// constructor of the base class.
signal.MyPrintMethodTest();

// I can also use base. to access a list of members via intellisense.
// which is convenient.


}

}

---UPDATE---
I could also just put base.Initialize(); within the Initialize() of the inheriting class I suppose. Same for OnBarUpdate(). base.OnBarUpdate(); inside of OnBarUpdate() of inheriting class.

I like my constructor model better because it doesn't require me to remember to put in either ;-)

[Ralph]

So yes, if it compiles (legal syntax), then it should behave the same like the protected constructor.
I am personally wouldn't use that because "abstract" is a concept to provide an interface class. Your intention is to use it rather as an intermediate layer than as an interface.
It's perhaps a discussion about coding style.

Regards
Ralph

[sefstrat]

No he is using it correctly. Abstract means the class must be inherited to be instantiated. Generally you use it to define a common foundation that other classes inherit from and implement more specifically.

Interface is also used to define a template but it cannot have any preset implementation associated with the interface, unlike an abstract class.

The primary reason you would want to use interfaces over abstract classes in some scenarios is that you can only inherit from one abstract class but you can implement many interfaces. (since c# does not support multiple inheritance)

So yes, if it compiles (legal syntax), then it should behave the same like the protected constructor.
I am personally wouldn't use that because "abstract" is a concept to provide an interface class. Your intention is to use it rather as an intermediate layer than as an interface.
It's perhaps a discussion about coding style.

Regards
Ralph

[r2kTrader]

Awesome,

I'm learning a lot. Thanks for the heads up Sefstrat.

It is interesting to see how different programmers use the power of C# differently. Like Accountants and bookkeeping ;-)

I am exploring interfaces in more depth, and from what I can tell, it's essentially a Class, but without methods. I see it as a variable template of sorts. I also understand the multiple Interface inheritance verses single inheritance with Classes (I look at it like Parallel inheritance and Serial inheritance to help me remember)

Lot's to learn. The more I learn, the more I realize that it's about having the right questions. Answers are just a matter of coding, it's what to code that seperates the adults from the children from what I can tell.


Regards,

No he is using it correctly. Abstract means the class must be inherited to be instantiated. Generally you use it to define a common foundation that other classes inherit from and implement more specifically.

Interface is also used to define a template but it cannot have any preset implementation associated with the interface, unlike an abstract class.

The primary reason you would want to use interfaces over abstract classes in some scenarios is that you can only inherit from one abstract class but you can implement many interfaces. (since c# does not support multiple inheritance)