Я немного неясно написал, предполагается что проперти MonthlyHits, IP могут быть как у компаний, так и клиентов. Тем не менее, пример это подходящий - ошибок можно было бы избежать, если бы Contact и Company наследовали бы от Entity. Тогда в массив Contac[] объект Company никак бы попасть не смог.


По-прежнему не вижу нарушения инкапсуляции. Объект часть своих свойств может скрывать, часть - предоставлять через методы/проперти. Если например класс Point не будет иметь методов getX, getY, то использовать его будет неудобно - для всех возможных применений класса придется создавать свой метод, меняя класс. Реюзать такой класс будет еще труднее, поскольку невозможно предусмотреть все возможные варианты использования Point. 


Существующие фрейворки, хоть и не на 100%, но по крайней мере процентов на 90 меня устраивают. Наследование Company от Contact или Square от Size - не устраивает на 100%, я легко могу представить как сложно поддерживать такой код. 
 

Имхо, это скорее способ стандартизации работы с полями (свойствами) классов. 
 

Так ведь не знаю! Вот и хочу узнать, в каком случае решение о наследовании одного класса из другого (при условии, что все поля и методы родителя свойственны дитю) может быть ошибочным?
   

Заключение о том, что поля/методы класса А свойственны и классу Б должно следовать из логических соображений, из архитектуры, а не из сравнения (все поля класса Size есть и у Square и у Car, следовательно унаследуем Square и Car от Size). Что будет, позже, когда код написан, придется изменить класс SIze и дописать метод Resize()? Не получится ли, что размеры Car можно менять как угодно? Базовый класс должен быть абстракцией более высокого уровня, чем сабкласс (Entity - абстракция от Company и Contact).  

Нет, не понимаю. Ну и что же? Теперь и Contact, и Company могут попасть в массив Entity, а Entity - это, допустим, еще и Vehicle. И что? 
А то, что вы пытаетесь привязать классы к наблюдаемым объектам, а этого делать как раз не нужно. ООП - это не концепция понимания мира сквозь призму модели классов, а способ создания программ, в которых возможны локальные изменения на любом уровне. 
Или вы пытаетесь создать заведомо ошибочный код (метод, которому на вход передаются контакты почему-то интерпретирует их как персон).


А я вот не могу представить трудностей, которые представляете вы. Поделитесь?   

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

Тот, кто пишет метод Process(Entity entity), знает, что в данный метод можно передать любую Entity. Если будет нужно создать метод, специфичный для контактов (Process(Contact contact)), то передать туда Company будет нельзя.
 

1. Непонятный код. К примеру, можно будет спокойно писать 

2. Плохой код. К примеру, добавление нового метода или поля в контакт (например, пол) через полгода после старта проекта приведет к появлению компаний женского и мужского полу.
3. Больше багов
 

Ты не знаешь примеров хорошего ООП, но при этом твердо убежден, что все что есть сейчас плохо?

Добавлено @ 22:44 

Гут!   

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

Один мой товарищ, например, считает, что возможность переопределения операций в C++ - зло, которого следует избегать любой ценой. В чем здесь прикол? У него просто нет нормальной IDE, а C++ он знает недостаточно хорошо, чтобы отследить все зависимости без IDE. А другой мой товарищ вообще не знаком с программированием и нифига не понимает во всех этих кракозяблах. Так что, программировать нужно так, чтобы все одобряли и понимали? Не смешно ли?

Добавлено @ 23:05 

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

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

Кто тебе это сказал      


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


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

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

Обмишурился чуток. Беседовали о квадратах и разнополых компаниях.
Хорошим примером ООП наверняка может быть отдельно взятый фрагмент в любом из существующих якобы-ООП-фреймворков (кроме майкрософтовских, пожалуй). Но в целом - нет. Самое жуткое - это, конечно, properties.

Целью разработки каких-либо моделей или фреймворков никогда не становится упрощение, только ускорение.      

Это сообщение отредактировал(а) w1nd - 12.5.2006, 00:14

Да ладно 
Spring Framework значительно упрощает разработку
 

Конечно. В команде когда-нибудь работал? Занимался переписыванием кода после индусов? 



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




Упрощение - тоже ускорение, оно ускоряет дебаг и поддержку кода.
 

Ни я, ни мои коллеги никогда, к счастью, не сталкивались с необходимостью переписывать чей-то код. 

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

Изначально вопрос состоял в том, может ли ООП обойтись без множественного наследования. Я утверждал, что не может и пока не никто не смог предъявить сколько-нибудь весомых аргументов против (кроме утверждений о том, что кто-то потеряет голову, глядя на классы с N-надцатью родителями). 

 

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

[OFF] MoonCat, Daily WTF: там этого добра навалом