Разве какие-либо ОО-языки позволяют вычитать функции из класса?

Question

В C ++ и большинстве объектно-ориентированных языков, которые я знаю, когда вы выводите класс B из существующего класса A, вы можете добавлять новые методы, переопределять существующие методы и добавлять новые члены данных. Если у A есть какие-то фигуры, которые вам не нужны в B, вы не можете их устранить. Возможно, в большинстве случаев это не имело бы смысла, но бывали моменты, когда я хотел бы.

Существуют ли какие-либо языки, которые позволяют определять производный класс с удалением определенных его родительских элементов?

Answer 1

Я думаю, что, возможно, правильный способ сделать это, подкласс должен предоставить пустой метод, который переопределяет реализацию родителя.

Проблема в том, что подклассы имеют отношение IS-A к своим суперклассам. Если подкласс отключил методы, семантически ли это будет экземпляр суперкласса? Как будет работать полиморфизм? При передаче подкласса в метод, который ожидает тип суперкласса, вы можете столкнуться с различными видами боли.

Тем не менее, с динамическими языками вы можете удалить нужные методы во время выполнения с помощью метапрограммирования. Но я бы просто сделал пустой метод, который может выдать какую-то ошибку UnsupportedOperation, если это имеет смысл.

Answer 2

Если необходимо удалить объекты из родительского класса (или родительского объекта, это также относится и к прототипу OO), он не должен наследоваться в первую очередь. См. Принцип замещения Лискова :

Пусть q (x) - свойство, доказуемое для объектов x типа T. Тогда q (y) должно быть истинным для объектов y типа S, где S - это подтип T.

Или, переходя через «это»: если D наследует от B, то каждый D является B. Это не может быть B, если у него нет одного из методов.

Кроме того, практическая проблема: это, в основном, делает полиморфизм подтипа (способность пропускать D всякий раз, когда требуется / ожидается A), довольно фундаментальной особенностью ОО, невозможной (так как вы не можете знать, подтипы также предоставляют определенный метод / свойство).

Answer 3

С Аспектно-ориентированным программированием вы можете фактически сделать что-то похожее на то, что вы говорите.Есть много языков, нацеленных на это, например, AspectJ.В любом случае, я полагаю, вам следует хорошо подумать о том, что вы, возможно, проектируете плохую архитектуру, поскольку подобные действия могут снизить качество вашего программного обеспечения с точки зрения непостижимости (классы, которые не всегда предоставляют согласованные услуги).Предметно-ориентированное программирование - это еще одна область исследований, нацеленная на выполнение того, что вы предлагаете.

Answer 4

Бывают случаи, когда вы можете получить что-то похожее на это.

Например, в Windows Forms все свойства элемента управления отображаются в таблице свойств, поэтому вы можете редактировать их значения в визуальном конструкторе. Базовый класс Control предоставляет набор общих свойств, таких как Text, которые не применяются ко всем элементам управления, но которые (по мнению команды Windows Forms) являются достаточно общими, чтобы их можно было установить для элемента управления без необходимость знать, кнопка ли это, метка, окно и т. д.

Хотя вы не можете на самом деле удалить эти свойства в классе-потомке - код все еще может читать и записывать их, если вы действительно хотите - вы можете пометить их атрибутами, чтобы сообщить инструментам, чтобы они их скрывали, чтобы, по крайней мере, они тебе не мешают.

// 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; }
}

Конечно, можно утверждать, что только из-за плохого дизайна им вообще пришлось создавать эти атрибуты - этот проект явно нарушает Принцип замены Лискова . (Вместо этого они могли бы создать интерфейс для каждого из этих общих свойств, который позволил бы потомкам участвовать в их поддержке, в то же время предоставляя коду доступ к ним без снижения до определенных типов элементов управления.)

Answer 5

Что ж ... если вы будете следовать методикам "аспектно-ориентированного программирования" и использовать интерфейсы, то вы сможете эффективно "скрыть" детали реализации, которые не должны видеть ваши пользователи, поскольку они будут иметь доступ толькочлены интерфейса