Началось все с
Деструкторы — плохо, используйте явное освобождение ресурсов
Конструкторы — плохо, используйте фабрики, прячьте конструкторы в private
Множественное наследование — плохо
Наследование — всегда плохо, используйте агрегацию и интерфейсы
Интерфейсы со множеством вызовов — плохо, используйте интерфейсы с одним
* сюрприз, почти такие интерфейсы в Си с самого начала, при определении любой функции она приводится к указателю с типизированными параметрами прямо из коробки, только к этому "интерфейсу" еще this в качестве параметра надо добавить — вот уже почти современное ООП. Но инкапсуляция будет нарушена.
А инкапсуляция тоже не всегда хорошо. Когда тесты на какой то участок кода пишутся, нужно состояние окружения подменять на входе, а на выходе тестировать что оно изменилось в нужное. Т.е. и состояние тестируемого объекта и состояния объектов с которыми он взаимодействуют нужно устанавливать независимо от штатных методов объектов — жесткое нарушение инкапсуляции, и потом лезть во внутрь объекта за состоянием — тоже жестко нарушая инкапсуляцию. Состояние это вообщем-то все поля объекта.
Инкапсуляция — плохо для ТДД
* то что состояние this в Си-шных реализациях ООП легко отделимо от методов это то что надо для тестов
PS.
Итого, если код в более менее хорошей архитектуре, покрыт тестами, компилируется быстро и быстро работает — это по-прежнему код на СИ.
Когда ваш компилятор подвиснет в очередной раз на пару минут, задумайтесь над этим
"Будет никак" — это значит, что вы надеятесь, что с этой темой (которая по ссылке) ничего не будет. Если вы надеятесь, что с вашей темой будет по-другому, чем с темой по ссылке, это пишется "будет не как". Через "е" и раздельно.
Что до самой темы по ссылке, то она, на мой взгляд, недостаточно раскрыта.
C>Итого, если код в более менее хорошей архитектуре, покрыт тестами, компилируется быстро и быстро работает — это по-прежнему код на СИ. C>Когда ваш компилятор подвиснет в очередной раз на пару минут, задумайтесь над этим
По-разному бывает. Бывает даже так, что код нифига не покрыт тестами, а все равно, работает, собака.
У вас топик для потрындеть Философии ПО, как мне кажется.
Сферический ООП в вакууме никакого прикладного применения не имеет (статьи и конференции за полезный выхлоп не считаем), т.е. в этом разделе точно оффтопик.
Если уточнить вопрос до конкретного языка / фреймворка, то внезапно окажется, что в каждом конкретном случае все актуальные грабли уже давно известны и обойдены.
Начните с конкретных примеров, или голосуйте за снести в философию — присоединюсь.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Current, Вы писали:
C>>Надеюсь, будет никак с этой темой: C>>http://rsdn.ru/forum/trash/6091539.1
Pzz>"Будет никак" — это значит, что вы надеятесь, что с этой темой (которая по ссылке) ничего не будет. Если вы надеятесь, что с вашей темой будет по-другому, чем с темой по ссылке, это пишется "будет не как". Через "е" и раздельно.
а как же устойчивые "никак с этим не связан" и "никак не похоже на"
S>У вас топик для потрындеть Философии ПО, как мне кажется.
S>Сферический ООП в вакууме никакого прикладного применения не имеет (статьи и конференции за полезный выхлоп не считаем), т.е. в этом разделе точно оффтопик.
А также сферический DDD, TDD, BDD и другие модные слова? Не согласен.
Все таки в них обсуждаются общие принципы построения кода, по крайней мере для императивных языков. А это и есть архитектура.
S>Если уточнить вопрос до конкретного языка / фреймворка, то внезапно окажется, что в каждом конкретном случае все актуальные грабли уже давно известны и обойдены.
Тогда тема будет перенесена в обсуждение этого фреймворка и его граблей.
Здравствуйте, Current, Вы писали:
>>Сферический ООП в вакууме никакого прикладного применения не имеет (статьи и конференции за полезный выхлоп не считаем), т.е. в этом разделе точно оффтопик. C>А также сферический DDD, TDD, BDD и другие модные слова? Не согласен.
Ну, это ваши проблемы.
DDD хорош в своей теоретической части, которая про анализ требований и построение биз-архитектуры. Вторую половину — про натягивание кода на паттерны — всерьёз воспринимать невозможно.
TDD/BDD без соответствующей инструментальной обвязки вообще годятся только для буллшит-бинго. Но это снова оффтоп.
C>Все таки в них обсуждаются общие принципы построения кода, по крайней мере для императивных языков. А это и есть архитектура.
1. Нет никаких общих принципов в прикладной разработке. Точнее они есть, но пользы от них — только чтоб свою терминологию для каждого языка не изобретать.
2. Общие принципы и архитектура ПО — ортогональные понятия.
Блин, да даже банальный if в отдельных языках вынуждает городить костыли, что уж про более сложные вещи говорить?
Здравствуйте, Sinix, Вы писали:
S>Здравствуйте, Current, Вы писали:
>>>Сферический ООП в вакууме никакого прикладного применения не имеет (статьи и конференции за полезный выхлоп не считаем), т.е. в этом разделе точно оффтопик. C>>А также сферический DDD, TDD, BDD и другие модные слова? Не согласен. S>Ну, это ваши проблемы.
Ваши.
S>DDD хорош в своей теоретической части, которая про анализ требований и построение биз-архитектуры. Вторую половину — про натягивание кода на паттерны — всерьёз воспринимать невозможно. S>TDD/BDD без соответствующей инструментальной обвязки вообще годятся только для буллшит-бинго. Но это снова оффтоп.
C>>Все таки в них обсуждаются общие принципы построения кода, по крайней мере для императивных языков. А это и есть архитектура. S>1. Нет никаких общих принципов в прикладной разработке. Точнее они есть, но пользы от них — только чтоб свою терминологию для каждого языка не изобретать.
Может вам нечего тогда делать в форуме Архитектура ПО?
Здравствуйте, Current, Вы писали:
C>Деструкторы — плохо
деструкторы это и хорошо и плохо
C>Конструкторы — плохо
конструкторы это и хорошо и плохо
C>Множественное наследование — плохо
множественное наследование это и хорошо и плохо
C>Наследование — всегда плохо
наследование и хорошо и плохо
C>Интерфейсы со множеством вызовов — плохо
интерфейсы со множеством вызовов это и хорошо и плохо
разработка ПО это инженерия, т.е. поиск технического компромисса между противоричивыми требованиями/инструментами/решениями в определённом контексте. Так как каждый проект в той или иной степени уникален, то универсального "это хорошо" а "вот это плохо", существующего для всех типов проектов нет и быть не может. Единственное что может быть общим — это наличие здравого смысла и обоснованность принятия решений.
Здравствуйте, Current, Вы писали:
C>Надеюсь, будет никак с этой темой:
У тебя не критика ООП, у тебя критика конкретного способа его готовить.
Я, кстати, с таким способом приготовления на практике не встречался, так что подозреваю, что это синтетический конструкт чисто для дискуссии.
Здравствуйте, Current, Вы писали:
S>>1. Нет никаких общих принципов в прикладной разработке. Точнее они есть, но пользы от них — только чтоб свою терминологию для каждого языка не изобретать. C>Может вам нечего тогда делать в форуме Архитектура ПО?
Мягко говоря, странный вывод
S>>>1. Нет никаких общих принципов в прикладной разработке. Точнее они есть, но пользы от них — только чтоб свою терминологию для каждого языка не изобретать. C>>Может вам нечего тогда делать в форуме Архитектура ПО? 0>Мягко говоря, странный вывод
Ну да, он даже завсегдатый. И широкая публика тут того же мнения.
Читали "страна слепых"? Вот про форум Архитектура ПО у меня сейчас тоже мнение.
Архитектура ПО к языку это как более высокий уровень сетевой модели над более низким.
Низкий может чего-то неподдержать, но большинстиво языков поддерживает большинство архитектур.
Программы переписываются с java <-> c++ <-> c <-> perl <-> php <-> и т.д. без смены архитектуры
Не касательно вопроса зачем, просто сам факт программы можно переписывать на другой язык сохраняя не только функциональность, но и внутреннюю структуру.
Это примерно как IP все равно, будет ли внизу Ethernet, PPP или IEEE 802.11n.
Не настолько гладко, но все равно намного ближе к правде, чем та демагогия про нет "пользы от общих принципов" которую тут развели.
A>разработка ПО это инженерия, т.е. поиск технического компромисса между противоричивыми требованиями/инструментами/решениями в определённом контексте. Так как каждый проект в той или иной степени уникален, то универсального "это хорошо" а "вот это плохо", существующего для всех типов проектов нет и быть не может. Единственное что может быть общим — это наличие здравого смысла и обоснованность принятия решений.
У разрабочика цель довольно конкретная — отразить логику в коде. Если контекст требований про который ты говоришь задается прикладной областью, то я не очень понимаю где дилема — если делать сервер кафе мороженного то множественное наследование хорошо, а в gui булочной публичные конструкторы это здорово?
Если контекст в тех.окружении то, да бывает, но и там на 10 исключений 100500 общих принципов.
Здравствуйте, Current, Вы писали:
C>Здравствуйте, Pzz, Вы писали:
Pzz>>Здравствуйте, Current, Вы писали:
C>>>Надеюсь, будет никак с этой темой: C>>>http://rsdn.ru/forum/trash/6091539.1
Pzz>>"Будет никак" — это значит, что вы надеятесь, что с этой темой (которая по ссылке) ничего не будет. Если вы надеятесь, что с вашей темой будет по-другому, чем с темой по ссылке, это пишется "будет не как". Через "е" и раздельно.
C>а как же устойчивые "никак с этим не связан" и "никак не похоже на"
C>если "не", то "не так как с этой темой"
Здесь само предложение некорректно составлено. Должно быть примерно так: Надеюсь, будет не так, как с темой (ссылка на тему).
Здравствуйте, Current, Вы писали:
C>Не настолько гладко, но все равно намного ближе к правде, чем та демагогия про нет "пользы от общих принципов" которую тут развели. C>Не видишь пользы? сиди в другом форуме
Я вижу пользу от процесса разработки и реализации архитектуры для некоторых проектов, но не вижу, как твои рассуждения об "общих принципах" с этим связаны, и как они могут быть полезны. И в этом я вижу большую проблему у многих архитекторов, с которыми мне приходилось иметь дело — они очень много рассуждали о принципах, а результатом их работы становился пшик.
0>Я вижу пользу от процесса разработки и реализации архитектуры для некоторых проектов, но не вижу, как твои рассуждения об "общих принципах" с этим связаны, и как они могут быть полезны.
Мои рассуждения в начале топика. По существу мне никто не ответил, поэтому тема безвозвратно скатилась в трепло о жизни.
0>И в этом я вижу большую проблему у многих архитекторов, с которыми мне приходилось иметь дело — они очень много рассуждали о принципах, а результатом их работы становился пшик.
Программисты без архитектора делают код в архитектуре "из г. и палок", которую они на словах ругают,
но если быть честными, ей несказанно рады — вначале подпирают новыми палками, потом чтобы палки не падали, обмазывают хот фиксами
и так по кругу, деньги идут, программисты довольны, а когда им нанимают архитектора,
занимаются саботажем разной степени наглости, пока архитектора не уволят за то, что он "демотивировал" команду
мне это напоминает детский стишок
"ох и трудная это работа из болота тащить бегемота"
на первый взгляд трудно, потому что бегемот тяжелый и болото вязкое
но главная проблема в том, что бегемот живет в болоте, ему там нравится, его там дом родной,
и вылазить он категорически не хочет, а когда восьмитонная свинья не хочет ..., а когда их целый отдел ...
даже если какой-то герой их и вытащит, при первой же возможности сбегут в "г. и палки" обратно
Здравствуйте, Current, Вы писали:
C>Мои рассуждения в начале топика. По существу мне никто не ответил, поэтому тема безвозвратно скатилась в трепло о жизни.
Ты опоздал с подобной темой. Объектная истерия уже прошла, такие топики уже не вызывают большого отклика у аудитории.
C>Программисты без архитектора делают код в архитектуре "из г. и палок", которую они на словах ругают,
К сожалению, с архитектором они тоже часто делают говно. Разница только в том, что в этом случае говно ажурное.
То есть формально всё на месте — модули, интерфейсы, микросервисы всякие, а счастья — нет
C>но если быть честными, ей несказанно рады — вначале подпирают новыми палками, потом чтобы палки не падали, обмазывают хот фиксами C>и так по кругу, деньги идут, программисты довольны, а когда им нанимают архитектора, C>занимаются саботажем разной степени наглости, пока архитектора не уволят за то, что он "демотивировал" команду
Ты о каких-то конкретных программистах говоришь?
C>>Мои рассуждения в начале топика. По существу мне никто не ответил, поэтому тема безвозвратно скатилась в трепло о жизни. 0>Ты опоздал с подобной темой. Объектная истерия уже прошла, такие топики уже не вызывают большого отклика у аудитории.
Ну инкапсуляцию методов и данных, на которую был наезд, используют и хвалят 99.9%
C>>но если быть честными, ей несказанно рады — вначале подпирают новыми палками, потом чтобы палки не падали, обмазывают хот фиксами C>>и так по кругу, деньги идут, программисты довольны, а когда им нанимают архитектора, C>>занимаются саботажем разной степени наглости, пока архитектора не уволят за то, что он "демотивировал" команду 0>Ты о каких-то конкретных программистах говоришь?
Хуже, это сейчас тренд у менеджеров — "не берите в команду архитектора, он может демотивировать ребят".
Что еще хуже, этот совет практичен. Менеджеров "г. и палки" как правило тоже устраивают.
Здравствуйте, Current, Вы писали:
C>Что еще хуже, этот совет практичен. Менеджеров "г. и палки" как правило тоже устраивают.
Нужно понимать, что прямой корреляции между качеством архитектуры и прибыльностью проекта нет.
Более того, часто бывает так, что пока архитектор парит в эмпиреях ака "тут одного рефакторинга на пару человеколет", беспринципный внедренец быстренько втыкает очередную палку, обмазывает очередным г., и разблокирует сделку на $300k.
Я такого навидался. Когда софт проектируется не с нуля, и внезапно появляются задачи типа "а вот давайте добавим в магазин валидацию телефонного номера покупателя на предмет отсутствия задолженности по счетам", то архитектурно-правильные решения типа "оооо, ну давайте добавим ещё один тип плагинов в нашу систему автоматизации бизнеса, реализуем плагин по проверке номера, выставим интерфейсы для магазина, и допилим магазин, чтобы он пользовался этими интерфейсами" тупо вылетают за пределы окупаемости. А решение "давайте вкрячим вызов javascript-залипухи в кастомизацию шаблона отображения странички чекаута" опытный ниндзя может прикрутить прямо на глазах изумлённого заказчика. Это, конечно, потом больно бьёт в майнтенансе, но деньги заказчик платит сейчас, а маинтенанс будет когда-то потом.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
