Паттерны проектирования, рефакторинг

По-моему, эта тема уже всплывала на LOR.

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

рефакторинг - это когда нефиг делать больше на работе ?

> рефакторинг - это когда нефиг делать больше на работе ?

Почему же нефиг?

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

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

А какое пренебрежение паттернам ты видел?

Рефакторинг рулит! :) (IMHO)

Наличие паттернов - симптом слабости языка. Чем их больше - тем язык слабее.

Рефакторинг - очень важная вещь

XP - нафиг.

> Наличие паттернов - симптом слабости языка. Чем их больше - тем язык слабее.

lingvo.ru: pattern

1. сущ.

1)

а) образец, модель

б) пример (для подражания), образчик

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

Анонимус утверждал, что паттерны нужны только быдлокодерам.

> Так чем же плохо повторное использование уже готовых походов, решений?

Тем, что они должны быть реализованы ОДИН раз, запихнуты в библиотеку и чтобы далее о реализации даже не думать.

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

Когда возникает потребность в формализации большого (и даже очень) набора типовых шаблонов, которые будут неизбежно встречаться в реализации любой практической объектной модели, то это говорит только о том, что любая такая модель неадекватна, и что технология моделирования неадекватна. Мат. модель по определению минималистична, и наболее компактным образом описывает предметную область - и появление повторяющихся шаблонов говорит о наличии серьёзных дыр в самой методологии проектирования. То есть, сами по себе шаблоны может и не плохи, но они являются симптомом настоящей гадской болезнии - OOD/OOP. И вот эта дрянь то как раз и плоха, адски плоха.

Рефакторинг - тоже, сам по себе не хорош и не плох, необходимость чрезмерного рефакторинга говорит об убожестве методологии (то есть, о неприменимости идеалистичного, ограниченного OOD для проблем реального мира).

> К тому же это хорошо сочетается с модным нынче XP.

Обычно модой интересуется только быдло. Нормальный человек такой хернёй не заморачивается.

> Так чем же плохо повторное использование уже готовых походов, решений?

Тем, что НОРМАЛЬНЫЙ язык при первом же появлении повторяющегося шаблона позволяет сделать из этого шаблона абстракцию более высокого уровня, и использовать уже её. Дерьмовые же быдлонедоязычки заставляют писать мегатонны кода на каждый случай применения такого вот шаблона.

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

>Тем, что НОРМАЛЬНЫЙ язык при первом же появлении повторяющегося шаблона позволяет сделать из этого шаблона абстракцию более высокого уровня, и использовать уже её. Дерьмовые же быдлонедоязычки заставляют писать мегатонны кода на каждый случай применения такого вот шаблона.

А производительность? Представь себе, что случилось бы, если бы поисковый движок Гугла был написан на Лиспе. ;)

> А производительность?

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

> Представь себе, что случилось бы, если бы поисковый движок Гугла был написан на Лиспе. ;)

Ничего бы не случилось. Лисп существенно быстрее, чем быдловский недоязычок C++.

>Ничего бы не случилось. Лисп существенно быстрее, чем быдловский недоязычок C++.

Да ну? Без нормальных тестов твои слова ничего не стоят.

Ну можно, конечно, программировать на Лиспе в стиле C (ради производительности), отказавшись от многих его фич. К примеру, представляя графы битовыми матрицами. Но смысл тогда Лисп вместо С использовать?

>Лисп существенно быстрее, чем быдловский недоязычок C++.
Да неужели?

> Ну можно, конечно, программировать на Лиспе в стиле C (ради производительности), отказавшись от многих его фич. К примеру, представляя графы битовыми матрицами. Но смысл тогда Лисп вместо С использовать?

Не надо на Лиспе в стиле Си программировать. Главная сила Лиспа - в метапрограммировании.

Например, на Си, при использовании библиотеки pcre, ты максимум, чего можешь добиться - это скомпилировать регулярное выражение в дерево, и потом его будет исполнять тормозной интерпретатор. И ещё код у тебя криво выглядеть будет - инициализация скомпилированного регекспа в одном месте, использование в другом. В Лиспе же, и в любом другом достаточно мощном метаязыке, статическое регулярное выражение будет просто скомпилированно в оптимизированный нативный код, а для пользователя всё будет выглядеть гораздо более прозрачно - где регэксп используем, там его и определяем, и пусть компилятор решает, динамический он тут или статический, и каким именно способом его компилировать.

Причём, сами макры, при том что они реализуют очень высокоуровневые абстракции, легко могут использовать сколь угодно низкоуровневый код - вплоть до генерёжки ассемблерных вставок. И всё соврешенно прозрачно для пользователя - он просто НЕ УВИДИТ всего этого низкоуровневого барахла. В то время как в убогих недоязычках, таких как C++, если ты предоставляешь юзеру мощные низкоуровневые оптимизации, то и юзерский код будет низкоуровневым.

Просто многие тут не догоняют - сила Лиспа не в списках и лямбдах, а в макрах. Которые, в свою очередь, могут хоть в ассемблерный код разворачиваться, гораздо более производительный чем всё, на что способен быдло-C++.

>скомпилированно в оптимизированный нативный код
Одно плохо - код этот(дизассемблером смотрел?) обычно намного хуже аналогичного, сгенеренного компилятором C/C++.

> Одно плохо - код этот(дизассемблером смотрел?) обычно намного хуже аналогичного, сгенеренного компилятором C/C++.

Не, обычно он лучше. Там же type annotations расставленны.

В моей реализации оно и вовсе сразу в ассемблер компилится, так что код заведомо существенно лучше чем у C++ - он заточен под только регулярные выражения, так же как и тот код, который генерится для прологообразного DSL получается лучше, чем скомпилированный через C WAM, и код из FSM получается лучше чем на C с кучей goto.

ЗЫ: и, кстати, о какой вообще производительности можно говорить, когда код написан на очень ООПнутом быдло-C++ с применением всех этих быдлошаблонов? Такой код, бывает, даже у Java отсасывает.

>В моей реализации оно и вовсе сразу в ассемблер компилится
Используешь одну из дорогущих коммерческих реализаций? Так бы сразу и сказал...

> Используешь одну из дорогущих коммерческих реализаций? Так бы сразу и сказал...

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

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

Отлично! Наконец-то - после долгого перерыва - грамотный и аргументированый обсер крестов на лоре.

"Подписался на коменты".

Тут есть еще один момент. Многие заказчики не согласяться на решение их задачи на Лиспе из-за его нераспостраненности(по сравнению с теми же C/C++/C#).

> Отлично! Наконец-то - после долгого перерыва - грамотный и аргументированый обсер крестов на лоре.

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

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

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

К счастью, сейчас таких идиотов становится всё меньше и меньше.

Fortran RIP.

Ещё что нибудь такое же смешное сможешь пёрднуть? Публика запасается попкорном!

Ну, а если жизнь действительно круто меняется? Вот писал ты программу 3 года подряд для одного единственного заказчика. Эта программа во всех местах под него заточена, а точнее под тех 3-х программистов, которые у него ею пользуются. И тут заказчик заявляет: типа программа стала крутая, вы типа теперь хотите много денег для её развития, так что продавайте-ка её на сторону сами, а на эти бабки сами живите и мне ещ фичи подкидывайте. И чё делать спрашивается? Вот тут-то и начинается мегарефакторинг...

Это уже совсем не то, что под рефакторингом понимают адепты XP.

>Отлично! Наконец-то - после долгого перерыва - грамотный и аргументированый обсер крестов на лоре.

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

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

PSS. Это мое ИМХО.

Найдите мне библиотеку на Lisp, аналогичную ACE, которая работает на огромным количеством платформ. Вряд ли Lisp будет хорошим решением для системного ПО.

> ЗЫ. Подрастет, поймет что не в языках сила, а в башке программиста.

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

ЗЫ: Кажется, быдлошко, это ты было, что кричало тут пару лет назад о том, что "рекурсия - зло"? Ну так, быдлушко, ты вообще не программист, ты ничтожество, и права на собственное мнение не имеешь.

В сад, жывотное. Прочитай внимательно, жывотное, что мы тут обсуждаем, а потом пукай, ок?

Библиотеки вообще не при чём. Целевой язык и целевая платформа при обсуждаемом подходе могут быть совершенно произвольными.

Вообще-то тут тема про рефакторинг и паттерны проектирования, ты залез сюда с Лиспом, заявляешь, что C++ - дерьмо, но при этом не спросил у автора топика, какова исходная задача. Может ему надо написать очень быстрый, надёжный и переносимый между платформами сервер. Так что, заглохни, плесень.

> Вообще-то тут тема про рефакторинг и паттерны проектирования,

Именно. Языки не относятся к теме совершенно.

> ты залез сюда с Лиспом

Не я первый упомянул Лисп. Я говорил про метапрограммирование вообще. Про Лисп начали бухтеть местные безграмотные тупые ушлёпки. Хорошо хоть что про Лисп краем уха слышали, но дальше этого ваш кругозоришко не тянется.

> заявляешь, что C++ - дерьмо, но при этом не спросил у автора топика, какова исходная задача

C++ - дерьмо для ЛЮБОЙ задачи.

> Может ему надо написать очень быстрый, надёжный и переносимый между платформами сервер

Кто будет такое делать на C++, да ещё и ООПно, с паттёрнами - тот вообще убогий тупица. Тут скорее подход, используемый в Erlang зарулит (если не вообще сам Erlang).

Макры они и в Плюсах макры. И уж, тем более, никто тебе не запрещает твои ассемблерные вставки на плюсовых макрах делать. Что-то кажеться мне, что ты просто клюнул на "крутизну" Шепелявого. Плюсы полюбому лучше, хотя бы за счет наработанной кодовой базы.

>Кто будет такое делать на C++, да ещё и ООПно, с паттёрнами - тот вообще убогий тупица.
Это ты о разработчиках ROOT?(http://root.cern.ch/)

Уж об этих уродах я кроме как матом вообще говорить не намерен. Тупицы конченные! После CERNlib их вонючее быдлоподелие выглядит хуже жидкого кала. При том, что многие разработчики - те же самые. Вот что с людьми пидарский ублюдочный сраный быдлонедоязычок C++ делает!

> Макры они и в Плюсах макры.

Нет, дебил, они там совсем не настоящие макры. Они там - говно, а не макры. Темплейты в C++ - самая убогая из когда либо существовавших систем метапрограммирования.

Тупейший тест - сделать нормальный, эффективный, полиморфный foreach. Даже на такой лаже C++ная быдлятина обосралась!

> Плюсы полюбому лучше, хотя бы за счет наработанной кодовой базы.

И кому на хер нужны эти мегатонны говна?

> Макры они и в Плюсах макры.

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

А чем тебе плюсовый foreach не нравится? Кроме того, что это быдляцкий C++...

> А чем тебе плюсовый foreach не нравится? Кроме того, что это быдляцкий C++...

Тем, что нет никакого foreach, который работал бы для любого stl-контейнера.

Зачем?

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

Так foreach же для последовательности, а не для контенера...

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

Хехе, это кажись подрос ребенок профессора :)

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

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

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

И не надо врать про "LISP на два порядка компактнее"; сходи хотя бы на shootout и убедить, что даже не вдвое. Да и код, скажем, в Practical Common Lisp нихрена не поражает компактностью.

> Вау. Учтя, что Spirit - это генератор парсеров для контекстно-свободных грамматик, совершенно очевидно, что он вполне себе реализует "ранее помянутую компиляцию регэкспов".

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

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

Данивапрос, я сам всегда ровно это же говорил.

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

Кстати, люди таки уходят с bison/flex на ANTLR, Ragel и др.