Retlang usage

[Chrisa23]

I have been structuring most of my projects around a Messaging library
for the particular project, where I define the immutable messages in
my API and one or more classes containing channels that represent the
system API. I am mostly focused on automated trading.

ie...
Project.Messaging
- Channels
- System Channels
- Messages
- Message1
- Message2

For my messages, I am using public readonly fields as opposed to auto
properties with private setters.

I have gone back and forth exploring using interfaces and abstract
classes for component abstractions. For the most part, since Retlang
components should normally not have public methods, interfaces become
clunky unless you want to implement publishing to channels underneath
your public interface. I have mostly settled on abstract classes
since in that case I can define a contract for constructor injection
which is how I provide channels to components. (this is mostly
oriented to how I abstract a "strategy")

Here's a quick pseudo example (the context contains the input/output
channels):

public abstract class Strategy
{
protected Strategy(IFiber fiber, StrategyContext context)
{
...
}
}

I am not completely settled on what I feel is best and am open to any
feedback.

[Graham Nash]

It looks like pretty standard usage.  

However, independent of the usage of Retlang, I wouldn't use inheritance in this case as it appears the child class would never be used via a parent reference.  It appears it is just being used as a marker for which inheritance is a bit heavy.

--
You received this message because you are subscribed to the Google Groups "retlang-dev" group.
To post to this group, send email to retla...@googlegroups.com.
To unsubscribe from this group, send email to retlang-dev...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/retlang-dev?hl=en.

[Chrisa23]

I am actually only referencing strategies as the base Strategy class
in my code. I have some factory methods that take a strategy
definition, instantiate it through reflection and return it as
Strategy. My system only knows about the base class Strategy and
never the details of whichever real strategy object is instantiated.
While the Strategy classes do not have public methods, they do have
control channels to allow interaction.

I think that is kind of what you are referring to. Does that seem to
make more sense given that explanation?

[Graham Nash]

If the Strategy child classes have no public methods, then there is no reason for them to be Strategies as they are not extending the behavior of the base class and therefore there is no test for the Liskov Substitution Principle.  

It appears, as I referenced previously, inheritance is being used for marking (so they can be found via reflection).  Attributes would be more appropriate.

[Chrisa23]

Thank you. That makes a lot of sense. Wasn't sure what you meant by
marking, but now I am clear.

I definitely felt awkward in my use of inheritance in this situation,
and normally for reflectively loaded code, I use attributes. In this
case, my desire was to enforce a contract on the constructor more than
marking for loading. I didn't feel I fully violated the Liskov
principle, but I also didn't think in terms of whether there is a test
for it. I knew this wasn't ideal, but I am not aware of any other way
to enforce a contract on the constructor. I'm also not sure how
valuable this is.

On Oct 21, 2:07 pm, Graham Nash <graham.m.n...@gmail.com> wrote:
> If the Strategy child classes have no public methods, then there is no
> reason for them to be Strategies as they are not extending the behavior of
> the base class and therefore there is no test for the Liskov Substitution
> Principle.
>
> It appears, as I referenced previously, inheritance is being used for
> marking (so they can be found via reflection).  Attributes would be more
> appropriate.
>

> On Thu, Oct 21, 2010 at 1:56 PM, Chrisa23 <chris...@gmail.com> wrote:
> > I am actually only referencing strategies as the base Strategy class
> > in my code.  I have some factory methods that take a strategy
> > definition, instantiate it through reflection and return it as
> > Strategy.  My system only knows about the base class Strategy and
> > never the details of whichever real strategy object is instantiated.
> > While the Strategy classes do not have public methods, they do have
> > control channels to allow interaction.
>
> > I think that is kind of what you are referring to.  Does that seem to
> > make more sense given that explanation?
>
> > On Oct 21, 10:08 am, Graham Nash <graham.m.n...@gmail.com> wrote:
> > > It looks like pretty standard usage.
>
> > > However, independent of the usage of Retlang, I wouldn't use inheritance
> > in
> > > this case as it appears the child class would never be used via a parent
> > > reference.  It appears it is just being used as a marker for which
> > > inheritance is a bit heavy.
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "retlang-dev" group.
> > To post to this group, send email to retla...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > retlang-dev...@googlegroups.com<retlang-dev%2Bunsu...@googlegroups.com>
> > .