Возможны ООП и полностью предотвращение наследования реализации?

Проблемой с большей частью примера против наследования являются примеры, где человек использует наследование неправильно, не отказ наследования к правильно абстрактному.

В статье Вы отправили ссылку на, автор показывает "уязвимость" Стопки использования наследования и ArrayList. Пример испорчен, потому что Стек не является ArrayList, и поэтому наследование не должно использоваться. Пример столь же испорчен как Строковый Символ расширения или PointXY, расширяющий Число.

перед расширением класса необходимо всегда выполнять тест "is_a". Так как Вы не можете сказать, что Каждым Стеком является ArrayList, не будучи неправильным в некотором роде, тогда Вы не должны inheirit.

контракт для Стека отличается, чем контракт для ArrayList (или Список) и стек не должен наследовать методы, который является, не заботится о (как, добираются (интервал i) и добавляют ()). На самом деле Стек должен быть интерфейсом с методами, такими как:

interface Stack<T> {
   public void push(T object);
   public T pop();
   public void clear();
   public int size();
}

класс А как ArrayListStack мог бы реализовать интерфейс Stack и в этом случае использовать состав (имеющий внутренний ArrayList) и не наследование.

Наследование не плохо, плохое наследование плохо.

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

Вы могли также использовать состав и стратегическую модель. текст ссылки

public class Car
{
  private ICar _car;

  public void Move() {
     _car.Move();
  }
}

Это намного более гибко, чем использование основанного на наследовании поведения, поскольку это позволяет, Вы для изменения во времени выполнения, путем замены новым Автомобилем вводите как требуется.

Для создания mixins/composition легче смотрите на мои Аннотации и Процессор Аннотации:

http://code.google.com/p/javadude/wiki/Annotations

, В частности, mixins пример:

http://code.google.com/p/javadude/wiki/AnnotationsMixinExample

Примечание, что это в настоящее время не работает если интерфейсы/типы, делегируемые, чтобы иметь параметризованные методы (или параметризованные типы на методах). Я работаю над этим...

Это забавно для ответа на мой собственный вопрос, но здесь является чем-то, что я нашел, что это довольно интересно: Sather.

Это - язык программирования без наследования реализации вообще! Это знает интерфейсы (названный абстрактными классами без реализации или инкапсулировавших данных), и интерфейсы могут наследоваться друг друга (на самом деле, они даже поддерживают множественное наследование!), но класс может только реализовать интерфейсы (абстрактные классы, столько, сколько ему нравится), он не может наследоваться другому классу. Это может однако "включать" другой класс. Это - скорее понятие делегата. Включенные классы нужно инстанцировать в конструкторе Вашего класса и уничтожают, когда Ваш класс уничтожается. Если Вы не перезаписываете методы, они имеют, Ваш класс наследовал их интерфейс также, но не их код. Вместо этого методы создаются, которые просто переводят вызовы к Вашему методу к одинаково именованному методу включенного объекта. Различие между включенными объектами и просто инкапсулировавшие объекты состоят в том, что Вы не должны создавать делегацию вперед сами, и они не существуют как независимые объекты, которые можно раздать, они - часть объекта и живут и умирают вместе с объектом (или более технически говоривший: память для Вашего объекта и всех включенных создается с единственным вызовом выделения, тем же блоком памяти, Вам просто нужны к init они в Вашем вызове конструктора, в то время как при использовании настоящих делегатов, каждый из этих объектов вызывает собственный вызов выделения, имеет собственный блок памяти и живет полностью независимо от объекта).

язык не так красив, но я люблю идею позади него:-)

Наследование не необходимо для объектно-ориентированного языка.

Рассматривают JavaScript, который еще более объектно-ориентирован, чем Java, возможно. Нет никаких классов, просто объекты. Код снова используется путем добавления существующих методов к объекту. Объект JavaScript является по существу картой имен к функциям (и данные), где начальное содержание карты устанавливается прототипом, и новые записи могут быть добавлены к приведенному примеру на лету.

Необходимо прочитать Шаблоны разработки. Вы найдете, что Интерфейсы очень важны для многих типов полезных Шаблонов разработки. Например, абстракция различных типов сетевых протоколов будет иметь тот же интерфейс (к программному обеспечению, называя его), но мало повторного использования кода из-за различных поведений каждого типа протокола.

Для некоторых алгоритмов глаз, открывающийся в показе, как соединить бесчисленные элементы программирования, чтобы сделать некоторую полезную задачу. Шаблоны разработки делают то же для объектов. Шоу Вы, как объединить объекты способом для выполнения полезной задачи.

Шаблоны разработки Банды Четыре