Модератор: Вынесено из 5 основных отличий между Java и C++ 



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

Оффтоп: 

Какие-то странные примеры наследования. У автора книжки с ООП было явно туговато.  

Первый пример есть во всех книжках по ООП. А в чем странность? 

В том, что наследовать Square от Point и Size нельзя - квадрат не есть точка и никак не размер. Впервые такой пример встречаю просто. 

На мой взгляд, вы заблуждаетесь, гражданин начальник. Видимо, просто привыкли к объектной модели Bordand VCL, MFC, JavaBeans и им подобным - а они довольно далеки от ООП. Можно было бы это обсудить где-нить отдельно. 

Наследование - это отношение is-a, вот и все.


http://en.wikipedia.org/wiki/Inheritance_%...uter_science%29

Наследовать квадрат от неправильно, тк квадрат не есть точка, тем более не "размер".   

Именно так. Но вы (как и многие) допускаете распространенную ошибку - отождествляете эти классы с объектами реального мира. Для квадрата свойственны все поля и методы координаты и размера - именно это (все поля и методы) определяет наличие отношения is-a для классов.    

Это сообщение отредактировал(а) w1nd - 11.5.2006, 19:09

Простой пример:




ООП и постоено на объектах реального мира, просто в каждой ситуации програмист рассматривает лишь отдельные стороны объектов, важные в данной ситуации. С точки зрения геометрии квадрат не есть точка. Да, он унаследует два поля точки, но за выигрыш двух строк кода придется платить - например, можно будет откастить объект квадрата к объекту точки или размера, что будет приводить к появлению багов, непонятному коду. К примеру, у точки есть метод Paint, который мы перегружаем в Square. Тогда метод DrawPoint(Point point) приведет к изображению не точки, а квадрата при вызове DrawPoint(square). 
Согласно такой логике мне нужно наследовать класс Company от класса Contact, поскольку последний содержит все поля (адрес, имя, телефон, емейл, итп). К чему такой наследование приведет нетрудно догадаться. 
 

ООП построено не на объектах реального мира, а на принципе инкапсуляции и полиморфизма .

Само существование методов вроде DrawPoint или CreatePolygon полностью противоречит принципам ООП. Только сам объект может себя рисовать или создавать. И если бы класс Контакт не обладает атрибутом Пол или Возраст, он подойдет для Компании; в ином случае нужно просто выделить общие для них поля и методы в отдельный(е) класс(ы) и назвать соответствующе.   

Это сообщение отредактировал(а) w1nd - 11.5.2006, 20:28

Замените DrawPoint на метод Point.Paint, и проблема останется. CreatePolygon вполне может относиться к классу, занимающемуся проецированием полигонов из 3D на экран, тогда полигон сам себя прорисовать не сможет, так как ему будет необходимо знать ряд других параметров, возможно, выполнить к-л оптимизации при прорисовке, итп.


Предположим, что пол и возраст не важен и мы унаследовали Company от Contact. Бизнес-логика приложения очень сложная, где-то я по ошибке передал Company в метод, ожидающий Contact. На дебаге я потрачу раз в 30 больше времени, чем если бы я потратил 2 минуты на создание общего класса Entity. 

Какая проблема? Проблема здесь только в том, что пользователь класса Point хочет знать, каким образом этот класс себя нарисует, а знать ему (пользователю) этого не положено.

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


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

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

Да какая угодно. Например, создается репорт, содержащий к-л статистику по посещениям сайта (скажем, Контакт/Компания содержат поля MonthlyHits и IP). В данный метод передается массив Контактов, в который по ошибке попала одна Компания. У всех этих объектов вызывается проперти MonthlyHits, IP. Такой баг и заметить сложно. 

Мы про ООП или про что? Инкапсуляция подразумевает не сокрытие информации (это как самоцель не имеет смысла), а сокрытие способа хранения, реализации, взаимодействия. Это необходимо для того, чтобы не переписывать клиентский код при внесении изменений в реализацию класса. Геттеры/сеттеры - это как раз нарушение инкапсуляции (замаскированный прием структурного программирования). Вообще (как я и говорил, вы, похоже, зацикливаетесь на существующих framework'ах, которые примером ООП не являются), само по себе понятие properties объекта очень сомнительно с точки зрения ООП.


Какой-то неподходящий пример. Здесь иллюстрируется только ошибочность решения наследовать компанию из контакта, т. к. в нем есть малоподходящие компании атрибуты (MonthlyHits, IP). Но пусть это неотъемлемые атрибуты любой компании, при чем здесь наследование? Подобную ошибку с таким же успехом можно допустить где угодно: можно создать метод, принимающий в качестве параметров массив объектов и напихать туда чего попадет. 

Чует мое сердце, что для этого нужно наследование, а не инкапсуляция...  

1. Что же тогда по твоему хороший пример?
2. Чем properties плохи (то что при их использовании  можно спокойно менять способ хранения данных, я тебе уже демонстрировал)?