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

А>Применяете ли вы альтернативные подходы к архитектуре (не ООП)? Если да, то поделитесь, пожалуйста, ссылками (книги, статьи, код), позволяющими понять, как это реально работает.

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

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

0>Ты мечтаешь об идеальном BDUF-е. Однако этот метод исходит из того, что в момент проектирования ты обладаешь полной информацией о том, как что ты реализуешь в своей программе.
0>Это работает в двух случая: при написании небольших и тривиальных программ (по типу студенческих курсовых), или при написании программ аналогичным тем, которые ты уже раньше писал.

Нет, я мечтаю об NDAA: No Design At All — безархитектурное программирование.

Даже больше, я мечтаю об HPOCP: A Huge Pile of Code Programming — бесструктурное программирование, без классов, модулей, структур данных и функций, ты просто вписываешь код куда-то, а некая продвинутая система навигации по коду, анализа и выборки позволяет тебе в нем легко ориентироваться. Правда не знаю, возможно ли это вообще.

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

А>Нет, я мечтаю об NDAA: No Design At All — безархитектурное программирование.
В принципе, если речь идет о небольших программах, которые ещё и не надо будет поддерживать, то там можно и без совсем архитектуры обойтись.

А>Даже больше, я мечтаю об HPOCP: A Huge Pile of Code Programming — бесструктурное программирование, без классов, модулей, структур данных и функций, ты просто вписываешь код куда-то, а некая продвинутая система навигации по коду, анализа и выборки позволяет тебе в нем легко ориентироваться. Правда не знаю, возможно ли это вообще.
Вопрос: а как ты понимаешь, что такое архитектура программы и зачем она вообще нужна?
С какой целью проводится работа над архитектурой?

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

0>Вопрос: а как ты понимаешь, что такое архитектура программы и зачем она вообще нужна?
0>С какой целью проводится работа над архитектурой?

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

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

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

А>Применяете ли вы альтернативные подходы к архитектуре (не ООП)? Если да, то поделитесь, пожалуйста, ссылками (книги, статьи, код), позволяющими понять, как это реально работает.

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

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

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

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

p.s. Не, можно и сознание порасширять всякими травками порошочками. Программировать лучше не станешь, но тебе и так будет хорошо

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

S>ООП, это не модная придумка программеров, ООП — это способ, которым человеческий мозг декомпозирует окружающую действительность. Он, мозг, так устроен. Такова его изначальная природа. Это вообще не имеет отношения к компьютерам.
S>Чудаки, которые пытаются этот факт игнорировать, просто неумные умники. С таким уже успехом можно пытаться есть носом или нюхать ухом. Другими словами, когда люди осознали как работает мозг, они попытались максимально плотно подстроить технологии проектирования под эти особенности работы мозга. Вот собсно и всё. Сформировался ООП подход. Других вариантов нет.

Откуда такие сведения? Можно согласиться с тем, что человеческое сознание оперирует понятиями, а не объектами. Например, «стол» — это понятие, вы не имеете в виду конкретный стол (объект) под этим словом, но понимаете, о чем идет речь, так как понятие «стол» выражает некое усредненное представление о множестве конкретных столов самых различных форм и видов. ООП пытается спроецировать систему понятий на систему объектов в языке программирования, иногда это частично получается, именно поэтому ООП иногда кажется таким интуитивным, но, как правило, конечно же, это невозможно, так как одна и та же система понятий может быть представлена множеством соответствующих ей систем объектов языка программирования, в зависимости от задачи или требований эффективности, а также благодаря ограниченности представления, так как языки программирования вроде C# не рассчитаны на представление онтологий. Например, если вы попытаетесь представить понятие «стол» объектом в языке программирования, вы непременно потерпите фиаско, так как понятие не позволяет вам определить конкретные свойства и функции объекта. Какой именно стол? Деревянный, каменный, металлический, стеклянный, складной, приставной, какого цвета, сколько у него ножек, какие функции он может выполнять? Все это зависит от конкретной задачи, от конкретных требований, но отсюда следует вывод, что соответствие между понятием «стол» и классом «стол» всегда будет неполноценным. Мы никогда не сможем в рамках существующих ООП языков отобразить онтологию на систему классов, отсюда я и делаю вывод о врожденной несостоятельности ООП.

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

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

Ты слишком буквально воспринимаешь термин ООП, точнее первую 'О' в нём. В программировании вообще довольно много несуразностей в названиях и аббревиатурах, видимо потому что это ещё довольно молодая инженерная дисциплина. Ценность ООП не в том, что он якобы эмулирует реальный мир (это как раз полный бред, на котором не стоит долго заморачиваться), а в том, что ООП даёт нам модульность и компонентность. API любой современной библиотеки, любого приложения сегодня немыслим без ООП. ООП — это средство декомпозиции больших сложных систем и больше ничего. В этом его ценность и суть.

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

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

S>>ООП, это не модная придумка программеров, ООП — это способ, которым человеческий мозг декомпозирует окружающую действительность. Он, мозг, так устроен. Такова его изначальная природа. Это вообще не имеет отношения к компьютерам.
S>>Чудаки, которые пытаются этот факт игнорировать, просто неумные умники. С таким уже успехом можно пытаться есть носом или нюхать ухом. Другими словами, когда люди осознали как работает мозг, они попытались максимально плотно подстроить технологии проектирования под эти особенности работы мозга. Вот собсно и всё. Сформировался ООП подход. Других вариантов нет.

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

ООП проецирует систему понятий на систему КЛАССОВ в языке программирования. Хорошо или плохо это получается зависит от проектировщика и задачи. Равно как и в жизни. Если мозг не сталкивался с некоей проблемной областью, его классификация часто будет ошибочной. Но это не недостаток ООП, это недостаток информации/фактов. Как правило на классы можно положить любую систему понятий. Детальность такого отображения определяется решаемой задачей.


А>Например, если вы попытаетесь представить понятие «стол» объектом в языке программирования, вы непременно потерпите фиаско, так как понятие не позволяет вам определить конкретные свойства и функции объекта.

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

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

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

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

1) для описания онтологий, то есть формализованных систем понятий, существуют специальные языки вроде OWL, и обычные языки программирования Java, C# и С++ к языкам описания онтологий не относятся и, видимо, плохо подходят для этой задачи, раз их для этого не используют;

2) сама по себе задача составления онтологии спорна, то есть даже при наличии идеального языка описания онтологии у нас будут проблемы с однозначным, непротиворечивым и достаточно полным формальным описанием реального мира (точнее, предметной области);

3) классы в типичном объектном языке программирования можно соединять только отношением «is-a» (наследование), которое является лишь одним из всех возможных отношений между понятиями. Например, в известной «Circle-ellipse problem» многие программисты ошибочно соединяют окружность и эллипс отношением наследования в одну или другую сторону, так как «окружность является частным случаем эллипса» или «эллипс является расширением функциональности по отношению к окружности». Но отношение «является частным случаем» — это не отношение наследования, оно лишь означает, что экземпляры класса «эллипс», у которых радиусы равны, являются окружностями. В языках вроде Java, C# и С++ просто нет способа выразить такое отношение (хотя, возможно, есть какой-то обходной путь);

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

5) классы в языке программирования привязывают конкретную реализацию к понятию, что в будущем создает логические противоречия при использовании понятия, описываемого этим классом в другом контексте. Например, типичный класс String в языках программирования, описывающий строку символов, обычно содержит одну конкретную реализацию строки, например, с завершающим нулевым символом, и для «строки» в другом контексте, например, строки символов в бинарном файле на диске, приходится делать совершенно другую реализацию с другим интерфейсом. Мне кажется, что это не просто проблема проектирования, а фундаментальная проблема, так как современные объектные языки просто не позволяют описывать понятия настолько абстрактно, чтобы можно было действительно сопоставить понятие и класс. Здесь важную роль играет эффективность кода, например, вряд ли кто-то будет делать общий абстрактный интерфейс для работы со строкой в оперативной памяти и на диске — слишком разные требования, это может слишком существенно повлиять на производительность программы. Возможно, все-таки, это не фундаментальная проблема ООП, а лишь проблема современных объектных языков;

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

7) поскольку отображение понятий предметной области на классы всегда ограничено, оно меняется при изменении требований к программе, причем может меняться очень сильно, что приводит к большим трудозатратам и проблемам в будущей поддержке, то есть затраты на поддержание корректной модели предметной области могут быть очень высокими, на практике это приводит к тому, что со временем модель «расползается» и наполняется компромиссами и логическими ошибками.

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

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

IT>Ты слишком буквально воспринимаешь термин ООП, точнее первую 'О' в нём. В программировании вообще довольно много несуразностей в названиях и аббревиатурах, видимо потому что это ещё довольно молодая инженерная дисциплина. Ценность ООП не в том, что он якобы эмулирует реальный мир (это как раз полный бред, на котором не стоит долго заморачиваться), а в том, что ООП даёт нам модульность и компонентность. API любой современной библиотеки, любого приложения сегодня немыслим без ООП. ООП — это средство декомпозиции больших сложных систем и больше ничего. В этом его ценность и суть.

Да, но ведь весь вопрос и заключается в том, как выполнять эту декомпозицию. Скорее всего, ООП и не подразумевает того, чтобы проецировать систему понятий на классы, но именно к этому оно подталкивает, это наиболее интуитивный способ использования ООП, в этом его преимущество как средства, повышающего понятность кода и API, и так его фактически использует и понимает большинство программистов. Возможно, именно такой способ использования ООП как «проекции понятий на классы» и является порочным, и создает проблемы, так как ООП не может решить эту задачу, оно для этого не предназначено. Классы действительно не должны ассоциироваться с понятиями, а должны определяться формально по функциональности (по «обязанностям»), а имена классов, которые вызывают ассоциации с понятиями — вторичны. Да, в общем, надо будет мне поработать в этом направлении.

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

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

А>Применяете ли вы альтернативные подходы к архитектуре (не ООП)? Если да, то поделитесь, пожалуйста, ссылками (книги, статьи, код), позволяющими понять, как это реально работает.

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

Одним из способов описания онтологий является диаграмма классов из UML.

Вообще, модель это максимально упрощенное представление реальности подходящее для решения задачи. Если мне для решения задачи достаточно знать ширину и длину стола для подсчета количества персон, это одна модель. Если я хочу делать расчет стоимости изготовления стола — совсем другая. Хотя объект реальности один и тот же.

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

А>1) для описания онтологий, то есть формализованных систем понятий, существуют специальные языки вроде OWL, и обычные языки программирования Java, C# и С++ к языкам описания онтологий не относятся и, видимо, плохо подходят для этой задачи, раз их для этого не используют;

Java, C# и С++ предназначены для решения промышленных задач автоматизации. Зафиксированный ими код должен быть преобразован и выполняться на существующих вычислительных мощностях. Если говорить о формальной научной фиксации знаний в исследованиях на темы классификаций, онтологий, таксономий, то наверное можно использовать в чём-то более простые и наглядные языки описательного толка.

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

Видимо да, но спорность задачи онтологии есть скорее философская проблема классификации, и она не есть следствие ООП подхода к проектированию.

А>3) классы в типичном объектном языке программирования можно соединять только отношением «is-a» (наследование), которое является лишь одним из всех возможных отношений между понятиями. Например, в известной «Circle-ellipse problem» многие программисты ошибочно соединяют окружность и эллипс отношением наследования в одну или другую сторону, так как «окружность является частным случаем эллипса» или «эллипс является расширением функциональности по отношению к окружности».

В типичном объектном языке программирования конечно же можно соединять классы и отношением has-a (агрегирование). Достаточно всего лишь объявить атрибут некоего типа (указатель, ссылку на объект некоего типа). . Скажу больше — ООП подход к проектированию абсолютно не требует использования ОО-языков для реализации. Это просто удобно. Но вы также можете кодировать задачу на ассемблере или SQL, эмулируя теже зависимости. Тот факт, что проблема окружности/эллипса отмечена, подтверждает то, что мозг пытается классифицировать и абстрагироваться, но натыкается на логическое противоречие. ОО-языки позволяют зафиксировать любой из подходов которые примет мозг. Язык это лишь инструмент фиксации работы мозга.

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

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

А>5) классы в языке программирования привязывают конкретную реализацию к понятию, что в будущем создает логические противоречия при использовании понятия, описываемого этим классом в другом контексте. Например, типичный класс String в языках программирования, описывающий строку символов, обычно содержит одну конкретную реализацию строки, например, с завершающим нулевым символом, и для «строки» в другом контексте, например, строки символов в бинарном файле на диске, приходится делать совершенно другую реализацию с другим интерфейсом. Мне кажется, что это не просто проблема проектирования, а фундаментальная проблема, так как современные объектные языки просто не позволяют описывать понятия настолько абстрактно, чтобы можно было действительно сопоставить понятие и класс. Здесь важную роль играет эффективность кода, например, вряд ли кто-то будет делать общий абстрактный интерфейс для работы со строкой в оперативной памяти и на диске — слишком разные требования, это может слишком существенно повлиять на производительность программы. Возможно, все-таки, это не фундаментальная проблема ООП, а лишь проблема современных объектных языков;

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

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

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

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

Опять же — всё так. Но в случае с другими подходами всё ещё хуже.

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

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

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

А>Да, но ведь весь вопрос и заключается в том, как выполнять эту декомпозицию. Скорее всего, ООП и не подразумевает того, чтобы проецировать систему понятий на классы, но именно к этому оно подталкивает, это наиболее интуитивный способ использования ООП, в этом его преимущество как средства, повышающего понятность кода и API, и так его фактически использует и понимает большинство программистов. Возможно, именно такой способ использования ООП как «проекции понятий на классы» и является порочным, и создает проблемы, так как ООП не может решить эту задачу, оно для этого не предназначено. Классы действительно не должны ассоциироваться с понятиями, а должны определяться формально по функциональности (по «обязанностям»), а имена классов, которые вызывают ассоциации с понятиями — вторичны. Да, в общем, надо будет мне поработать в этом направлении.

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

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


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

Можно подумать, Вы первый с этим сталкиваетесь. Это не проблема ООП, это сложность и ,видимо, специфичность предметной области плюс
навыки архитектора и разработчика.

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

S>Упрощённо говоря, когда вы упрощаете работу плотника, то помимо сущностей типа дерево, доска, стена, планка, вы также используете инструментальные сущности — молоток, пила, гвозди, которых изначально не было в предмете обработки.

Это всё тоже сущности реального мира. Вот примерчик получше будет:

- ...И ещё они рисовали всё, что начинается на М: мышеловки, мальчишек, мишек, мотыльков, математиков, множества. Ты когда-нибудь видела, как рисуют множества?
— Множества чего?
— А ничего, просто множества.

(c)

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

А>Нет, я мечтаю об NDAA: No Design At All — безархитектурное программирование.

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

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

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

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

А>Например, если вы попытаетесь представить понятие «стол» объектом в языке программирования

..., то вы занимаетесь ерундой. Синклер как то одну фразу выдал: ООП это не про данные, ООП это про поведение. Как только мы начинаем следовать этому принципу, все якобы несуразности ООП сразу исчезают.

А> Все это зависит от конкретной задачи, от конкретных требований, но отсюда следует вывод, что соответствие между понятием «стол» и классом «стол» всегда будет неполноценным.

Неверный вывод. Правильный — не нужно никаких левых, бесполезных для решения задачи соответствий городить.

А>отсюда я и делаю вывод о врожденной несостоятельности ООП.

Знакомо.

S>ООП проецирует систему понятий на систему КЛАССОВ в языке программирования.

Нет. ООП — это про объекты и их взаимодействие (причем, именно последнее — суть ООП), а не про классы. И объекты — это не "экземпляры классов", как убедительно врет нам таварищ Мейер.

Alan Kay:

"OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them."