So I've found myself in a situation in which I either want to add a static member to an interface or create a static interface for my class to implement. Research has shown that this isn't a thing you can do in C# because it violates the concept of OOP. The problem I'm having is trying to find a replacement.

I have a generic data structure that I'm trying to turn into bytes to send/receive. The data structure is written and works with the generic type T, but now I am trying to add the construction/destruction from bytes. I looked into generic interfaces and came up with something like

public class HeirTree<T> where T : IEdible<T>
    { /*implementation*/ }


public interface IEdible<T>
    {
        byte[] GetBytes();
    }

public struct RobotPartPair : IEdible<RobotPartPair>
{ /*implements GetBytes*/}

This guarantees that whatever T is, I can call GetBytes on it. Now I want to create a FromBytes, but it only makes sense that it should be a constructor or a static method that returns the object. I see how this violates OOP because IEdible is not a concrete class and could be any inheriting class, but the fact that I'm using a generic T and that T will always be a concrete class should work around that. What would be the right solution here?

Ideally the entire HeirTree class has a method GetAsBytes() that returns the tree and all items inside it as an array of bytes, then has a static FromBytes or a constructor taking a byte array that can reverse an array of bytes into a tree.

Also every node in the tree is also a tree.

The only way that I've been able to work around this is with an abstract base class:

public abstract class EdibleBase<T>
where T : EdibleBase<T>, new()
{
    public abstract byte[] GetBytes();
    protected abstract void LoadFromBytes(byte[] bytes);

    public static T FromBytes(byte[] bytes)
    {
        var output = new T();
        output.LoadFromBytes(bytes);
        return output;
    }
}

Though honestly, since it's using an abstract base class it would probably be more efficient to have a protected (or public) constructor that takes a byte array and uses that in the call rather than an empty constructor and then calling a method. In the end, the constructor is really the easiest option; any reason you're avoiding using a constructor?

Now I want to create a FromBytes, but it only makes sense that it should be a constructor or a static method that returns the object.

What's wrong with making it a public method? If it's semantics, change the name.

any reason you're avoiding using a constructor?

I'm not avoiding a constructor, it just suffered the same fate as the static method in that you can't make one in the interface to force the inheriting classes to have one.

Ideally the entire HeirTree class has a method GetAsBytes() that returns the tree and all items inside it as an array of bytes, then has a static FromBytes or a constructor taking a byte array that can reverse an array of bytes into a tree.