MVP's: static methods in interfaces.

[Picho]

Hi all,

I popped up this question a while ago, and I thought it was worth checking
again now... (maybe something has changed or something will change).

I read this book about component oriented design (owreilly - Juval Lowy),
and it was actually very nice.
The book goes on about how we should use Interfaces exposure instead of
classes (this is my terminology and english is not my language so I hope you
understand what I'm on about...).

however...

I want to give my classes the ability to staticly create instances, simply
because I think that calling a 'MyClass.FromSomething(Something something)'
is more intuative than a constructor 'public MyClass(Something something)'

this is just me...

anyway, as far as I know interfaces cannot define static members. this
pushed me into something I even like less - a class factory (even though it
is in some scenarios a good practice).

MVP's...

1. Is there a more... 'elegant' way for me to achieve this?
2. is this somehing we want from C# (static member decleration in
interfaces)?
3. am I just being picky (should I just use constructors and forget my
intuition?)
4. am I totaly wrong?
5. all the above

Thanx,
Picho

hang on... can we even define constructors in interfaces today?...
god I even confused myself...

 

[Helge Jensen]

I want to give my classes the ability to staticly create instances, simply
because I think that calling a 'MyClass.FromSomething(Something something)'
is more intuative than a constructor 'public MyClass(Something something)'

For classes, you can just do that:

public class MyClass {
protected MyClass(...) {...}
public FromSomething(...) { return new MyClass(...); }
}

So, actually your problem doesn't arise from trying to redefine
contruction. It arises from trying to do (what is often called) virtual
construction.

this is just me...

Beware, that other people might not agree. Sometimes it's just easier to
accept the common idioms, with the problems they offer, than to teach
all you work together with a new one (and sometimes, the new one has
it's own problems

anyway, as far as I know interfaces cannot define static members. this
pushed me into something I even like less - a class factory (even though it
is in some scenarios a good practice).

All polymorphic behaviour is on instances in C#, and you are asking for
virtual construction (which uses polymorphism). So, you need an
instance, commonly called a factory.

1. Is there a more... 'elegant' way for me to achieve this?

Not really, especially don't fall into the pit of "prototyped
contruction" if you don't actually *need* cloning.

You can do virtual construction using delegation (delegating to
FromSomething) but whether that is more elegant is debatable.

2. is this somehing we want from C# (static member decleration in
interfaces)?

Perhaps, but I don't think so in the sense that you ask for.

Since C# doesn't allow free functions, it would be nice to be able to
stick static functions implemented purely in terms of the interface in
the interface declaration. This wouldn't solve the problem of missing
free-functions for class-symmetric operations though.

3. am I just being picky (should I just use constructors and forget my
intuition?)

You couldn't get by just using constructors for virtual construction.

With regard to the "FromSomething(...)" idiom, you might want to ponder
whether it buys you enough to break out of the "new(...)" idiom, which
is widely used.

One thing which FromSomething *does* buy you is that you can do
delegates to the construction, something you cannot do with new.

Beware, also that you would want to write a contructor in the class even
if you do FromSomthing, you just would just need to decide whether to
make it public or protected.

Personally I would consider having a FromSomething only as an added
option, so I would not make the constructor protected. And I would
probably only do FromSomething if there were a *lot* of SomeThings, or I
needed to do construction by delegate.

4. am I totaly wrong?

Well,.... you're mixing up two separate issues,...

hang on... can we even define constructors in interfaces today?...
god I even confused myself...

No, you can not.

You cannot instantiate an interface, since an interface is exactly a
*declaration* of what an instance *can*. Not a recepie for *how*, which
is done in a class (which can incidentally also contain state).

 

[Picho]

Thanx for the reply Helge.

To sum things up, what you say is that there is no way that an interface can
enforce or dictate the way a class instanciate itself.
I am not arguing with what you said and I even accept the fact that
interfaces has to do with behavior.

but then again, we can talk all day long philosophicly wether construction
is not a behavior...

I would still like to state that I realy want an interface to declare static
methods, even not for construction...


Picho

 

[Dmitriy Lapshin [C# / .NET MVP]]

Hi,

I would still like to state that I realy want an interface to declare
static methods, even not for construction...

To the best of my knowledge, you cannot. Interfaces assume polymorphic
behavior in .NET, and static methods cannot be polymorphic.

Some general comments:

Interfaces are not used for construction as construction in 99% cases does
not need to be polymorphic. So if you need polymorphic construction, declare
an interface for a class factory and implement several factories each
encapsulating a different way of constructing instances.

As for static methods such as Graphics.FromHandle(), they have nothing to do
with interfaces, from my point of view. They are just a convenient way of
constructing objects, but they at the same time guarantee that the
construction behavior is not overridden if you implement a derived class.

 

[Picho]

Guys thanx for the replies, but I'm afraid you are not following me....

Component-Oriented-Design.

I have no intention of using interfaces for declaring constructors for my
own pleasure.
however, examining interface-based programming there is a certain conflict
between object oriented design and component oriented design if I cannot
control the way an object is created and only use the interface for managing
its state and behavior.

Hi,

I would still like to state that I realy want an interface to declare
static methods, even not for construction...

To the best of my knowledge, you cannot. Interfaces assume polymorphic
behavior in .NET, and static methods cannot be polymorphic.

Some general comments:

Interfaces are not used for construction as construction in 99% cases does
not need to be polymorphic. So if you need polymorphic construction,
declare an interface for a class factory and implement several factories
each encapsulating a different way of constructing instances.

As for static methods such as Graphics.FromHandle(), they have nothing to
do with interfaces, from my point of view. They are just a convenient way
of constructing objects, but they at the same time guarantee that the
construction behavior is not overridden if you implement a derived class.

--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx

Thanx for the reply Helge.

To sum things up, what you say is that there is no way that an interface
can enforce or dictate the way a class instanciate itself.
I am not arguing with what you said and I even accept the fact that
interfaces has to do with behavior.

but then again, we can talk all day long philosophicly wether
construction is not a behavior...

I would still like to state that I realy want an interface to declare
static methods, even not for construction...


Picho

 

[Dan Bass]

Interfaces can contain nothing but but a skeleton of abstract methods which
your derived classes must instantiate.

If you want a parent class that does something, or contains data members,
then the interface is wrong for you. Use abstract classes instead, allowing
your static methods etc etc.

Guys thanx for the replies, but I'm afraid you are not following me....

Component-Oriented-Design.

I have no intention of using interfaces for declaring constructors for my
own pleasure.
however, examining interface-based programming there is a certain conflict
between object oriented design and component oriented design if I cannot
control the way an object is created and only use the interface for
managing its state and behavior.

Hi,

I would still like to state that I realy want an interface to declare
static methods, even not for construction...

To the best of my knowledge, you cannot. Interfaces assume polymorphic
behavior in .NET, and static methods cannot be polymorphic.

Some general comments:

Interfaces are not used for construction as construction in 99% cases
does not need to be polymorphic. So if you need polymorphic construction,
declare an interface for a class factory and implement several factories
each encapsulating a different way of constructing instances.

As for static methods such as Graphics.FromHandle(), they have nothing to
do with interfaces, from my point of view. They are just a convenient way
of constructing objects, but they at the same time guarantee that the
construction behavior is not overridden if you implement a derived class.

--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx

Thanx for the reply Helge.

To sum things up, what you say is that there is no way that an interface
can enforce or dictate the way a class instanciate itself.
I am not arguing with what you said and I even accept the fact that
interfaces has to do with behavior.

but then again, we can talk all day long philosophicly wether
construction is not a behavior...

I would still like to state that I realy want an interface to declare
static methods, even not for construction...


Picho

Picho wrote:

I want to give my classes the ability to staticly create instances,
simply because I think that calling a 'MyClass.FromSomething(Something
something)' is more intuative than a constructor 'public
MyClass(Something something)'

For classes, you can just do that:

public class MyClass {
protected MyClass(...) {...}
public FromSomething(...) { return new MyClass(...); }
}

So, actually your problem doesn't arise from trying to redefine
contruction. It arises from trying to do (what is often called) virtual
construction.

this is just me...

Beware, that other people might not agree. Sometimes it's just easier
to accept the common idioms, with the problems they offer, than to
teach all you work together with a new one (and sometimes, the new one
has it's own problems

anyway, as far as I know interfaces cannot define static members. this
pushed me into something I even like less - a class factory (even
though it is in some scenarios a good practice).

All polymorphic behaviour is on instances in C#, and you are asking for
virtual construction (which uses polymorphism). So, you need an
instance, commonly called a factory.

1. Is there a more... 'elegant' way for me to achieve this?

Not really, especially don't fall into the pit of "prototyped
contruction" if you don't actually *need* cloning.

You can do virtual construction using delegation (delegating to
FromSomething) but whether that is more elegant is debatable.

2. is this somehing we want from C# (static member decleration in
interfaces)?

Perhaps, but I don't think so in the sense that you ask for.

Since C# doesn't allow free functions, it would be nice to be able to
stick static functions implemented purely in terms of the interface in
the interface declaration. This wouldn't solve the problem of missing
free-functions for class-symmetric operations though.

3. am I just being picky (should I just use constructors and forget my
intuition?)

You couldn't get by just using constructors for virtual construction.

With regard to the "FromSomething(...)" idiom, you might want to ponder
whether it buys you enough to break out of the "new(...)" idiom, which
is widely used.

One thing which FromSomething *does* buy you is that you can do
delegates to the construction, something you cannot do with new.

Beware, also that you would want to write a contructor in the class
even if you do FromSomthing, you just would just need to decide whether
to make it public or protected.

Personally I would consider having a FromSomething only as an added
option, so I would not make the constructor protected. And I would
probably only do FromSomething if there were a *lot* of SomeThings, or
I needed to do construction by delegate.

4. am I totaly wrong?

Well,.... you're mixing up two separate issues,...

hang on... can we even define constructors in interfaces today?...
god I even confused myself...

No, you can not.

You cannot instantiate an interface, since an interface is exactly a
*declaration* of what an instance *can*. Not a recepie for *how*, which
is done in a class (which can incidentally also contain state).

 

[Picho]

OK.

Let me rearange this...

obviosly you are not following me and this is usualy my fault...

I know all about interfaces, constructors, abstract classes and everything
you guys already said.
If you are famalier with component-oriented design or interface-based
programming, this question is for you.

We are supposed to use interface-based programming for many reasons. Static
methods ARE infact "a behavior" that I would like to declare and use in my
class. I was mearly expressing my distress since we cannot declare "static"s
in an interface but still encoureged to use interface-based programming...

Thanx again.

Picho

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

interfaces are abstract method declarations, public abstract to be more
exact, a static method CANNOT be abstract.

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

Guys thanx for the replies, but I'm afraid you are not following me....

Component-Oriented-Design.

I have no intention of using interfaces for declaring constructors for my
own pleasure.
however, examining interface-based programming there is a certain conflict
between object oriented design and component oriented design if I cannot
control the way an object is created and only use the interface for
managing its state and behavior.

Hi,

I would still like to state that I realy want an interface to declare
static methods, even not for construction...

To the best of my knowledge, you cannot. Interfaces assume polymorphic
behavior in .NET, and static methods cannot be polymorphic.

Some general comments:

Interfaces are not used for construction as construction in 99% cases
does not need to be polymorphic. So if you need polymorphic construction,
declare an interface for a class factory and implement several factories
each encapsulating a different way of constructing instances.

As for static methods such as Graphics.FromHandle(), they have nothing to
do with interfaces, from my point of view. They are just a convenient way
of constructing objects, but they at the same time guarantee that the
construction behavior is not overridden if you implement a derived class.

--
Sincerely,
Dmitriy Lapshin [C# / .NET MVP]
Bring the power of unit testing to the VS .NET IDE today!
http://www.x-unity.net/teststudio.aspx

Thanx for the reply Helge.

To sum things up, what you say is that there is no way that an interface
can enforce or dictate the way a class instanciate itself.
I am not arguing with what you said and I even accept the fact that
interfaces has to do with behavior.

but then again, we can talk all day long philosophicly wether
construction is not a behavior...

I would still like to state that I realy want an interface to declare
static methods, even not for construction...


Picho

Picho wrote:

I want to give my classes the ability to staticly create instances,
simply because I think that calling a 'MyClass.FromSomething(Something
something)' is more intuative than a constructor 'public
MyClass(Something something)'

For classes, you can just do that:

public class MyClass {
protected MyClass(...) {...}
public FromSomething(...) { return new MyClass(...); }
}

So, actually your problem doesn't arise from trying to redefine
contruction. It arises from trying to do (what is often called) virtual
construction.

this is just me...

Beware, that other people might not agree. Sometimes it's just easier
to accept the common idioms, with the problems they offer, than to
teach all you work together with a new one (and sometimes, the new one
has it's own problems

anyway, as far as I know interfaces cannot define static members. this
pushed me into something I even like less - a class factory (even
though it is in some scenarios a good practice).

All polymorphic behaviour is on instances in C#, and you are asking for
virtual construction (which uses polymorphism). So, you need an
instance, commonly called a factory.

1. Is there a more... 'elegant' way for me to achieve this?

Not really, especially don't fall into the pit of "prototyped
contruction" if you don't actually *need* cloning.

You can do virtual construction using delegation (delegating to
FromSomething) but whether that is more elegant is debatable.

2. is this somehing we want from C# (static member decleration in
interfaces)?

Perhaps, but I don't think so in the sense that you ask for.

Since C# doesn't allow free functions, it would be nice to be able to
stick static functions implemented purely in terms of the interface in
the interface declaration. This wouldn't solve the problem of missing
free-functions for class-symmetric operations though.

3. am I just being picky (should I just use constructors and forget my
intuition?)

You couldn't get by just using constructors for virtual construction.

With regard to the "FromSomething(...)" idiom, you might want to ponder
whether it buys you enough to break out of the "new(...)" idiom, which
is widely used.

One thing which FromSomething *does* buy you is that you can do
delegates to the construction, something you cannot do with new.

Beware, also that you would want to write a contructor in the class
even if you do FromSomthing, you just would just need to decide whether
to make it public or protected.

Personally I would consider having a FromSomething only as an added
option, so I would not make the constructor protected. And I would
probably only do FromSomething if there were a *lot* of SomeThings, or
I needed to do construction by delegate.

4. am I totaly wrong?

Well,.... you're mixing up two separate issues,...

hang on... can we even define constructors in interfaces today?...
god I even confused myself...

No, you can not.

You cannot instantiate an interface, since an interface is exactly a
*declaration* of what an instance *can*. Not a recepie for *how*, which
is done in a class (which can incidentally also contain state).

 

[Dan Bass]

We are supposed to use interface-based programming for many reasons.
Static
methods ARE infact "a behavior" that I would like to declare and use in my
class. I was mearly expressing my distress since we cannot declare
"static"s in an interface but still encoureged to use interface-based
programming...

This depends on the OO model you're using. Interfaces aren't always
"encouraged".

 

[Dmitriy Lapshin [C# / .NET MVP]]

OK, some thoughts:

1. Interface defines behavior for an *instance* of a class - that is, of an
object, but not of the class itself. Static methods, on the other hand,
define behavior of the class itself - that's why they are called 'class
methods' in Delphi.

2. If a class implements a certain interface, you can cast a reference to an
instance of that class to the interface type:

ISomething is = (ISomething)theInstance;
is.DoSomething();

Now note that if there is another class which implements ISomething, we can
also do the folllowing:

ISomething is2 = (ISomething)theInstanceOfAnotherClass;
is2.DoSomething();

Now it is obvious that the implementations of DoSomething can be quite
different for the first and the second class - say, in the first example,
calling DoSomething would display a message box and in the second it would
erase a file on disc. Of course this sounds far-fetched but is pretty
possible from technical standpoint - and is called 'polymorphism'. What I am
trying to say here is polymorphism and interfaces are coupled together, at
least in the .NET world.

Now, with static methods - these just *cannot* be polymorphic, nor you are
able to cast a class itself to an interface type - hence the limitation.

 

[Nick Malik [Microsoft]]

Actually, Dan, Interfaces are usually encouraged in OO programming. This is
a tradition dating back to Martin Fowler's writings in the 90s and from the
introduction section in the Gang-of-Four book, where interfaces were
emphasized as a best practice.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Nick Malik [Microsoft]]

Hello Picho,

You have a distaste for class factories. That is unfortunate. In
Component-oriented-design, it is considered a good practice for one body of
code to define a behavior (the interface) and another body of code to define
how an instance is created (the factory method). These are seperate on
purpose. Behaviors are not the same as instances, and the logic for
creating instances is often quite complex. There is no reason for them to
be coupled together, and forcing them apart often reduces unnecessary
coupling.

There are seperate patterns that manage and control the ways that objects
are created. These are termed 'creational patterns' in the GoF book.
Included are Factory Method, Abstract Factory, Singleton, Builder, and
Prototype. Take a look at these patterns. Only Prototype and Singleton are
coupled to the class, and then Singleton is only coupled because of language
constraints, not OO principles. The rest illustrate the principle that the
construction of an object is an inherently seperate process from its use.

You can still use interfaces to describe object creation. That is what the
Abstract Factory pattern describes. However, in this case, you have an
interface that is responsible for creating a set of _related_ objects. By
deriving types from an abstract factory, you can create a framework.

I personally discourage the use of static methods for nearly all OO
programmers. You should use a static method ONLY when there is a behavior
of a type that is independent of the instance of that type, and even then,
you'd be challenged in a code review to justify it. This is not because I
dislike the construct. It is because this construct can lead to lazy
programming (not just in initial development... but also in maintenance
programming). I see very few reasons for opening the door to lazy
programming.

And maybe that's just me .

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Dan Bass]

Agreed.

The problem I sometimes have is that, coming from a C++ background,
interfaces different to C#. Well, C++ doesn't have the concept of an
interface at all, it's more a pattern included in design, implemented by
means of pure abstract classes. I guess this is because C# an OO language,
where C++ is a progression of C, a procedural language, stepping towards OO.

You could "cheat" the norm by having global variables, instantiations in
your "interfaces", and ... *gasp* someone stop this guy from swearing!

As I said:
"Interfaces aren't always encouraged."

which could be interpreted as you mentioned:
"Interfaces are usually encouraged..."

The web is full of Interfaces versus Abstract Classes...

 

[Dan Bass]

How would you approach the following:

In developing an application, it becomes obvious that a few lines of code is
being repeated more than a few times and so refactoring is to be done. The
thing is it's not necessarily object specific, but more of a general set of
commands.

My approash is a class that contains a public static method that is declared
as follows:

public static string ExceptionInfo ( Exception ex )
{
if ( ex == null ) return "";

StringBuilder sb = new StringBuilder();
sb.Append( " Exception: " );
sb.Append( ex.Message );
sb.Append("\r\n");
sb.Append( " Stack Trace: ");
sb.Append( ex.StackTrace );
return sb.ToString();
}

This is referenced all over applications, across different projects in my
solution (which means it's in a constants / enum definitions / type class
library) every time an exception of any sort is thrown for logging purposes.

Is this incorrect / bad / undesirable?

Thanks for your time.

Daniel.

 

[Picho]

And if I may, add to Dans example that that class is implementing an
interface - that is - following the interface-programing guidlines, and
moreover, this static method is public and therfore should be publicly known
in some manner....

 

[Nick Malik [Microsoft]]

Hello Dan,

How would you approach the following:

In developing an application, it becomes obvious that a few lines of code is
being repeated more than a few times and so refactoring is to be done. The
thing is it's not necessarily object specific, but more of a general set of
commands.

I would start with the question: what is similar between each case, and what
varies. The things that are similar should be pushed toward the top of the
inheritance tree, while the things that vary should be encapsulated. (This
is a short-hand definition of "commonality variability analysis" or CVA.
Refer to [Coplien] and [Shalloway]).

On the surface, if there is a set of repeating statements within a set of
related classes, I would think "strategy pattern" and that's where the
paragraph above led me... until I read the next part...

This is referenced all over applications, across different projects in my
solution (which means it's in a constants / enum definitions / type class
library) every time an exception of any sort is thrown for logging

purposes.

well... the strategy pattern appears to go right out the window. After all,
the repeating code is not part of related classes! So I start to think
about what you are trying to accomplish.

You defined a static method (some would call it a "helper" method) that
takes an exception object and returns a string suitable for throwing to a
log file or an exception handler of some kind.

Clearly, the thing that varies is this: what will we do with this string?
The thing that is constant is: we need a uniform description of the
exception that contains an inordinately large amount of information.
So, the creation of this string is at the top, perhaps as a concrete method
in an abstract class. The classes that inherit from that abstract class
will use this method by the fact that it is defined in the base class. The
inherited members will decide how to log the error.

So, it would look something like this:

// caveat: air code. I didn't compile this. Please forgive typos.

public abstract class IExceptionClass
{
private string ExceptionInfo ( Exception ex )
{
if ( ex == null ) return "";

StringBuilder sb = new StringBuilder();
sb.Append( " Exception: " );
sb.Append( ex.Message );
sb.Append("\r\n");
sb.Append( " Stack Trace: ");
sb.Append( ex.StackTrace );
return sb.ToString();
}
public void LogThisEvent(Exception ex)
{
string DisplayString = ExceptionInfo(ex);
WriteEventToLog(DisplayString);
}

private abstract void WriteEventToLog(string DisplayString);

}

Now, I am assuming that, since your static method didn't actually DO
anything with the string, that you will want to do many things with the
string, depending on what your code is up to. In that case, each of those
many things would require you to create a class like so:

public class MyTracer : IExceptionClass
{
private override void WriteEventToLog(string DisplayString)
{
// -- code goes here to write the event to a trace log.
}
}

public class MyEventLogger : IExceptionClass
{
private override void WriteEventToLog(string DisplayString)
{
// -- code goes here to write the event to the event log
}
}

and so on.

Add in a method in our handy-dandy class factory:
public class MyClassFactory : IMyAbstractFactory
{
/// ... singleton declaration and Instance property
/// ... other factory methods
public IExceptionClass GetEventLogger()
{
return new MyEventLogger();
}
}

In your code, when an event occurs, you would do this:
// snippet
// note: In this example, I will use a singleton to control the creation
of the class factory

try {
// offending, but not offensive, code
} catch (Exception ex) // for the sake of simplicity
{
MyEventLogger el = MyClassFactory.Instance.GetEventLogger();
el.LogThisEvent(ex);
}

You are no longer calling a static method. On the other hand, you do not
have to define the code more than once. The code is part of the handling of
errors. It is cohesively correct to place it in the inheritance tree for
the handling of errors.

Interestingly enough, the way this ends up being implemented... it's a
strategy pattern after all.
Alas, a good idea is hard to kill.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Ravichandran J.V.]

Inrefaces are meant to provide a blueprint for future implementation and
not directly control the members.

There are two choices for you - one, with an interface the other, with
abstract classes. If you wish to provide for your own definition of
certaiun members or make provision for static members, you must provide
an abstract class and not an interface.

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com

 

[Helge Jensen]

Thanx for the reply Helge.

No problemo.

I am not arguing with what you said and I even accept the fact that
interfaces has to do with behavior.

It's not me defining this, it's C#

It is very hard to describe state with only functions, which gives you:
accessors (get/set). Iterfaces with accessors (with convinient C#
properties) are closer to modelling the sub-typing idea.

but then again, we can talk all day long philosophicly wether construction
is not a behavior...

In C#, constructors are inherently different from methods. They MAKE
objects, so they cannot depend on the state of the object they create.
However, they can depend on the state of OTHER objects, which gives you:
Factory.

I would still like to state that I realy want an interface to declare static
methods, even not for construction...

I suggested that too, but as a small patch on leaving out free-functions.