Здравствуйте, -VaS-, Вы писали:

VS> И объекты — это не "экземпляры классов", как убедительно врет нам таварищ Мейер.

Дожили млин.

Здравствуйте, Steamus, Вы писали:

VS>> И объекты — это не "экземпляры классов", как убедительно врет нам таварищ Мейер.

S>Дожили млин.

Ага. Например, в javascript классов нет, а объекты есть.

Здравствуйте, Аноним, Вы писали:

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

Вы были все восемь лет не тем заняты. От программирования устают все. Нужно было интересоваться предметной областью.

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

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

Здравствуйте, niralex, Вы писали:

N>Я учавствую в реализации одного проекте с компонентно-ориентированной архитектурой. Мне нравится.

Хорошо, что нравится. Только не чаВкайте в процессе.

Здравствуйте, dimgel, Вы писали:

D>Здравствуйте, Steamus, Вы писали:

VS>>> И объекты — это не "экземпляры классов", как убедительно врет нам таварищ Мейер.

S>>Дожили млин.

D>Ага. Например, в javascript классов нет, а объекты есть.

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

Здравствуйте, Аноним, Вы писали:

А>Я слишком много времени и сил трачу на перетасовывание классов и бесконечный рефакторинг

Источников проблем есть минимум три, но против ООП — ни одного.
1. Узость мышления/слабая практика/отсутствие хороших учителей, вобщем ваша личная неспособность хотя бы "проинтуичить" архитектуру. Как результат — вопиюще неподобающие изменения в архитектуре, которые по идее должны быть не сложнее прикручивания ещё пары классов. Это не личный наезд, надо просто честно себе ответить насколько вы широки и глубоки профессионально, всё таки 8 лет — это где-то середнячковый уровень.
2. Вы используете неэффективно язык или сам язык является слишком убогим. Например, Смоллток — это "чистый ООП" с мощным рантаймом, позволяющий самые немыслимые вещи. В противовес ему С++ — это пороховая бочка, которая только выглядит как ООП, являясь скорее "объектно ориентированными граблями".
3. Вы не очень чётко определились со всеми требованиями (в т.ч. и потенциальными), поэтому изначально слишком простая архитектура потребовала радикальных изменений.

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

А>ООП — это когда вы сначала создаете набор абстракций, инкапсулируете реализацию, делаете систему гибкой с помощью полиморфизма, а потом героически преодолеваете...

Ай, фигня! Всегда находится проблема, рушащая изначальную идиллию — что с того? Итерационное перепроектирование — это норма, не надо из-за неё расстраиваться. Лучше сегодня всё стереть и переписать, чем завтра упереться в тупик.

Здравствуйте, Sharov, Вы писали:

А>Хотелось бы выработать уже нормальную методику разработки архитектуры, чтобы хотя бы новый код писать нормально, без кривостей и переделок.

Пока универсальный принцип такой: разделять всё на подблоки и делать связи между ними максимально гибкими.

Здравствуйте, Аноним, Вы писали:

А>3) классы в типичном объектном языке программирования можно соединять только отношением «is-a» (наследование)

Отношения — это МЕТОДЫ классов, а наследование — просто способ построения абстракций. Кроме того, классы могут включать коллекции других классов, агрегируя их функции.

А>Например, в известной «Circle-ellipse problem»...

Это у трепологов — проблема. Иерархия круг-овал напрямую зависит от задачи, в которой они используются. Хуже того — где-то это могут быть вообще две разных ветки наследования! Например:
ellipse(rounded rectangle) <- rectangle <- non-symmetric-shape <- shape -> symmetric shape -> square -> circle

А>5) классы в языке программирования привязывают конкретную реализацию к понятию, что в будущем создает логические противоречия при использовании понятия, описываемого этим классом в другом контексте.

Для этого и надо думать, чтобы спроектированный класс в другом контексте вёл себя правильно! Для этого есть ИНТЕРФЕЙСЫ, позволяющие одному и тому же объекту выглядеть "родным" для соотв. контекста.
Кроме того, это типичная ошибка — держать в одном классе ВСЁ. Иерархия для того и придумана, чтобы выделять общее "наверх".

А>6) мы можем лишь описать очень ограниченное множество понятий в очень ограниченном представлении, что практически неизбежно приводит к таким проблемам как смешивание понятий (один и тот же класс ассоциируется с различными понятиями) и логические ошибки (логически некорректное наследование и использование классов), для исправления которых требуются большие трудозатраты;

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

А>7) поскольку отображение понятий предметной области на классы всегда ограничено....

Ограниченно, но ДОСТАТОЧНО для описания требуемой абстракции. Если последущие требования напрочь корёжат изначальный класс, это хреновое проектирование, только и всего.

Как правильно уже заметили, ООП — лучшее из того, что есть на сегодня. И не факт, что в будущем будет что-то лучше. Просто недостаток опыта ведёт к грустным рефакторингам, вот опыт-то и надо "прокачивать"! Ну и чисто профессиональная интуиция: даже когда клиент говорит "мне достаточно трёх филиалов", подумай и сделай запас на 4,000,000,000 филиалов, да ещё с иерархией — не ошибёшься!

> А>ООП — это когда вы сначала создаете набор абстракций, инкапсулируете реализацию, делаете систему гибкой с помощью полиморфизма, а потом героически преодолеваете...
>
> Ай, фигня! Всегда находится проблема, рушащая изначальную идиллию — что с того? Итерационное перепроектирование — это норма, не надо из-за неё расстраиваться. Лучше сегодня всё стереть и переписать, чем завтра упереться в тупик.

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

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

ООП своей инкапсуляцией не дает работать с сетевой структурой программы. В ООП нужна строгая определенная и единственная декомпиляция или начинаются сложности. Структура объектов обязывает.

Я для себя выход нашел, когда понял порочность инкапсуляции кода. Данные оставил как есть, то есть к структурам данных (это не БД) подхожу все еще в ООП стиле. А вот код и локальные поля считаю документом, структуру которого формирую и работаю с ним как с документом, как с описанием, как с инструкцией. И все удобно — документ (программа) имеет понятную структуру, можно сделать индексы для удобства. Есть разделы, абзацы, ссылки, примечания, всё как у людей.

Здравствуйте, matumba, Вы писали:

M>Источников проблем есть минимум три, но против ООП — ни одного.
M>1. Узость мышления/слабая практика/отсутствие хороших учителей, вобщем ваша личная неспособность хотя бы "проинтуичить" архитектуру. Как результат — вопиюще неподобающие изменения в архитектуре, которые по идее должны быть не сложнее прикручивания ещё пары классов. Это не личный наезд, надо просто честно себе ответить насколько вы широки и глубоки профессионально, всё таки 8 лет — это где-то середнячковый уровень.

А откуда вы знаете, что у меня получается хуже, чем у вас?

M>3. Вы не очень чётко определились со всеми требованиями (в т.ч. и потенциальными), поэтому изначально слишком простая архитектура потребовала радикальных изменений.

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

M>Если все три пункта вам не подходят, было бы интересно взглянуть на этот интересный случай "одно требование заказчика коверкает всю архитектуру". Возможно, вам бы дали советы как изначально следовало проектировать.

Я не говорил «коверкает всю архитектуру», просто очень часто стоимость выполнения требования как-то совершенно не соответствует видимой сложности этого изменения. Например, заказчик говорит: хочу, чтобы работа этого модуля и этого модуля зависела от такой-то информации одинаково и синхронно. Для заказчика это внешне выглядит как «добавить еще два лейбла на экран», а это два совершенно не связанных между собой ни функционально, ни архитектурно модуля, которые друг о друге знать не знают (привет, изоляция и инкапсуляция!), работают в разных потоках и находятся в разных библиотеках. Это, естественно, не рушит всю архитектуру, но требует добавления новых сущностей, изменения интерфейсов, в общем — приличной по объему работы, а требование-то внешне совершенно ничтожное.

Здравствуйте, matumba, Вы писали:

M>Отношения — это МЕТОДЫ классов, а наследование — просто способ построения абстракций. Кроме того, классы могут включать коллекции других классов, агрегируя их функции.

Методы классов не выражают отношения между классами, в крайнем случае они выражают отношения класс-объект.

M>Это у трепологов — проблема. Иерархия круг-овал напрямую зависит от задачи, в которой они используются. Хуже того — где-то это могут быть вообще две разных ветки наследования! Например:
M>ellipse(rounded rectangle) <- rectangle <- non-symmetric-shape <- shape -> symmetric shape -> square -> circle

Но вы же, наверное, согласны, что названия классов и иерархии между ними должны быть осмысленными? То есть вы же не будете называть класс «Employee», если он описывает прямоугольник, и наследовать что попало от чего попало только ради требований задачи, не обращая внимания на получающуюся семантику?

M>Для этого и надо думать, чтобы спроектированный класс в другом контексте вёл себя правильно! Для этого есть ИНТЕРФЕЙСЫ, позволяющие одному и тому же объекту выглядеть "родным" для соотв. контекста.
M>Кроме того, это типичная ошибка — держать в одном классе ВСЁ. Иерархия для того и придумана, чтобы выделять общее "наверх".

Я под классами имею в виду интерфейсы тоже — это различие конкретных языков программирования, например, в C++ его нет. С точки зрения дизайна оно несущественно.

M>Ну не... вы прям говорите про какой-то чёрный ящик без хелпа! Каждый класс имеет чёткую область применения, никакого смешения там нет. Читайте доки и будет вам щщастье!

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

А>>7) поскольку отображение понятий предметной области на классы всегда ограничено....

M>Ограниченно, но ДОСТАТОЧНО для описания требуемой абстракции. Если последущие требования напрочь корёжат изначальный класс, это хреновое проектирование, только и всего.
M>Как правильно уже заметили, ООП — лучшее из того, что есть на сегодня. И не факт, что в будущем будет что-то лучше. Просто недостаток опыта ведёт к грустным рефакторингам, вот опыт-то и надо "прокачивать"! Ну и чисто профессиональная интуиция: даже когда клиент говорит "мне достаточно трёх филиалов", подумай и сделай запас на 4,000,000,000 филиалов, да ещё с иерархией — не ошибёшься!

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

Здравствуйте, dimgel, Вы писали:

D>Ага. Например, в javascript классов нет, а объекты есть.

Они там, конечно, есть — в неявном виде. Интерфейс класса определяется из фактического использования объектов. Спецификацией класса обычно является функция-конструктор, создающая объект. Они есть для программиста, так как программист, безусловно, понимает, объекты какого типа он обрабатывает в функции, которую пишет. Ну и те более-менее большие и серьезные программы на JavaScript, которые я видел, фактически, повторяют структуру обычной статически-типизированной программы, просто роль описателя классов выполняет функция-конструктор. И это вынужденное решение, так как иначе вы просто утонете в коде.

Здравствуйте, grosborn, Вы писали:

G>Я для себя выход нашел, когда понял порочность инкапсуляции кода. Данные оставил как есть, то есть к структурам данных (это не БД) подхожу все еще в ООП стиле. А вот код и локальные поля считаю документом, структуру которого формирую и работаю с ним как с документом, как с описанием, как с инструкцией. И все удобно — документ (программа) имеет понятную структуру, можно сделать индексы для удобства. Есть разделы, абзацы, ссылки, примечания, всё как у людей.

А можно подробней, как именно это выглядит?

> А можно подробней, как именно это выглядит?

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

Здравствуйте, grosborn, Вы писали:

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

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

Я б не сказал, что альтернативен сам подход. Альтернативна идеология, а результат получается теми же средствами. Вот например:

http://msdn.microsoft.com/en-us/library/system.windows.forms.controlpaint(v=vs.110).aspx

— типичная смысловая группировка кода, работающего с разными объектами. У меня много хелперов. Хелперов на один объект может быть не один, это определяется смысловой группировкой кода. Может быть вообще, в объекте только поля, а логика в хелпере. Я не ограничиваю доступ к внутренним полям объектов данных, с которыми работают хелперы. Грубо говоря какой-нибудь объект Point или Rectangle нафиг не сдался его инкапсулировать. В объектах я оставляю сервисные функции. Я не боюсь копипастить часть хелпера и курочить его как локальный хелпер, при этом сохраняю ссылку что бы можно было посмотреть "как там".

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

Здравствуйте, matumba, Вы писали:

M>ellipse(rounded rectangle) <- rectangle <- non-symmetric-shape <- shape -> symmetric shape -> square -> circle

..circle -> squared circle..

Здравствуйте, dimgel, Вы писали:

D>Ага. Например, в javascript классов нет, а объекты есть.

Какое непонимание ООП(Объектно-ориентированного подхода). КЛАСС это кусок кода )) а ОБЪЕКТ это кусок памяти, в грубом приближении. Когда вы у своего объекта в жаваскрипте вызываете метод, кто исполняет инструкции?

_>Какое непонимание ООП(Объектно-ориентированного подхода). КЛАСС это кусок кода )) а ОБЪЕКТ это кусок памяти, в грубом приближении. Когда вы у своего объекта в жаваскрипте вызываете метод, кто исполняет инструкции?

Т.е. вы всерьез считаете, что объектов без классов быть не может? Центральная концепция ООП — объекты, посылающие друг другу сообщения. А механизм их инстанцирования — деталь реализации, далеко не всегда включающая в себя концепцию классов.

Здравствуйте, -VaS-, Вы писали:


VS>Т.е. вы всерьез считаете, что объектов без классов быть не может?
А вы всерьёз считаете, что на этой планете бывают вещи без названий и не относящиеся ни к какой категории? Пойди туда — не знаю куда, возьми то — не знаю что?

То, что в глуповатых недоязычках для школьников типа javascript нет классов, но есть объекты, не означает что классов нет по сути. Просто одновременно с объявлением объекта (по пьяне называемого функцией) постулируется одноименный класс. Да, выглядит алогично, чтобы не сказать — полный кретинизм.