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

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

А>В реальном проекте с ограниченным временем трудно объяснить руководству, что тебе нужно все переписать для того, чтобы исправить архитектуру: «Я тут потрачу еще столько же времени, сколько уже потратил, но в конце работы результат не будет отличаться от того, что сейчас».
А>Вряд ли какой-то менеджер это воспримет положительно. Поэтому первоначальная прототипная архитектура со всеми заплатками так и продолжает жить, а потом кто-то ее начинает использовать, и ее уже совсем становится невозможно поменять, так как надо обеспечивать обратную совместимость.
Во-первых, есть и нормальные менеджеры. Я даже двух таких знаю (а с одним из них сейчас работаю).
Во-вторых, менеджеров надо учить о образовывать, объяснять им что такое технический долг и чем он опасен.
В-третьих, если менеджер совсем упертый, то можно его не посвящать в такие тонкости производственного процесса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Знакомо.

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

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

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

Похоже, вы слишком запариваетесь насчет теории, определений и чистоты подхода.

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


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

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

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

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

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

T>Smalltalk/Python/Ruby-программисты неодобрительно смотрят на Steamus-а

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

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

Любой предмет мы относим к некоторому классу. Просто часть людей патологически не способна абстрагироваться. Это не в ваш адрес, это в адрес тех, кто изобретает всякие там раби, стараясь их лишить строгого описания абстракций. С другой стороны, может они и правы. Ибо тех кто видя стол, видит всегда конкретный стол, возможно и больше, чем тех, кто понимает, что есть абстрактная сущность "столы". Посему, если язык позиционируется на дилетантов (а раби такой язык, как и джаваскрипт), то в нём минимизируются любые абстракции. Народу так проще чухать. PHP — яркий пример.

А>Применяете ли вы альтернативные подходы к архитектуре (не ООП)?
Все применяют. Не все признаются, правда.

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

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

Зачем ООП чему-то противопоставлять или чем-то заменять? ООП отличный инструмент для организации алгоритмов в компоненты и модули, ну так и пусть себе организует алгоритмы в компоненты и модули. Взять, например, Немерле. Этот язык функциональный внутри метода и объектно-ориентированный вне метода и в нём функциональное и объектно-ориентированное программирование олично дополняют друг друга. Используются ли в нём другие парадигмы? Да по полной. Отменяет ли это использование ООП? Нет, какой смысл.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

D>Перефразируя старый анекдот,

D>

D>- 60 делится на все числа.
D>- На 17 не делится.
D>- Ну вот поэтому 17 и не является хорошим внятным числом.

D>Я не говорил про хорошесть или нехорошесть javascript. Я формально приводил контрпример к твоему "дожили млин", означающему, как я понимаю, отказ в несуществовании объектам без классов.

Я там ниже уже пояснил, что класс есть всегда. Его вводит наш мозг. Посему, если некий язык программирования явно не постулирует класс, то нужно просто поразмышлять где он постулируется неявно. В нашем мире любой реальный предмет как-то обзывается и сразу классифицируется. Если этого нет, то наш мозг не может им полноценно оперировать. Даже есди мы не можем классифицировать некий предмет, он всё равно классифицируется как "неклассифицируемый предмет"

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

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

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

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

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

Programming Paradigms for Dummies: What Every Programmer Should Know

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

IT>Зачем ООП чему-то противопоставлять или чем-то заменять? ООП отличный инструмент для организации алгоритмов в компоненты и модули, ну так и пусть себе организует алгоритмы в компоненты и модули. Взять, например, Немерле. Этот язык функциональный внутри метода и объектно-ориентированный вне метода и в нём функциональное и объектно-ориентированное программирование олично дополняют друг друга. Используются ли в нём другие парадигмы? Да по полной. Отменяет ли это использование ООП? Нет, какой смысл.

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

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

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

Да что там далеко ходить, вспомним про Rich Domain Model, в которой мы сначала создаем абстракцию, а потом стоически решаем создаваемые ею проблемы. Здесь, конечно, как на RSDN знают, можно спорить, но ведь Anemic Model, внешне являющаяся шагом в сторону от ООП, не просто так существует? Хотя я не очень хорошо разбираюсь в ORM и бизнес-программировании вообще, может, это и не лучший пример.

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

SICP книгу прочитать надо тебе, великого гения в тебе видим мы!

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

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

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

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

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


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

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

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

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

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

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

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

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

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

А>Нет, я мечтаю об 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."

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

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

Дело в том, что парадигма классов в ООП старше языков с прототипированием лет на тридцать. Вот она и поселилась плотно в голове, и выглядит незаменимой. Наверное в 80е сторонники процедурных ЯП так же фыркали на Симулу. Ничего, со временем привыкнете и оцените

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

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

Smalltalk/Python/Ruby-программисты неодобрительно смотрят на Steamus-а

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

D>>Я не говорил про хорошесть или нехорошесть javascript. Я формально приводил контрпример к твоему "дожили млин", означающему, как я понимаю, отказ в несуществовании объектам без классов.

S>Я там ниже уже пояснил, что класс есть всегда. Его вводит наш мозг. Посему, если некий язык программирования явно не постулирует класс, то нужно просто поразмышлять где он постулируется неявно. В нашем мире любой реальный предмет как-то обзывается и сразу классифицируется. Если этого нет, то наш мозг не может им полноценно оперировать. Даже есди мы не можем классифицировать некий предмет, он всё равно классифицируется как "неклассифицируемый предмет"

Проблема в том, что днем стул — это стул, а ночью — вешалка для рубашки. Вот и квалифицируй теперь этот предмет.

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

L>>Нет, не одноклассовые

S>Теоритически — да. Каждому можно назначить свой класс. Ну, скажем потому, что один стул на три грамма тяжелее другого. Против этого конечно не попрёшь. Но мозг потому и является мощным инструментом. Ибо, в зависимости от задачи, способен отбрасывать второстепенное детали и выявлять главные, и по ним классифицировать и далее оперировать классами. В принципе, если вы этого не выделили, то и дискутировать не имеет смысла. Куча людей цепляется к малозначащим деталям и не способна выявить общее. Не всем дано. Ничевострашного. И так живут.

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

Сэмулировать подобного рода поведение в статически-типизированном языке будет очень сложно. В отличии от...

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

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

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

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

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

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

Так а вы лично делали проекты, построенные без ООП?

Я вообще за свою жизнь видел два типа проектов: либо ООП, либо «макароны» — отсутствие какой-либо формальной методологии, просто группировка функций по гуманитарному принципу.

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

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

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

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

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

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

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

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

B>Похоже, вы слишком запариваетесь насчет теории, определений и чистоты подхода.

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

К тому же, архитектура в принципе нужна в основном для того, чтобы программист не запутался в коде, она непосредственно не служит для решения задачи. Поэтому идеальная архитектурная парадигма такая, в которой архитектура просто отсутствует вместе со всеми архитектурными проблемами. А ООП устроено так, что оно отбирает на себя очень много ресурсов, точнее, оно в этом плане не ограничено. Можно потратить бесконечно много времени на совершенствование архитектуры и последующее решение возникших вследствие этого проблем. ООП — это черная дыра, в которую проект может затянуть до срыва сроков и провала, плохо помогающая решать проблемы, зато хорошо создающая их. Как в известной шутке: «You have a problem and decide to use Java, now you have a ProblemFactory». На самом деле, это шутка не про джаву, а про ООП.

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

у каждой парадигмы есть область применения, универсальной парадигмы нет:

процедурный подход — низкоуровневое программирование железяк, драйверов, realtime, язык С, ассемблер

ООП — бизнес задачи, то есть программирование процессов более приближенных к реальному миру, чем программы для железяк, высокоуровневое программирование, Язык С#, java

декларативное программирование, функциональная парадигма — научные расчеты, сложные научные алгоритмы

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

IB>у каждой парадигмы есть область применения, универсальной парадигмы нет:

IB>процедурный подход — низкоуровневое программирование железяк, драйверов, realtime, язык С, ассемблер

IB>ООП — бизнес задачи, то есть программирование процессов более приближенных к реальному миру, чем программы для железяк, высокоуровневое программирование, Язык С#, java

IB>декларативное программирование, функциональная парадигма — научные расчеты, сложные научные алгоритмы
Когда-то и процедурное программирование было большим шагом вперед..
Ну, и есть еще логическое программирование. За область применения не скажу, но было бы хорошим дополнением ко всем парадигмам..

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


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

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

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

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

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

B>Декларативное, но слишком отличается от функционального. Я бы поставил его отдельно.

По моим представлениям одной из классификаций возможностей ЯП является классификация основанная, на том что описывает программа на этом языке:
либо последовательность действий, которые машина должна выполнить для получения результата, который задумал программист,
либо результат, в этом случае последовательность действий, которые машина должна выполнить для его получения, машина определяет сама

В первом случае это императивные языки, во втором декларативные. В свою очередь декларативные языки делятся по стилю формального описания результата: функции, логические предикаты и т. д.

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

IB>По моим представлениям одной из классификаций возможностей ЯП является классификация основанная, на том что описывает программа на этом языке:
IB>либо последовательность действий, которые машина должна выполнить для получения результата, который задумал программист,
IB>либо результат, в этом случае последовательность действий, которые машина должна выполнить для его получения, машина определяет сама

IB>В первом случае это императивные языки, во втором декларативные. В свою очередь декларативные языки делятся по стилю формального описания результата: функции, логические предикаты и т. д.
Хотелось бы поспорить, но не с чем

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

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

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

Здравствуйте, 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, Вы писали:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

(c)

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

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

Дожили млин.

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

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

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

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

Здравствуйте, 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..

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

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

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

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

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

KA>Дело в том, что парадигма классов в ООП старше языков с прототипированием лет на тридцать. Вот она и поселилась плотно в голове, и выглядит незаменимой. Наверное в 80е сторонники процедурных ЯП так же фыркали на Симулу. Ничего, со временем привыкнете и оцените

Парадигма классов имеет возраст первого человека/обезьяны начавшего мыслить.

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

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

Перефразируя старый анекдот,

- 60 делится на все числа.
— На 17 не делится.
— Ну вот поэтому 17 и не является хорошим внятным числом.

Я не говорил про хорошесть или нехорошесть javascript. Я формально приводил контрпример к твоему "дожили млин", означающему, как я понимаю, отказ в несуществовании объектам без классов.

D>отказ в несуществовании

*отказ в праве существования

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

S>Любой предмет мы относим к некоторому классу. Просто часть людей патологически не способна абстрагироваться. Это не в ваш адрес, это в адрес тех, кто изобретает всякие там раби, стараясь их лишить строгого описания абстракций. С другой стороны, может они и правы. Ибо тех кто видя стол, видит всегда конкретный стол, возможно и больше, чем тех, кто понимает, что есть абстрактная сущность "столы". Посему, если язык позиционируется на дилетантов (а раби такой язык, как и джаваскрипт), то в нём минимизируются любые абстракции.

Это вы зря. С абстракциями в руби как раз все очень хорошо. Причем именно благодаря отказу от статической типизации

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

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

S>>Любой предмет мы относим к некоторому классу. Просто часть людей патологически не способна абстрагироваться. Это не в ваш адрес, это в адрес тех, кто изобретает всякие там раби, стараясь их лишить строгого описания абстракций. С другой стороны, может они и правы. Ибо тех кто видя стол, видит всегда конкретный стол, возможно и больше, чем тех, кто понимает, что есть абстрактная сущность "столы". Посему, если язык позиционируется на дилетантов (а раби такой язык, как и джаваскрипт), то в нём минимизируются любые абстракции.

T>Это вы зря. С абстракциями в руби как раз все очень хорошо. Причем именно благодаря отказу от статической типизации

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

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

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

D>>>Я не говорил про хорошесть или нехорошесть javascript. Я формально приводил контрпример к твоему "дожили млин", означающему, как я понимаю, отказ в несуществовании объектам без классов.

S>>Я там ниже уже пояснил, что класс есть всегда. Его вводит наш мозг. Посему, если некий язык программирования явно не постулирует класс, то нужно просто поразмышлять где он постулируется неявно. В нашем мире любой реальный предмет как-то обзывается и сразу классифицируется. Если этого нет, то наш мозг не может им полноценно оперировать. Даже есди мы не можем классифицировать некий предмет, он всё равно классифицируется как "неклассифицируемый предмет"

L>Проблема в том, что днем стул — это стул, а ночью — вешалка для рубашки. Вот и квалифицируй теперь этот предмет.

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

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

L>>Проблема в том, что днем стул — это стул, а ночью — вешалка для рубашки. Вот и квалифицируй теперь этот предмет.

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

Нет, не одноклассовые

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

T>>Это вы зря. С абстракциями в руби как раз все очень хорошо. Причем именно благодаря отказу от статической типизации

S>Возможно. Я слабо знаком с раби. Но, по правде говоря, любой отказ от статической типизации меня смущает. И будет смущать ровно до тех пор, пока компы не научатся мыслить.

Это уже гораздо более адекватное объяснение вашей приверженности к статической типизации, чем отнесение всех "инакомыслящих" к категории (с) дилетантов.

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

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

L>>>Проблема в том, что днем стул — это стул, а ночью — вешалка для рубашки. Вот и квалифицируй теперь этот предмет.

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

L>Нет, не одноклассовые

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

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

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

L>>>Нет, не одноклассовые

S>>Теоритически — да. Каждому можно назначить свой класс. Ну, скажем потому, что один стул на три грамма тяжелее другого. Против этого конечно не попрёшь. Но мозг потому и является мощным инструментом. Ибо, в зависимости от задачи, способен отбрасывать второстепенное детали и выявлять главные, и по ним классифицировать и далее оперировать классами. В принципе, если вы этого не выделили, то и дискутировать не имеет смысла. Куча людей цепляется к малозначащим деталям и не способна выявить общее. Не всем дано. Ничевострашного. И так живут.

L>Если говорить чисто философски, то класс в действительности не является неизменным атрибутом объекта, он постоянно меняется как во времени, так и в зависимости от наблюдателя. Даже от состояния меняется — стол, который вчера назад был просто столом, будучи политым из ведерка ртути, переходит в категорию "опасный для жизни предмет, подлежащий утилизации".

L>Сэмулировать подобного рода поведение в статически-типизированном языке будет очень сложно. В отличии от...

Класс — это не понятие вселенной/бога. Класс — это инструмент мозга. Во вселенной все предметы уникальны. И их много. Бесконечно много. Так много, что наш мозг не способен держать в себе такое количество предметов. И мозг нашёл выход. Для того, что бы манипулировать окружающими сущностями для решения некоей задачи, наш мозг умеет абстрагироваться. То есть, грубо говоря, отсекать незначащие в контексте решения некой задачи детали. А по значащим деталям, объединять предметы в группы, называемые классами. Мозгу это нужно, ибо иначе он не справится с разнообразием и сложностью окружаещего мира. И вот этот подход мозга и есть ООП. Такие вот дела. Больше вдаваться в дискуссию я не буду. Кто хочет, тот сам поймет. Кто не хочет — будет цепляться к словам. Если кто-то полагает что его мозг не мыслит по принципам ООП, то так оно видимо и есть. Его — не мыслит. Раз не смог абстрагироваться и понять.

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

L>>Если говорить чисто философски, то класс в действительности не является неизменным атрибутом объекта, он постоянно меняется как во времени, так и в зависимости от наблюдателя. Даже от состояния меняется — стол, который вчера назад был просто столом, будучи политым из ведерка ртути, переходит в категорию "опасный для жизни предмет, подлежащий утилизации".

L>>Сэмулировать подобного рода поведение в статически-типизированном языке будет очень сложно. В отличии от...

S>Класс — это не понятие вселенной/бога. Класс — это инструмент мозга. Во вселенной все предметы уникальны. И их много. Бесконечно много. Так много, что наш мозг не способен держать в себе такое количество предметов. И мозг нашёл выход. Для того, что бы манипулировать окружающими сущностями для решения некоей задачи, наш мозг умеет абстрагироваться. То есть, грубо говоря, отсекать незначащие в контексте решения некой задачи детали. А по значащим деталям, объединять предметы в группы, называемые классами. Мозгу это нужно, ибо иначе он не справится с разнообразием и сложностью окружаещего мира.

Вы зачем эти банальности повторяете? Вы считаете, что это кому-то непонятно?

S>И вот этот подход мозга и есть ООП. Такие вот дела.

Да вот только речь-то не об ООП, а о статической типизации

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

Да, мы все знаем, что именно засчитывают за переход на личности.

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

L>Да вот только речь-то не об ООП, а о статической типизации

А другой типизации и не бывает. Трансляторы пока мыслить не научились. Динамическая типизация это не более чем понты. По сути разработчик просто говорит транслятору — назначь всякой моей переменной какой-нить свой универсальный класс гандон. И будет ООП объект! Мелкий гандон. Средний гандон. Крупный гандон. Смысла нет. Компу пофик, а парню приятно. Он терь — ООП пацан. Методы всех объектов ессно стандартны: надеть, снять, надуть, вдуть... ну и далее от фантазии. Другие особенности классов не осмысливались. Зато всё налету и в процессе. Динамически!

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

L>Сэмулировать подобного рода поведение в статически-типизированном языке будет очень сложно. В отличии от...

Сдаётся мне, что и в этих самых "от ..." это будет нифига не проще, а точно также невозможно.

В HL2 Ep1 (или Ep2) есть момент, когда Барни выдёргивает монтировку из механизма моста и подаёт её Фримену. В режиме прохождения с комментариями разработчиков эти самые разработчики рассказывают, что тут на самом деле три монтировки: одна в механизме, потом в определённый момент она исчезает и появляется другая, привязанная к положению руки Барни, ну и наконец, когда Фримен монтировку получает — это уже третья. Вот так вот. Для, казалось бы, тривиальнейшего действия — даже без изменения свойств объекта, без поливания его ртутью — такие совершенно непроходимо дикие хаки. А вы говорите — ООП, типизация, динамика... От динамики вашей польза возможна лишь в очень узком множестве сценариев. Да и в них, есть подозрение, гимору будет больше, чем пользы.

D>От динамики вашей польза возможна лишь в очень узком множестве сценариев.

Вот, например, приду я к пластическому хирургу и попрошу мне пришить второй член на грудь. Вроде бы, все ранее имевшиеся свойства и модели поведения остались при мне, а вот новое свойство новый член public Dick dick2 к классу Man добавить как-то надо.

D>Да и в них, есть подозрение, гимору будет больше, чем пользы.

Потому что на динамике человек не будет париться заводить под меня такого красивого отдельный класс, а присобачит новое свойство динамически. После чего, где бы он с этим классом Man ни работал, нигде ему IDE не подскажет, что у этого класса может быть ещё и член dick2. Что, во-первых, чревато опечатками в имени свойства, а во-вторых, если факт его наличия/отсутствия влияет на поведение класса (а такое козырное свойство будет влиять да ещё как! гыгы), то вообще пиши пропало.

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

D>В HL2 Ep1 (или Ep2) есть момент, когда Барни выдёргивает монтировку из механизма моста и подаёт её Фримену. В режиме прохождения с комментариями разработчиков эти самые разработчики рассказывают, что тут на самом деле три монтировки: одна в механизме, потом в определённый момент она исчезает и появляется другая, привязанная к положению руки Барни, ну и наконец, когда Фримен монтировку получает — это уже третья. Вот так вот. Для, казалось бы, тривиальнейшего действия — даже без изменения свойств объекта, без поливания его ртутью — такие совершенно непроходимо дикие хаки. А вы говорите — ООП, типизация, динамика... От динамики вашей польза возможна лишь в очень узком множестве сценариев. Да и в них, есть подозрение, гимору будет больше, чем пользы.

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

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

А>Пример интересный, но, я так подозреваю, неудачный. Как человек, занимающийся разработкой 3D-движка, могу сказать, что в компьютерной графике свои проблемы есть с объектами, дело не в ООП.

Удачный. В том смысле, что программирование (в т.ч. объектно-ориентированное) по убожеству своих возможностей бесконечно далеко от реального мира. Настолько далеко, что смешно даже говорить о моделировании реальных объектов и процессов реального мира. В 3D свои будут грабли, в других областях свои: ни полить стол ртутью, ни разломать стул и бросить в камин. Каждый раз придётся уничтожать старый инстанс и создавать новый, нового класса, с новыми свойствами. Как ту монтировку.

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

D>Удачный. В том смысле, что программирование (в т.ч. объектно-ориентированное) по убожеству своих возможностей бесконечно далеко от реального мира. Настолько далеко, что смешно даже говорить о моделировании реальных объектов и процессов реального мира. В 3D свои будут грабли, в других областях свои: ни полить стол ртутью, ни разломать стул и бросить в камин. Каждый раз придётся уничтожать старый инстанс и создавать новый, нового класса, с новыми свойствами. Как ту монтировку.

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

Вон в движке Unreal Engine сделали симуляции на GPU, и теперь весь мир ломается произвольно и очень реалистично.

Весь вопрос в мощности железа.

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

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

L>>Сэмулировать подобного рода поведение в статически-типизированном языке будет очень сложно. В отличии от...

D>Сдаётся мне, что и в этих самых "от ..." это будет нифига не проще, а точно также невозможно.

D>В HL2 Ep1 (или Ep2) есть момент, когда Барни выдёргивает монтировку из механизма моста и подаёт её Фримену. В режиме прохождения с комментариями разработчиков эти самые разработчики рассказывают, что тут на самом деле три монтировки: одна в механизме, потом в определённый момент она исчезает и появляется другая, привязанная к положению руки Барни, ну и наконец, когда Фримен монтировку получает — это уже третья. Вот так вот. Для, казалось бы, тривиальнейшего действия — даже без изменения свойств объекта, без поливания его ртутью — такие совершенно непроходимо дикие хаки. А вы говорите — ООП, типизация, динамика...

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

D>От динамики вашей польза возможна лишь в очень узком множестве сценариев. Да и в них, есть подозрение, гимору будет больше, чем пользы.

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

А это зависит от того, что считается "ООП", а что — уже нет.

По мне, так темплейты Си++ — это НЕ ООП. Это метапрограммирование, и главное отличие от ООП — полиморфизм не run-time, а compile-time. Объекты by value, а не by reference.

Процедурный подход, конечно, неизбежно приведет к повторному изобретению ООП "на коленке". Такие вещи, как стратегии и декораторы, придется делать через указатели на функции и PVOID Context что есть то же ООП. Пример — файловые системы в UNIXах с тамошней "struct vnodeops". Конечно, BSD написана задолго до осмысления ООП, а Линукс — в годы младенчества ООП, но таки данная архитектура — объектная.

Помимо ООП и "мета", назову еще парадигму из кучи скриптовых языков от Питона до PowerShell, где есть богатые средства использования контейнеров/множеств даже не by value (это и в "мета" стиле есть "до кучи"), а _временных значений контейнерных типов_.

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