static inner instance of abstract class

[pisacou]

Hello,
I am currently working on a strategy pattern. It consists of an abstract base class that declares some functionality, and some derived classes that implement that functionality. My problem is that only a specific set of derived classes is allowed. Coming from a Java background, I have tried to implement that in the following way:

    public abstract class Edge
    {
        private string name;
        public static Edge TOP_LEFT = new Edge("TOP_LEFT")
        {
            public PointF Coordinate(RectangleF area)
        {
            return new PointF(area.X, area.Y);
        }
    }

        private Edge(string name)
        {
            this.name = name;
        }
        public abstract PointF Coordinate(RectangleF area);

    }

I am getting the error that "an instance of the abstract class or interface Edge could not be created". Removing the abstract keyword from the class declaration gives the error "Edge does not contain a constructor that takes 1 argument".
Is there any way to implement that pattern in C#?
best regards

 

[JohnH]

Abstract classes can not be instantiated, they can't have constructors. abstract (C# Reference) | Microsoft Docs

Using a private constructor is not a problem in a not abstract class, but there are lots of syntax errors in the code you posted.

 

[pisacou]

Abstract classes can not be instantiated, they can't have constructors.

I agree with the first statement, but not with the second. What I would agree with is that abstract classes do not need to have public constructors, since these ctors cannot be called from any point outisde the class hierarchie, but only from subclasses.

but there are lots of syntax errors in the code you posted.

Yes, I noted that, too. The main reason for my post was to understand those errors and find an error-free way to realize my goal: the creation of a fixed number of instances that expose the same interface, which is defined either by a common interface or by a common class or common superclass. An interface doesn't allow to restrict the number of instances (at least not to my knowledge), so thats a dead end. Remain the use of a common class or a common superclass.
After some research, I am convinced that static inner classes are not supported in C#, at least not in the same way as in Java. BUt I found two alternative approaches:
1. private inner subclasses of the outer superclass:

    abstract class Edge
    {
        private string name;

        public static Edge TOP_LEFT = new TL();

        private class TL : Edge
        {
            internal TL() : base("TOP_LEFT")
            {

            }
            public override PointF Coordinate(RectangleF area)
            {
                return new PointF(area.X, area.Y);
            }
        }

        private Edge(string name)
        {
            this.name = name;
        }

        public abstract PointF Coordinate(RectangleF area);

    }

2. Use of (potentially anonymous) delegates:

    public class Edge1
    {
        private string name;

        private delegate PointF Coords(RectangleF area);

        private static PointF coordsBR(RectangleF area)
        {
            return new PointF(area.X + area.Width, area.Y + area.Height);
        }

        private Coords coords;

        public static Edge1 TOP_LEFT = new Edge1("TOP_LEFT", (area) => new PointF(area.X, area.Y));

        public static Edge1 BOTTOM_RIGHT= new Edge1("BOTTOM_RIGHT", coordsBR);

        private Edge1(string name, Coords coords)
        {
            this.name = name;
            this.coords = coords;
        }
        public PointF Coordinate(RectangleF area)
        {
            return coords(area);
        }

    }

Version 1. looks better to me, as it keeps associated code in one and the same class, but I do not like the idea of creating a new subclass for each new method implementation. Version 2. comes with no additional class definition, but it just seems a bit less organized, since the delegates need to be explictly assigned to the correct instance, and are not "automatically" part of the correct instance.
I would like to hear other opinions about what way is more efficient, and better coding style.

 

[JohnH]

I agree with the first statement, but not with the second. What I would agree with is that abstract classes do not need to have public constructors, since these ctors cannot be called from any point outisde the class hierarchie, but only from subclasses.

That's right, a protected constructor in abstract class could make sense, so that derived classes could access it. The protected constructor could also call another private constructor in abstract class.

 

[pisacou]

Thank you for your comment regarding contructors for abstract classes.
I have started to implement version 2 in a real world example, where the interface exposed by the abstract class consists of 3 methods, and where four different strategies to implement these methods are possible.
That involved the declaration of three delegates, declaration and and implementation of 12 methods, and using the right set of three methods to assemble each of the four classes. All in all, that just didn't look clean.
I will go for version 1, unless there is a better way to achieve my goal.