С появлением дополнительных методов действительно ли абстрактные классы менее привлекательны?
<android.support.v7.widget.Toolbar
android:id="@+id/custom_toolbar"
android:layout_width="match_parent"
android:layout_height="?android:attr/actionBarSize"
android:background="@android:color/holo_red_dark">
<TextView
android:layout_width="match_parent"
android:layout_height="wrap_content"
android:text="abc"
android:textColor="@android:color/white"
android:textSize="20sp"
android:layout_marginRight="?android:attr/actionBarSize"
android:gravity="center"/>
</android.support.v7.widget.Toolbar>
11 ответов
Что дополнительные методы позволяет, сделать необходимо сфокусироваться в на том, что должны на самом деле делать абстрактные классы. Существует искушение реализовать "служебный" код в абстрактных классах, потому что это будет использоваться реализаторами даже при том, что это не может быть часть логического дерева наследования. Дополнительные методы позволяют Вам присоединить эти служебные методы для интерфейса, не загромождая Ваши абстрактные базовые классы.
Править
А именно, я применил бы эти инструкции.
Наследование
- ДЕЙСТВИТЕЛЬНО используйте наследование, если поведение является частью логического поведения базового класса
- НЕ используйте наследование, если поведение является сквозным (относится к вещам за пределами Вашей иерархии объектов). Они потребуют дублирования.
Служебные классы
- ДЕЙСТВИТЕЛЬНО используйте служебные классы (статические классы), если поведение логически не принадлежит классу, это действует на
- НЕ используйте служебные классы, если они изменяют внутреннее состояние объекта, это действует на. Модификация состояния должна быть зарезервирована только для иерархии реализации объектов.
Дополнительные методы
- ДЕЙСТВИТЕЛЬНО используйте то же решение для дополнительных методов, как Вы были бы для служебных классов, когда они создают меньше трения. Если принятие дополнительных методов чувствует себя менее естественным, не делайте этого.
- ДЕЙСТВИТЕЛЬНО используйте дополнительные методы для добавления утилиты к классам, которыми Вы не управляете (как строка).
- НЕ используйте дополнительные методы, когда поведение используется классом, это расширяется. В то время как возможно сделать это, это чувствует себя изобретенным
- НЕ используйте дополнительные методы просто, потому что Вы можете. На самом деле не отклоняйтесь от старого доброго сформированного ООП, если Вы не имеете к. Когда Вы имеете к, однако, дополнительные методы являются относительно полезным и безопасным решением сделать.
РЕДАКТИРОВАНИЕ 2
Мысль о другом ДЕЛАЕТ для дополнительных методов
ДЕЙСТВИТЕЛЬНО используйте дополнительные методы для обеспечения естественного языка (внутренний DSL) для определенных реализаций. Вот глупый пример.
int age = getAge();
if (age.IsDraftAge() && !age.IsLegalDrinkingAge())
{
Console.WriteLine(@"You cannot drink until your birthdate on {0}.
Join the army instead.",
age.GetYearWhenGettingDrunkIsOk());
}
Нет, это уменьшит некоторые неправильные употребления абстрактных классов.
Абстрактный класс должен содержать реализации/поведения по умолчанию, которые могут переопределить подклассы. Если учтено соответственно, это означает, что Вы могли бы переопределить просто единственное поведение класса и работать со значениями по умолчанию для остальных. Дополнительные методы обеспечивают что-то действительно различное от этого.
Я несколько раз использовал эту функциональность - и на самом деле, эта функциональность была создана специально для цели украсить интерфейсы, не изменяя их, следовательно LINQ. Все совершенство, которое является LINQ (к Объектам, по крайней мере) основано на дополнительных методах к IEnumerable <T>.
Однако я не чувствую, что дополнительные методы всегда заменяют абстрактные базовые классы для того, когда Вам нужны они. Дополнительные методы не могут получить доступ к частному состоянию расширенного класса - дополнительные методы похожи на экземпляры, но все еще статичны.
Дополнительные методы и абстрактные базовые классы решают два различных типов проблем, и выбор использовать любую из этих парадигм не должен зависеть друг от друга.
Мой ответ на Ваш вопрос о заголовке таким образом: Нет, существование Дополнительных Методов не делают Абстрактные базовые классы менее привлекательными. Если Вы полагаете, что существование Дополнительных Методов делает Абстрактные базовые классы менее привлекательными, то каждый не использовал Абстрактные базовые классы правильно во-первых.
Мне действительно нравятся дополнительные методы, потому что это дало мне, способность определить Находит (Предикат), Удаляет (Предикат) и т.д. на IList<T> который я пропускал. Я не думаю, что можно сказать, что они - замена для абстрактных классов.
Я также определил дополнительные методы для добавления универсального поведения. Я люблю свой метод расширения ToJson на объекте или довольно удобном ToXml.
Единственная проблема, которую я имею с Вашим примером, я всегда смотрю IsCurrentUser как свойство не метод, и увы у нас нет дополнительных свойств. Но я придираюсь к мелочам
Они completly не связанный. Я использую абстрактный класс, когда я хочу смоделировать поведение, которое другие реализуют или наследуют.
Я думаю, что это зависит от Вашего использования -
Если Ваше основное беспокойство осуществляет рефакторинг для уменьшения количества исходных файлов и/или классов в блоке, то да, дополнительные методы являются определенно способом пойти, и абстрактные классы, вероятно, закончат тем, что использовались меньше.
Однако для тех, кто заботится больше о том, что абстрактные классы представляют концептуально, не, много изменилось. Все еще имеет смысл в организационном кодом контексте помещать "общедоступный интервал getCalories ()" в абстрактном классе "Еда", поскольку это было бы глупо для человека, едящего его (код с помощью подкласса еды) для определения, сколько калорий это имеет.
Одним словом: Да. Вследствие того, что абстрактные классы налагают много на будущие внедрения, общие рекомендации, кажется, для создания абстрактных классов, которые реализуют интерфейсы (например, DBDataReader: IDataReader). Пока метод не требует доступа к внутреннему состоянию объекта, я не вижу оснований для не рендеринга его как дополнительного метода. Вы получаете функциональность без стоимости.
Если Вы не должны получать доступ к защищенным полям из дополнительного метода, то это - AFAIK способ пойти, так как можно наследовать несколько интерфейсов и получить все связанные расширения этот путь (в то время как можно только произойти из единственного абстрактного класса).
Нет, абстрактные классы не менее привлекательны. Абстрактные классы обеспечивают надлежащую парадигму для иерархий объектов.
Дополнительные методы только действительно полезны, если Вы должны добавить методы экземпляра для уже существующего класса, но не можете изменить код непосредственно.
Дополнительные методы хороши, но Вы не можете сравнить их или их использование к абстрактным классам. Не забывайте, какова инкапсуляция, это - один из столба ООП...
Я думаю, что существуют абсолютно случаи, где это - хорошая идея. Linq является ярким примером преимуществ, но существует другой: потоки.
Целая причина потоки являются абстрактным классом, состоит в том, потому что они должны были поддерживать методы как BeginRead, ReadByte, и т.д. Поток мог быть интерфейсом, и все те методы могли быть дополнительными методами вместо этого. Это позволило бы сделать, вещам нравится, наследовались непотоковому классу и добавляют потоковую функциональность и делают (более) естественным добавить потенциально полезные потоковые методы как 'потоковое содержание дампа к буферу памяти'.
Я ничего не использовал мимо.NET 2.0, таким образом, я понятия не имел, что Вы могли сделать это. Кажется странным мне; интерфейсы не для реализаций. Я нашел бы это сбивающим с толку. Кроме того, примером, который Вы показываете, является класс, не интерфейс.