Здравствуйте, 0x7be, Вы писали:
А>>ООН = Объектно Ориентированные Нагромождения 0>Плохому программисту и парадигма мешает.
Нагромождать не мешают ни парадигмы, ни их отсутствие.
Здравствуйте, samius, Вы писали:
0>>Плохому программисту и парадигма мешает. S>Нагромождать не мешают ни парадигмы, ни их отсутствие.
Конечно. Но чтобы начало получаться не нагромождать обычно надо хорошо и довольно длительно понапрягаться.
А обвинить во всем плохой язык, ООП, паттерны и парадигмы гораздо проще
Здравствуйте, robin_of_the_wood, Вы писали:
S>>Нагромождать не мешают ни парадигмы, ни их отсутствие.
___>Конечно. Но чтобы начало получаться не нагромождать обычно надо хорошо и довольно длительно понапрягаться.
Я бы сказал что при одинаковой степени и длительности напряжения итоги могут быть разные и оцениваются они субъективно. ___>А обвинить во всем плохой язык, ООП, паттерны и парадигмы гораздо проще
да, сложнее перестать нагромождать после смены языка и парадигмы )
Еще Объектно Ориентированные Нагромождения получаются когда программист хочет выпендрится.
Выпендриваются из-за честолюбия и\или страха, что коллеги сочтут низкоквалифицированным, если решение будет слишком простое.
Отвечайте на это сообщение, только если у Вас хорошее настроение и в Вашем ответе планируются только конструктивные вопросы и замечания http://rsdn.ru/Info/rules.xml
Здравствуйте, Аноним, Вы писали: А>ООН = Объектно Ориентированные Нагромождения
основной принцип разработки сложной фигни это разделение на части
ООП помогает разделять
кому-то кажется что нагромождение гавна это ООП. это не так
Здравствуйте, __kot2, Вы писали:
>основной принцип разработки сложной фигни это разделение на части >ООП помогает разделять
Каким образом?
>кому-то кажется что нагромождение гавна это ООП. это не так
Весьма обоснованное предположение. Почему объектно-ориентированное программирование провалилось? (извиняюсь за боян).
>это не так
Это ещё надо доказать.
Здравствуйте, nullxdth, Вы писали: >>основной принцип разработки сложной фигни это разделение на части >>ООП помогает разделять N>Каким образом?
задача разработки качественного ПО в срок сейчас решена.
это не проблема. это не гадание. это так же просто, как приготовить обед. огромную долю успеха в решении этой задачи занимает ООП.
да, возможно есть другие какие-то тоже рабочие способы разработки. но они мало кому интересны.
если вы все еще считаете, что в разработке по много рисков, сроки у всех всегда ползут, то вы просто не знакомы с тем, как его надо по-человечески разрабатывать или у вас недостаточно ресурсов.
>>кому-то кажется что нагромождение гавна это ООП. это не так N>Весьма обоснованное предположение. N>Почему объектно-ориентированное программирование провалилось? (извиняюсь за боян).
меня так прикалывают эти желтушные посты. то win 8 провалилось, что еще что-то, то, теперь, оказывается ООП. то ученые нашли, что чеснок лечит рак, то София Ротару собралась лететь на Марс. это никому не интересно.
Re[4]: Не пора ли переименовать ООП в ООН
От:
Аноним
Дата:
10.05.13 19:37
Оценка:
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, nullxdth, Вы писали: >>>основной принцип разработки сложной фигни это разделение на части >>>ООП помогает разделять N>>Каким образом? __>задача разработки качественного ПО в срок сейчас решена. __>это не проблема. это не гадание. это так же просто, как приготовить обед. огромную долю успеха в решении этой задачи занимает ООП.
Можно подробнее , каким образом решена ? Где четкая методология ( рецепт приготовления обеда ) и как оценивать стоимость/сроки каждого шага ?
Здравствуйте, Аноним, Вы писали: А>Можно подробнее , каким образом решена ? Где четкая методология ( рецепт приготовления обеда ) и как оценивать стоимость/сроки каждого шага ?
это как вкратце матан рассказать
учиться этому надо
основные концепции можно так примерно назвать:
дизайн делается не на уровне "тут мы классик заведем, тут синглон воткнем, тут таблица у нас будет с записями, тут говносервис", а выписываются на листочке/доске все сущности, которые есть "юзеры, танки, поле, письма", каждой сущности выделяется их погонялец (контроллер) и оговаривается интерфейс взаимодействия. если интерфейс получается большой его делят на подинтерфейсы. класс большой — его делят на подклассы. чтобы больше примерно 10 методов не было ни у кого. в принципе, деление выдавливать из себя не нужно. обычно все очень натурально делится. у общих сущностей для избежания дублирования кода создается предок (полиморфизм). там где общие методы применяются к разнородным сущностям используюся шаблоны, а не копипаста. таким образом убирается все дублирование и избыточность кода, все дублирование информации еще на этапе дизайна нахрен убирается, чтобы не было ошибок рассинхронизации. над начинающими программистами ставят надсмотрщика. если эта область все равно получается забагованной — меняют надсмотрщика. в коде не оставляют никаких закомментированных вещей и вещей, сделанных на будущее, но пока не используемых.
ну и лично я уже считаю, что код никогда не должен переписываться тем, кто его написал, то есть в случае неуспеха какой-то части меняется команда этой части, команда расформировывается и все участники провалившейся команды понижаются в должности и попадают в подчинение в другие команды.
>меня так прикалывают эти желтушные посты.
Это не "желтушный пост", а вполне адекватное мнение о полемике на одной из конференций OOPSLA.
"Желтушными" кажутся ваши максималистические высказывания. Но пойдём по порядку:
>задача разработки качественного ПО в срок сейчас решена.
Нет. "Задача разработки качественного ПО в срок" --- это сложнейшая задача успех которой зависит от большого количества различных факторов.
Влияние ООП/ООД относительно этой задачи --- капля в море.
Я думаю это должно быть очевидно.
>это не проблема. это не гадание. это так же просто, как приготовить обед.
Ага. А "любая кухарка сможет управлять государством!"
>огромную долю успеха в решении этой задачи занимает ООП.
Я так не считаю. Расскажите об этой "огромной доле успеха" по пунктам и аргументированно.
>да, возможно есть другие какие-то тоже рабочие способы разработки. но они мало кому интересны.
Огромное заблуждение, которое чаще всего присуще фанатикам ООП/ООД.
Существует огромнейшее количество разнообразных проблемных областей и задач, требующих различных подходов: как архитектурных, так и уровня реализации.
Среди методологий и подходов, ООП/ООД является хоть и очень популярной (незаслуженно), но весьма примитивной методологией.
>то ученые нашли, что чеснок лечит рак
Кстати, очень похоже на то, как "британские учёные-программисты" изобрели ООП для решение "всех проблем разработки качественного ПО в срок"
Здравствуйте, nullxdth, Вы писали: >>задача разработки качественного ПО в срок сейчас решена. N>Нет. "Задача разработки качественного ПО в срок" --- это сложнейшая задача успех которой зависит от большого количества различных факторов.
я еще раз говорю — задача разработки качественной архитектуры это как сходить посрать. реализация это архитектуры не сложнее поедания мороженого.
как это продается, управляется, как компания конкурирует сильно зависит от локальных особенностей. в обязанности программиста это не входит.
огромные нерешаемые почти проблемы создают проекты, уже написанные через пень-колоду. это как если бы продукты поставляли только со свалки и вы должны были бы готовить только то, что уже было ранее. тут можно много размышлять что с этим делать. как жигули не переделывай, все равно жигули получатся. вот на этом поле и рождаются какие-то методологии, как из говна смастерить пулю. теоретически — интересно. практически — они занимаются решением несуществующих задач.
Здравствуйте, __kot2, Вы писали:
>это как вкратце матан рассказать >учиться этому надо
Не надо уровень значимости и сложности математики/математического анализа с ООП/ООД сравнивать. Тут явно счёт будет не в пользу второго.
>каждой сущности выделяется их погонялец (контроллер)
Что из себя представляет и для каких целей нужен "погонялец"?
>если интерфейс получается большой его делят на подинтерфейсы.
Как определить "размер" интерфейса?
>чтобы больше примерно 10 методов не было ни у кого
Почему, кстати? И почему примерно 10? Откуда это число?
>у общих сущностей для избежания дублирования кода создается предок (полиморфизм)
Я понимаю что такое полиморфизм в ООП, но то что вы написали --- это какая-то ерунда.
Если "создается предок", то, видимо, под сущностью вы полагаете "класс"; и тогда этот механизм называется "наследованием", а не "полиморфизмом".
>там где общие методы применяются к разнородным сущностям используюся шаблоны, а не копипаста.
Опять я нифига не понял. Что вы подразумевается под "разнородными сущностями"? И что под "шаблонами"?
Осмелюсь предположить, что тут речь об обобщённом программировании. Обобщённое программирование никакого отношения к ООП/ООД не имеет.
>таким образом убирается все дублирование и избыточность кода
В обобщённом программировании и ООП нет механизмов для "убирания" всевозможного избыточного кода
>все дублирование информации еще на этапе дизайна нахрен убирается, чтобы не было ошибок рассинхронизации.
А как быть, например, с кэшем? Кэш не нужен?
>команда расформировывается и все участники провалившейся команды понижаются в должности и попадают в подчинение в другие команды.
Мде... Brilliant management!
С таким отношением вы ничего не напишите. Неужели вы полагаете, что "понижение в должности" работников благоприятно повлияет на успех компании?
>основные концепции можно так примерно назвать
Мде... Не густо с основными концепциями.
Здравствуйте, __kot2, Вы писали:
>я еще раз говорю
Ещё хоть тысячу раз. Без аргументов и доказательств --- просто шум. Самый невежественный и пустой шум.
>задача разработки качественной архитектуры это как сходить посрать. реализация это архитектуры не сложнее поедания мороженого.
Вы уж определитесь "срать" или "кушать"
>как жигули не переделывай, все равно жигули получатся. вот на этом поле и рождаются какие-то методологии, как из говна смастерить пулю.
Нет. Вы совершенно не понимаете семантику слова "методология".
Здравствуйте, __kot2, Вы писали:
__>Здравствуйте, Аноним, Вы писали: А>>Можно подробнее , каким образом решена ? Где четкая методология ( рецепт приготовления обеда ) и как оценивать стоимость/сроки каждого шага ? __>это как вкратце матан рассказать __>учиться этому надо
а за сколько времени ты мне программу напишешь?
Всё сказанное выше — личное мнение, если не указано обратное.
