Should inheritance (of non-interface types) be removed from programming languages?

前端 未结 20 2367
旧时难觅i
旧时难觅i 2020-12-30 05:20

This is quite a controversial topic, and before you say \"no\", is it really, really needed?

I have been programming for about 10 years, and I can\'t honestly sa

20条回答
  •  没有蜡笔的小新
    2020-12-30 05:31

    Inheritance is one of those tools that can be used, and of course can be abused, but I think languages have to have more changes before class-based inheritance could be removed.

    Let's take my world at the moment, which is mainly C# development.

    For Microsoft to take away class-based inheritance, they would have to build in much stronger support for handling interfaces. Things like aggregation, where I need to add lots of boiler-plate code just to wire up an interface to an internal object. This really should be done anyway, but would be a requirement in such a case.

    In other words, the following code:

    public interface IPerson { ... }
    public interface IEmployee : IPerson { ... }
    public class Employee : IEmployee
    {
        private Person _Person;
        ...
    
        public String FirstName
        {
            get { return _Person.FirstName; }
            set { _Person.FirstName = value; }
        }
    }
    

    This would basically have to be a lot shorter, otherwise I'd have lots of these properties just to make my class mimic a person good enough, something like this:

    public class Employee : IEmployee
    {
        private Person _Person implements IPerson;
        ...
    }
    

    this could auto-create the code necessary, instead of me having to write it. Just returning the internal reference if I cast my object to an IPerson would do no good.

    So things would have to be better supported before class-based inheritance could be taken off the table.

    Also, you would remove things like visibility. An interface really just have two visibility settings: There, and not-there. In some cases you would be, or so I think, forced to expose more of your internal data just so that someone else can more easily use your class.

    For class-based inheritance, you can usually expose some access points that a descendant can use, but outside code can't, and you would generally have to just remove those access points, or make them open to everyone. Not sure I like either alternative.

    My biggest question would be what specifically the point of removing such functionality would be, even if the plan would be to, as an example, build D#, a new language, like C#, but without the class-based inheritance. In other words, even if you plan on building a whole new language, I still am not entirely sure what the ultimate goal would be.

    Is the goal to remove something that can be abused if not in the right hands? If so, I have a list a mile long for various programming languages that I would really like to see addresses first.

    At the top of that list: The with keyword in Delphi. That keyword is not just like shooting yourself in the foot, it's like the compiler buys the shotgun, comes to your house and takes aim for you.

    Personally I like class-based inheritance. Sure, you can write yourself into a corner. But we can all do that. Remove class-based inheritance, I'll just find a new way of shooting myself in the foot with.

    Now where did I put that shotgun...

提交回复
热议问题