LINUX.ORG.RU

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


0

0

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

Мне лично, концепция рефакторинга, как средства постоянного улучшения архитектуры проекта, нравится. К тому же это хорошо сочетается с модным нынче XP.

★★★★★

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

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

anonymous_incognito ★★★★★
()
Ответ на: комментарий от kto_tama

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

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

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

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

anonymous_incognito ★★★★★
()

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

php-coder ★★★★★
()

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

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

XP - нафиг.

Miguel ★★★★★
()
Ответ на: комментарий от Miguel

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

lingvo.ru: pattern

1. сущ.

1)

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

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

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

mv ★★★★★
()
Ответ на: комментарий от mv

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

anonymous
()
Ответ на: комментарий от mv

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

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

Miguel ★★★★★
()

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

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

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

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

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

anonymous
()
Ответ на: комментарий от mv

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

yz
()
Ответ на: комментарий от yz

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

KIV
()
Ответ на: комментарий от KIV

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

krum
()
Ответ на: комментарий от KIV

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

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

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

anonymous
()
Ответ на: комментарий от krum

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

krum
()
Ответ на: комментарий от krum

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

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

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

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

anonymous
()
Ответ на: комментарий от yz

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

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

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

anonymous
()
Ответ на: комментарий от anonymous

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

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

ero-sennin ★★
()
Ответ на: комментарий от ero-sennin

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

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

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

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

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.