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

Programming Paradigms for Dummies: What Every Programmer Should Know

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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