Наследование является решением реализации. Интерфейсы почти всегда представляют лучший дизайн и должны обычно использоваться во внешнем API.

, Почему запись много шаблонного кода, передавая вызовы метода составленному участнику возражает, когда компилятор сделает это для Вас с наследованием?

Этот ответ к другому вопросу суммирует мои взгляды вполне прилично.

Существует много функций на языке программирования, которые являются не действительно необходимы . Но они там по ряду причин, который все в основном сводят к возможности многократного использования и пригодности для обслуживания.

Весь бизнес заботится о, производит (качество, конечно) дешево и быстро .

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

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

Проблема с наследованием состоит в том, что оно объединяет проблему выделения подтипов (утверждение - отношения) и повторное использование кода (например, частное наследование только для повторного использования).

Так, нет это - перегруженное слово, в котором мы не нуждаемся. Я предпочел бы выделять подтипы (использование ключевого слова 'реализаций'), и импорт (своего рода как Ruby делает это в определениях классов)

Кто-либо еще помнит всех пуристов OO, идущих баллистический по реализации COM "включения" вместо "наследования?" Это достигло по существу того же самого, но с другим видом реализации. Это напоминает мне о Вашем вопросе.

я строго стараюсь избегать религиозных войн в разработке программного обеспечения. ("vi" ИЛИ "emacs"..., когда все знают его "vi"!) Я думаю, что они - знак маленьких умов. Аккомпанемент Научные профессора может позволить себе сидеть без дела и обсудить эти вещи. Я работаю в реальном мире и мог заботиться меньше. Весь этот материал является просто попытками предоставления полезных решений настоящих проблем. Если они будут работать, то люди будут использовать их. То, что языки OO и инструменты были коммерчески доступны в широком масштабе для продолжения на 20 лет, является довольно хорошей ставкой, что они полезны для большого количества людей.

Я думаю, прося ситуации, где наследование действительно необходимо, упускает суть немного. Можно фальсифицировать наследование при помощи интерфейса и некоторого состава. Это не означает, что наследование бесполезно. Можно сделать что-либо, что Вы сделали в VB6 в ассемблерном коде с некоторым дополнительным вводом, который не означает, что VB6 был бесполезен.

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

GoF (и многие другие) рекомендуют что Вы только польза состав по наследованию. Если у Вас есть класс с очень большим API, и Вы только хотите добавить очень небольшое количество методов к нему, оставляя базовое внедрение в покое, я нашел бы несоответствующим использовать состав. Необходимо было бы повторно реализовать все открытые методы инкапсулированного класса просто возвратить их значение. Это - пустая трата времени (программист и ЦП), когда можно просто наследовать все это поведение и провести время, концентрируясь на новых методах.

Так, для ответа на вопрос нет Вы не делаете абсолютно потребность наследование. Существуют, однако, много ситуаций, где это - правильное проектное решение.

Наследование определяет отношения "ISA".

class Point( object ):
    # some set of features: attributes, methods, etc.

class PointWithMass( Point ):
    # An additional feature: mass.

Выше, я использовал наследование, чтобы официально объявить, что PointWithMass является Точка.

существует несколько способов обработать объект P1 являющийся PointWithMass, а также Точкой. Вот два.

1. Имеют ссылку от PointWithMass объект p1 к некоторому Точечному объекту p1-friend. Эти p1-friend имеет Point атрибуты. Когда p1 потребности участвовать в Point - как поведение, это должно делегировать работу своему другу.

2. Полагаются на наследование языка, чтобы гарантировать, что все функции Point также применимы к моему PointWithMass объект, p1. Когда p1 потребности уже участвовать в [1 113] - как поведение, это Point объект и может просто сделать что потребности быть сделанным.

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

Редактирование.

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

Для действительно неясного злоупотребления наследованием, считайте о странном "составе C++ посредством частного наследования" болото. См. Какие-либо разумные примеры создания наследования, не создавая выделение подтипов в отношениях? для некоторого дальнейшего обсуждения этого. Это объединяет наследование и состав; это, кажется, не добавляет ясность или точность к получающемуся коду; это только относится к C++.

В следующем наследование используется для представления особого свойства для всех нескольких определенных воплощений той же вещи типа. В этом случае GeneralPresenation имеет свойства, которые относятся ко всей "презентации" (данные передали представлению MVC). Ведущее устройство Page является единственной вещью с помощью него и ожидает GeneralPresentation, хотя определенные представления ожидают больше информации, адаптированной в соответствии с их потребностями.

   public abstract class GeneralPresentation
    {
        public GeneralPresentation()
        {
            MenuPages = new List<Page>();
        }
        public IEnumerable<Page> MenuPages { get; set; }
        public string Title { get; set; }
    }

    public class IndexPresentation : GeneralPresentation
    {
        public IndexPresentation() { IndexPage = new Page(); }
        public Page IndexPage { get; set; }
    }

    public class InsertPresentation : GeneralPresentation
    {
        public InsertPresentation() { 
          InsertPage = new Page(); 
          ValidationInfo = new PageValidationInfo(); 
        }
        public PageValidationInfo ValidationInfo { get; set; }
        public Page InsertPage { get; set; }
    }

Благодаря всем для Ваших ответов. Я сохраняю свою позицию, что строго говоря наследование не необходимо, хотя я полагаю, что нашел новую оценку для этой функции.

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

Наблюдение некоторых ответов, упоминая что-то подобное заставляет меня задаться вопросом, не могло ли это быть точно, как наследование предположило, чтобы использоваться: действие с обратной силой. Напоминает мне о кавычке Stepanov: "Вы не запускаете с аксиом, Вы заканчиваете с аксиомами после того, как у Вас есть набор связанных доказательств". Он - математик, таким образом, он должен знать что-то.

Абсолютно необходимый? нет, Но думайте о лампах. Можно создать новую лампу с нуля каждый раз, когда Вы делаете один, или можно взять свойства от исходной лампы и сделать все виды новых стилей лампы, которые имеют те же свойства как оригинал, каждый с их собственным стилем.

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

Не требуемый, но хороший :)

Я соглашаюсь со всеми остальными о необходимом/полезном различии.

причина мне нравится ООП, то, потому что это позволяет мне написать код, это более чисто и более логически организовано. Одно из самых больших преимуществ прибывает от способности до "факторной" логики, это характерно для многих классов. Я мог дать Вам конкретные примеры, где ООП серьезно уменьшило сложность моего кода, но это было бы скучно для Вас.

Достаточно сказать, я сердечное ООП.

Наследование является хорошей вещью, когда подкласс действительно является тем же видом объекта как суперкласс. Например, если Вы реализуете Активный Рекордный шаблон, Вы пытаетесь отобразить класс на таблицу в базе данных и экземпляры класса к строке в базе данных. Следовательно, очень вероятно, что Ваши Активные Рекордные классы совместно используют единый интерфейс и реализацию методов как: что является первичным ключом, сохраняется ли текущий экземпляр, сохраняя текущий экземпляр, проверяя текущий экземпляр, выполняя обратные вызовы после проверки и/или сохранения, удаления текущего экземпляра, выполнения SQL-запроса, возврата названия таблицы, на которую отображается класс, и т.д.

также кажется от того, как Вы формулируете свой вопрос, что Вы предполагаете, что наследование является единичным, но не несколько. Если нам нужно множественное наследование, то мы должны использовать интерфейсы плюс состав для осуществления задания. Для помещения тонкости об этом Java предполагает, что наследование реализации исключительно, и интерфейсное наследование может быть несколькими. Один не должен идти этим путем. Например, C++ и Ruby разрешают множественное наследование для Вашей реализации и Вашего интерфейса. Тем не менее нужно использовать множественное наследование с осторожностью (т.е. сохранить Ваши абстрактные классы виртуальными и/или не сохраняющими состояние).

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

Нет.

для меня, ООП главным образом об инкапсуляции состояния и поведения и полиморфизма.

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

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

Не нужный, но полезный.

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

Зависит от Вашего определения "необходимых". Нет, нет ничего, что является невозможно для обхождений без наследования, хотя альтернатива может потребовать большего количества подробного кода, или майор переписывает приложения.

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

Наследование часто используется в качестве опоры людьми, которые слишком одержимы узким определением Java (и одержимость) ООП, хотя, и в большинстве случаев я соглашаюсь, это - неверное решение, как будто чем глубже Ваша иерархия классов, тем лучше Ваше программное обеспечение.

Существует много полезных использований наследования, и вероятно так же, как многие, которые менее полезны. Один из полезных является потоковым классом.

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

Самая большая проблема с интерфейсами в том, что они не могут быть изменены. Сделайте интерфейс публичным, затем измените его (добавьте к нему новый метод) и сломайте миллионы приложений по всему миру, потому что они реализовали ваш интерфейс, но не новый метод. Приложение может даже не запуститься, ВМ может отказаться его загружать.

Использовать базовый класс (не абстрактный) другие программисты могут наследовать (и переопределять методы по мере необходимости); затем добавить в него метод. Каждое приложение, использующее ваш класс, все равно будет работать, этот метод просто никто не будет переопределять, но так как вы предоставляете базовую реализацию, то этот метод будет использоваться, и он может отлично работать для всех подклассов вашего класса... это также может привести к странному поведению, так как иногда переопределение было бы необходимо, ладно, может быть так, но, по крайней мере, все эти миллионы приложений в мире все равно запустятся!

Я предпочитаю, чтобы мое Java-приложение все еще работало после обновления JDK с 1.6 до 1.7 с некоторыми незначительными ошибками (которые могут быть исправлены с течением времени), чем не запускать его вообще (заставляя немедленно исправлять или это будет бесполезно для людей).