Do any OO languages allow subtracting features from a class?

In C++ and most object oriented lanuages I know, when you derive class B from existing class A, you can add new methods, override existing methods, and add new data members. If A has some pieces you don't want in B, you 开发者_C百科can't eliminate them. Perhaps most of the time that wouldn't make sense anyway, but there have been times I wish I could.

Are there any languages that do allow a derived class to be defined with certain of its parent's elements removed?

I think maybe the proper way to do this the subclass should provide an empty method that overrides the parent's implementation.

The problem is subclasses have an IS-A relationship to their superclasses. If the subclass took methods off, semantically would it be an instance of the superclass? How would the polymorphism work? You would run into all sorts of pain when you passed a subclass in to a method that expects the superclass type, which you should be able to do.

That said, with dynamic languages you could remove the desired methods at runtime via meta-programming. But I would just do an empty method, that possible throws some sort of UnsupportedOperation error if that makes sense.

If it need to remove features from the parent class (or parent object, it applies to prototype OO as well), it shouldn't inherit in the first place. See Liskov substitution principle:

Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.

Or, going over "is a": If D inherits from B, then every D is a B. It can't be a B if it doesn't have one of its methods.

Also, practical problem: This would basically make subtype polymorphism (being able to pass a D whenever an A is required/expected), a pretty fundamental feature of OO, impossible (since you can't know if subtypes also expose a certain method/property).

There are cases where you can get something similar to this.

For example, in Windows Forms, all of a control's properties are shown in the Property Grid, so you can edit their values in the visual designer. The base Control class exposes a bunch of common properties, like Text, that don't apply to all controls, but that (in the view of the Windows Forms team) are general enough that you should be able to set them on a control without having to know whether it's a button, label, window, etc.

While you can't actually remove these properties in a descendant class -- code can still read and write them if you really want -- you can flag them with attributes to tell the tools to hide them, so that, at least, they're not in your way.

// Don't show this property in the Property Grid
[Browsable(false)]

// Don't save this property's design-time value to be reloaded at runtime
// (i.e. don't generate a property assignment in the .designer.cs file)
[DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]

// Don't show this property in the editor's Intellisense code-completion lists
[EditorBrowsable(EditorBrowsableState.Never)]

public override string Text {
    get { return base.Text; }
    set { base.Text = value; }
}

Of course, it could be argued that it's only because of a poor design that they had to create these attributes at all -- this design clearly violates the Liskov Substitution Principle. (They could, instead, have made an interface for each of these common properties, which would let descendants opt in to supporting them, while still letting code access them without downcasting to specific control types.)

With Aspect Oriented Programming you could virtually do something similar to what you say. There are many languages aimed at this, for instance AspectJ. Anyway I guess you should consider quite well the fact you are possibly designing a bad architecture since doing this kind of things might reduce the quality of your software in terms of understendability (classes that do not always provide coherent services). Subject oriented programming is another research field aimed at doing what you suggest.

Well ... if you follow "aspect oriented programming" techniques and use interfaces, then you should be able to effectively "hide" the implementation details that you don't want your users to see since they will only have access to members of the interface