Наследование, как им пользоватся

Уважаемые программисты, осозновая что тема по сути банальная, но изучив пару книг по теме не только наследования, но пытаясь понять суть самого наследования прочитал книги начиная от павловской и для чайников,  на данный момент для профессионалов пытаюсь осилить. Все просто и легко написано, но не могу применить на практике я наследование. Синтаксис и семантику изучил, понимаю, что с помощью наследования можно наростить возможности, дибо подписам "контракт" выполнять определенные функции. Но в моем случае я как в примерах приводится не пишу такие проги, как для сотовых компаний (а хотелось бы) но хочу применять три столпа ООП, но как? Опытных программистов прошу объяснить "на пальца", буду благодарен если продвинете в этом направлении. 
14 ответов

DossПочитай книгу Design Patterns - авторы Э. Гамма   Р. Хелм   Р. Джонсон   Дж. Влиссидес.Лучше примеров чем в шаблонах проектирования не найдешь, заодно и много полезного узнаешь  


Ну если вопрос только в том: "как же это все применить на практике", то моя версия ответа: "все приходит только с опэтом".Помнятся мне мои первые попытки писать в стиле ООП. Я просто тупо все сводил к классам, все что нужно и не нужно... я объявлял кучу не нужных делегатов для связи между классами и события... выделял в отдельные классы то, что относилось к единой группе данных... как следствие этого, все только усложнялось и еще больше усложнялось, пока я не понял, что для того чтоб писать в стиле ООП, надо начать думать в этом стиле. Особенность такого мышления состоит в том, чтобы сводить код к абстракции. Не совсем прямо и тупо все, иначе можно доабстрагироваться до такого, что можно будет свихнуться при попытке внести что-то новое в код или внести какие-либо изменения. При абстрагировании кода, надо смотреть еще и на контекст задачи.Например, если вы разрабатываете текстовый редактор, и ставите перед собой задачу усовершенствования его функций в дальнейшем, то вы можете определить сам документ, как одну простую единицу данных (класс TextDocument), содержащую свойства Text и UIEditor и методы Save и Print (это в простом случае, для примера). Свойство UIEditor возвращает, например, экземпляр объекта типа Control, который содержит элементы управления для форматирования документа. Вся ваша программа, весь ваш основной код работает только с этими свойствами и этими типами свойств и с этими методами. Далее, для начала, вы можете сделать класс SimpleTextDocument (наследника TextDocument), который представляет формат простого текстового документа. Класс реализует конкретные возможности данного типа документа, т.е. возвращает в качестве UIEditor некий Control (это может быть Panel, UserControl и т.п.) который содержит элементы для форматирования этого документа (для SimpleTextDocument можно вернуть null, т.к. нет возможности его форматировать). Конкретные реализации методов Save и Print умеют этот формат документа сохранять (в Stream(!), а не в файл) и распечатывать. Весь основной код имеет ссылку на тип TextDocument и ему уже без разницы, какого конкретно наследника вы присвоили этой ссылке. Вы в любой момент времени можете добавить новый тип документа, реализовав наследника от TextDocument (или от SimpleTextDocument, если нужна часть его возможностей), а основной код программы даже не заметит этого, т.к. он тупо будет считать свою ссылку типом TextDocument и не более.Конечно, я привел довольно сокращенный и не до конца продуманный пример, но смысл приведения к абстракции, а также преимущество возможности наследования он слегка демонстрирует.ООП позволяет создать приложение не как одно целое, а как набор логически сгруппированых данных и методов работы с этими данными (собствеенно это и есть класс) и связанных между собой абстрактными (или поздними) связями. При этом любой класс может быть безболезненно, просто и тупо заменен на своего наследника без необходимости производить целую массу изменений в где-то в коде.Также ООП может демонстрировать прекрасную возможность переиспользования ранее созданного кода в других приложениях.Среди начинающих в ООП, нередко бытует ошибочное мнение что ООП нужен только для создаия пользовательского интерфейса. Это, конечно же, не так. ООП полезен и в GUI и в самой логике приложения.Более лучше это все можно понять только на практике, при разборе конкретных примеров (не одного типа).Добавлено через 3 минуты и 2 секундыКстати да, azesmcar прав. Шаблоны проектирования демонстрируют очень хорошие примеры ООП, а также являются очень хорошим стартом в ООП.


Наследование стоит применять лишь в одном случае: когда 2 класса связаны отношением "является", то один(более конкретный) должен наследовать другой(более абстрактный).В целом, чем меньше в программе используется наследование, тем легче её читать, т.к. нет запутанных иерархий наследования, которые совместно с полиморфизмом способны свести на нет многие преимущества ООП.P.S. Подробнее читай в вышеуказанной книге от GoF.


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


QryStaLну он же сказал что изучил книги от "для чайников" до более высокого уровня..и читает - для профессионалов..следовательно имеет представление об ООП. Просто не знает куда его применятьДобавлено через 1 минуту и 16 секундмне кажется человек сейчас на стадии
Помнятся мне мои первые попытки писать в стиле ООП. Я просто тупо все сводил к классам, все что нужно и не нужно... 
Книга сложная для чтения но при желании осилить можно


Я бы не стал советовать новичку эту книгу - еще больше запутается.
Ну посоветуй альтернативу, мне было бы интересно узнать что она существует...  что ещё можно взять в качестве основы?  Буч "ООА/П"? Она тоже не из простых, да ещё и автор со своим навязыванием RUP+UML...  Хорошая книга - "Основы ООП" Мейер, но опять же не из лёгких, да и кто сказал, что должно быть легко? "Тяжело в учении - легко в бою." (с)Не тратить же теперь время на книги аля "ООП - это просто", подобные серии не то что для чайников, а для людей которые себя не уважают и время своё не ценят.Изучать ООП вне контекста паттернов проектирования - пустая трата времени, да и вообще неразумно изобретать всё с нуля, когда уже написаны десятки книг по паттернам, на практике доказавшим свою эффективность. Правда абсолютно любая из этих книг подразумевает уже не только хорошее владение, по крайней мере, одним объектно-ориентированным языком программирования, но и близкое знакомство с "Design Patterns".


Изучать ООП вне контекста паттернов проектирования - пустая трата времени, да и вообще неразумно изобретать всё с нуля, когда уже написаны десятки книг по паттернам, на практике доказавшим свою эффективность. Правда абсолютно любая из этих книг подразумевает уже не только хорошее владение, по крайней мере, одним объектно-ориентированным языком программирования, но и близкое знакомство с "Design Patterns". 
Вот только паттерны сами по себе требуют знания как ООП, так и вызываемых им проблем. И книга GoF - скорее букварь, чем серебряная пуля. Смотри, например:
Наследование стоит применять лишь в одном случае: когда 2 класса связаны отношением "является", то один(более конкретный) должен наследовать другой(более абстрактный).
Делать ли класс Square более конкретным наследником классом Rectangle?Doss, не уверен - не применяй. Кстати, то же самое относится к паттерам  


Когда я проходил в университете эти паттерны Bridge, AbstractFactory, etc. всё казалось невероятным бредом: ничерта не понятно зачем это надо, ведь писали же мы без этого много чего и нормально... Постепенно понял, что во всем этом скрыт глубокий философский смысл, но боюсь что полностью его ещё не осознал. Наверное требуется некоторое время.Вообще сложилось неприятное ощущение, что все эти "извращения" подходят больше для Java, а не для .NET. Модель MVC мне встречалась только в Java коде, который читать было несколько тяжеловато (ничерта не понятно что, куда и для чего). Скачанный код с MSDN не выделяется такими сложностями, поэтому там всё относительно легко и понятно. (Вполне возможно, что он просто написан левыми программистами, поэтому он неудобен при добалении новых возможностей, в следствие отсутствия примененных паттернов) 


Doss, ... объяснить "на пальца" ...Читай классику.Гради Буч. Объектно-ориентированный анализ и проектирование.


Kakadu, MVC - MonoRails, ASP.NET MVC - не встречались?, даже сами по себе WebForms - это практически реализация оригинального MVC. Эти "извращения" ты просто не умеешь узнавать ;) Формы и вообще система с контролами - композит. Обработка запросов в asp.net - шаблонный метод. Фабрики - чуть ли не каждый второй класс - да хоть WebRequest. Паттерны - это не извращения, это заранее известные решения проблем, ты их и без знания применяешь, только при этом тратишь время на изобретение колеса.


Вот только паттерны сами по себе требуют знания как ООП, так и вызываемых им проблем. И книга GoF - скорее букварь, чем серебряная пуля.
И в чём противоречие с тем что я сказал? А книгу GoF я и позиционирую как основу, что легко понять по риторическому вопросу:
что ещё можно взять в качестве основы
Делать ли класс Square более конкретным наследником классом Rectangle?
Вот на таких примерах ООП не изучить - это факт. 


Ну посоветуй альтернативу, мне было бы интересно узнать что она существует...  
http://www.williamspublishing.com/Books/97...459-1185-8.html


Вот на таких примерах ООП не изучить - это факт. 
Это классический пример с подвохом. Попробуй дать правильный ответ.
И в чём противоречие с тем что я сказал? А книгу GoF я и позиционирую как основу, что легко понять по риторическому вопросу:
Проблема самих паттернов (и GoF) в том, что они бесполезны в качестве примеров для изучения, и даже немного вредны - прочтение книги обычно приводит к приступам овердизайна. К ней нужно прилагать опытного разработчика, который будет бить по рукам.В качестве алтернативы/дополнения можно взять книгу Фаулера по рефакторингу.


Это классический пример с подвохом. Попробуй дать правильный ответ.
Это классическая провокация, любой ответ можно развернуть как неправильный, т.к. данных не достаточно для принятия решения. К тому же, если отбросить строгие математические определения, то отношение "является" тут будет в обе стороны, причём квадрат будет более абстрактным, т.к. у него меньше данных, достаточных для полного описания. В общем, правильный ответ: правильного ответа не существует.
http://www.williamspublishing.com/Books/97...459-1185-8.html 
Мне она показалась слишком нудной(ну не нравится мне навязывание RUP)... хотя вцелом книга полезная и кстати подразумевает, что читатель уже знаком с паттернами GoF, особенно гл. 26 это подразумевает   
прочтение книги обычно приводит к приступам овердизайна
ну это особенность человеческой натуры, просто не надо останавливаться на одной книге, например, в качестве противоядия от овердизайна хорошо подойдёт книга Кериевски "Refactoring to Patterns".
В качестве алтернативы/дополнения можно взять книгу Фаулера по рефакторингу. 
ну какая ж это альтернатива? дополнение 100%-ое.