tags:

views:

45

answers:

3

In the code below the "Move" public class derives fromthe generic type "Submit". "Submit" is a method, part of the DSS model, which handles messages and accepts two parameters, one is the message body and one is the message response.

My question is: How or WHY does a class derive from a method?!

It seems to me (since i'm only a beginner) "generic types" mean just this... any method or class (and by extension, any "block" of code) can become a type. Moreover there are NO types... everything is just a "class" which you can derive from (yet you probably can't overload string)

This basicly means that there are in fact NO methods OR types, but rather just classes (and some "sub"classes (ex-methods)) and you can derive from everything?!

Thank you. I'm not looking for the expert "except this" answear where some small thing is not possible. I would like confirmation that this is, in fact, what 90% of the time, programmers are doing.

  public class Move : Submit<MoveRequest, PortSet<DefaultSubmitResponseType, Fault>>
  {
    public Move()
    {
    }

    public Move(MoveRequest body) : base(body)
    {
    }

  }
+5  A: 

You can not derive from a method. Submit<T, V, E> must be a class.

Alex Reitbort
+1  A: 

No, Submit is definitely not a method. A Class can only derive from another class, or implement an interface. So, Submit has to be either a class or an interface.

Guffa
+1  A: 

in a little more detail, Submit may be an "action" and therefore commonly thought of as a method, but in your context, Submit is indeed a class. This may be an example of the "Command" design pattern, in which a request for an action is encapsulated in an object and thus can be passed around and acted on by classes that handle the command.

Generics, conceptually speaking, are classes that are able to provide similar functionality among a set of "inner" types. The basic example is a Math class that can add, subtract, multiply and divide two variables of numeric type; you know, very advanced math you can't do any other way. There are a lot of numeric types in most type systems (in C# you have byte, short, int, long, float, double, and decimal, plus unsigned variations). Rather than implement a MathByte, MathInt, MathLong, etc with methods strongly defining the type they work on, or implementing a Math class that works with any Object (and thus requires you to examine the type of everything passed in to determine that you can work with the type), you can simply create a Math<T> class, where T can be any of the numeric types.

The type parameter T is different from method parameters; when you declare an instance of the class, you specify a type that the instance will be set up to handle. That instance can then only work with objects of the specified type, but you can instantiate a Math<byte> and a Math<decimal> to work with different types. Methods defined in Math specify input parameters of type T, and T is "replaced" at instantiation with the type declared when you instantiate the class.

Generics help support the DRY ("Don't Repeat Yourself") tenet of good coding practice, while maintaining type integrity. MathLong, MathInt, MathByte etc would all be similar or identical in their internal code; the main difference would be the type of the object they work on. Instead of rewriting the same class 10 times, you write one class that can be more concretely defined as to its working type by consumers of your class.

Hope this is a little more educational.

KeithS