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

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

K>Обычно, чёткости мышления не хватает тому, кто начиташись этих книг бежит пременять везед где это не нужно. А так, солди, грасп(Ларман божественнен, имхо), гоф вполне решают те проблемы, которые описаны в паттёрнах.

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

А что касается четкости мышления и ясности, то чтобы заметить их отсутствие в книге, надо извините самому хоть в какой-то степени ими обладать.
Вот скажем "Алгоритмы:построение и анализ" — это пример удивительной ясности мышления.
Или скажем "Дискретная математика" Белоусова и Ткачева, "Грани алгебры" Аршинова и Садовского.
И еще пожалуй некоторые места в "Метафизике" Аристотеля.
Все это примеры ясности мышления. Книги по проектированию не дотягивают до этого уровня.

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

HH>Интересно, а как помогает ТРИЗ и теория систем? Есть какие-нибудь примеры, что какая-то идея из ТРИЗ реально помогла?

Хотя бы тот же принцип, который здесь часто звучит как "Ты не рассказывай нам своё кривое решение, ты изначальную задачу объясни".

HH>В основном, то что я читал, это были достаточно общие слова, которые очень сложно увязать с программированием.

Почему сложно? Например, MVC паттерн легко объясняется в терминах теории систем, которая утверждает, что сложность системы определяется не её составляющими, а связями между ними. Так при наличии 3-х компонентов (как в MVC) в системе у нас возникает даже не 6 возможных связей, как думают многие, а 12. А для 4-х компонентов это уже не 12, а 32 и т.п. MVC как раз и пытается рещить проблему связей, по возможности устранить их или ослабить. Ещё интересней обстоит дело с БД. По ER диаграме можно легко выявить косяки в системе даже не зная что она делает. Только смотреть нужно не на квадратики, а на стрелочки.

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

A>наверное раз исходные строки названы "понятными" — в SRP получатся непонятные строки? всякие там "class Foo {" — так непонятно.
A>ну и тестируемость/удобство внесения изменений это конечно незначительная выгода

Это очень сильно зависит от конкретной ситуации. Любой паттерн, принцип, инструмент в определённой ситуации может оказаться плохим, если он применяется таким образом, что приносит больше вреда, чем пользы. А вред в виде дополнительной сложности привносится всегда. В жизни это называется over-architecture. Есть только один вид сложности, которого, на мой взгляд, не стоит бояться — это сложность обучения, т.к. эта сложность преодолевается один раз и потом уже не является проблемой всю оставшуюся жизнь.

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

A>>наверное раз исходные строки названы "понятными" — в SRP получатся непонятные строки? всякие там "class Foo {" — так непонятно.
A>>ну и тестируемость/удобство внесения изменений это конечно незначительная выгода

IT>Это очень сильно зависит от конкретной ситуации. Любой паттерн, принцип, инструмент в определённой ситуации может оказаться плохим, если он применяется таким образом, что приносит больше вреда, чем пользы. А вред в виде дополнительной сложности привносится всегда. В жизни это называется over-architecture.
а речь не шла о какой-то неизвестной ситуации. речь о 100-строчном преобразователе XML в HTML, и о том что ты в статье написал что для него SRP не нужно, т.к. якобы понятные строки становятся непонятными.

да и вообще, "в 0.001% ситуаций любой паттерн, принцип, инструмент будет приносить больше вреда чем пользы" — это не аргумент в разговоре о том что хорошо а что плохо.

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

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

IT>>Это очень сильно зависит от конкретной ситуации. Любой паттерн, принцип, инструмент в определённой ситуации может оказаться плохим, если он применяется таким образом, что приносит больше вреда, чем пользы. А вред в виде дополнительной сложности привносится всегда. В жизни это называется over-architecture.
A>а речь не шла о какой-то неизвестной ситуации. речь о 100-строчном преобразователе XML в HTML, и о том что ты в статье написал что для него SRP не нужно, т.к. якобы понятные строки становятся непонятными.

Ты тоже втыкаешь SRP в каждую дюжину строк кода? А пример на самом деле почти из жизни. На одном моём проекте, один, извините за мой французский, арихтектор мудак умудрился в подобной ситуации вместо 200 строк кода нарисовать 70 классов и превратить простейшую, казалось бы, задачу в нечно запредельное по сложности. Этот придурок очень сильно хотел разделять ответственности и искал их даже там, где их никогда не было. Он считал себя очень опытным архитектором и носил на груди табличку "Design Pattern Police". Через пол года был разжалован в младшие разработчики.

A>да и вообще, "в 0.001% ситуаций любой паттерн, принцип, инструмент будет приносить больше вреда чем пользы" — это не аргумент в разговоре о том что хорошо а что плохо.

Любой паттерн автоматически плох в 100% случаях, потому что ничего бесплатного в этой жизни не бывает. Сделать его менее плохим и извлечь из него пользу задача разработчика. Если у разработчика нет мозгов и паттерны применяются не по назначению, то полезный выхлоп от таких паттернов чаще всего отрицательный.

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

Так и есть. Вот и нужно этот порог преодолевать.

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

IT>>>Это очень сильно зависит от конкретной ситуации. Любой паттерн, принцип, инструмент в определённой ситуации может оказаться плохим, если он применяется таким образом, что приносит больше вреда, чем пользы. А вред в виде дополнительной сложности привносится всегда. В жизни это называется over-architecture.
A>>а речь не шла о какой-то неизвестной ситуации. речь о 100-строчном преобразователе XML в HTML, и о том что ты в статье написал что для него SRP не нужно, т.к. якобы понятные строки становятся непонятными.

IT>Ты тоже втыкаешь SRP в каждую дюжину строк кода?
нет, к сожалению мне не удается применять SRP везде где это было бы нужно.

мой пойнт в том, что SRP надо применять не потому что это круто, а потому что его применение упрощает внесение изменений в код.
что означает, "если мы будем вносить такие-то изменения в этот код, нам надо так-то применить SRP".

IT>Любой паттерн автоматически плох в 100% случаях, потому что ничего бесплатного в этой жизни не бывает. Сделать его менее плохим и извлечь из него пользу задача разработчика. Если у разработчика нет мозгов и паттерны применяются не по назначению, то полезный выхлоп от таких паттернов чаще всего отрицательный.
Я смотрю на это иначе.
Паттерны говорят: "если есть проблема А, она будет изменяться в A' и при этом мы можем пожертвовать свойством X — используй паттерн P".

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

Применительно к SRP это выглядит так:
Надо написать код реализующий фичи A и B. Тогда мы применяем SRP если
— мы хотим менять реализацию фичи A не трогая реализацию фичи B
— — потому что так безопаснее, больше шансов что фича B не сломается
— — потому что мы хотим переписывать меньше юниттестов
— — потому что нам так проще ревьювить пулреквесты, и вообще проше смотреть что поменялось в коммитах
— два разработчика будут менять реализацию фич A и B, и мы не хотим чтобы они мешали друг другу.
— новым членам команды проще читать реализацию фич A и B по-отдельности
и т.п.
Если нам это не нужно, если фичи A и B всегда будут меняться вместе, или не будут меняться вообще — то мы не применяем для них SRP.

---

IT>>>Есть только один вид сложности, которого, на мой взгляд, не стоит бояться — это сложность обучения, т.к. эта сложность преодолевается один раз и потом уже не является проблемой всю оставшуюся жизнь.
A>>"сложность обучения" это еще и "порог вхождения", который иногда является основной проблемой внедрения той или иной технологии.
IT>Так и есть. Вот и нужно этот порог преодолевать.
только на практике этого не происходит.
так что я больше склоняюсь к тому что надо делать вещи проще, чтоб порог вхождения был ниже.

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

IT>>Ты тоже втыкаешь SRP в каждую дюжину строк кода?
A>нет, к сожалению мне не удается применять SRP везде где это было бы нужно.

Для меня это звучит примерно так: твой здравый смысл не позволяет тебе применять SRP везде к твоему большому сожалению.

A>мой пойнт в том, что SRP надо применять не потому что это круто, а потому что его применение упрощает внесение изменений в код.
A>что означает, "если мы будем вносить такие-то изменения в этот код, нам надо так-то применить SRP".

Это означает ещё кое что. Это означает, что "если мы НЕ будем вносить такие-то изменения в этот код, нам НЕ надо так-то применить SRP". Это вытекает из элементарной логики и почему-то с этим ты (и не только ты) споришь.

IT>>Любой паттерн автоматически плох в 100% случаях, потому что ничего бесплатного в этой жизни не бывает. Сделать его менее плохим и извлечь из него пользу задача разработчика. Если у разработчика нет мозгов и паттерны применяются не по назначению, то полезный выхлоп от таких паттернов чаще всего отрицательный.
A>Я смотрю на это иначе.
A>Паттерны говорят: "если есть проблема А, она будет изменяться в A' и при этом мы можем пожертвовать свойством X — используй паттерн P".

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

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

Эти проблемы перманентны и возникают постоянно. Если, конечно же, ты не решаешь одни и те же типовые задачи изо дня в день.

A>Применительно к SRP это выглядит так:
A>Надо написать код реализующий фичи A и B. Тогда мы применяем SRP если
A>- мы хотим менять реализацию фичи A не трогая реализацию фичи B
A>- — потому что так безопаснее, больше шансов что фича B не сломается
A>- — потому что мы хотим переписывать меньше юниттестов
A>- — потому что нам так проще ревьювить пулреквесты, и вообще проше смотреть что поменялось в коммитах
A>- два разработчика будут менять реализацию фич A и B, и мы не хотим чтобы они мешали друг другу.
A>- новым членам команды проще читать реализацию фич A и B по-отдельности
A>и т.п.

Это всё какая-то неинтересная фигня. Попытка спроецировать свой личный опыт на глобальные принципы. В результате получается две крайности: личные принципы и глобальный опыт. И ты пытаешься выдать первое за второе.

A>Если нам это не нужно, если фичи A и B всегда будут меняться вместе, или не будут меняться вообще — то мы не применяем для них SRP.

Если две фичи всегда вместе, то это одна фича и не надо было её разделять с самого начала, т.е. не надо было следовать догмам и применять SRP.

A>

---

IT>>Так и есть. Вот и нужно этот порог преодолевать.
A>только на практике этого не происходит.
A>так что я больше склоняюсь к тому что надо делать вещи проще, чтоб порог вхождения был ниже.

Это не такой простой вопрос как кажется. Преодоление порога вхождения позволяет использовать качественно другие инструменты. Типа был ты пешеходом, а стал велосипедистом. Был велосипедистом, а стал водителем. Скорость передвижения кардинально меняется с каждым разом. Например, тот же LINQ в C# позволяет решать более сложные задачи более простым способом. Но все эти нештяки становятся доступны только после преодоления порога вхождения.

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

IT>Это всё какая-то неинтересная фигня. Попытка спроецировать свой личный опыт на глобальные принципы. В результате получается две крайности: личные принципы и глобальный опыт. И ты пытаешься выдать первое за второе.
да, мой личный опыт состоит в написании кода который потом надо поддерживать.
и мне кажется что глобально все тоже пишут такой код, а не код на выброс.

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

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

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

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

IT>Опыт штука обманчивая, т.к. базируется на том что и как НЕ надо делать в определённой ситуации. На вопрос как делать правильно в любой ситуации он не отвечает. Поэтому опыт — это плохой аргумент в споре на глобальные темы.

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

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

HH>GoF, SOLID Мартина, GRASP Лармана, Шаблоны корпоративных приложений Фаулера.
HH>Ведь если честно все это ужасно, не хватает четкости мышления, систематичности, ясности, местами эти рекомендации просто вредны.
HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?

Эти вещи ничего общего с проектированием не имеют.

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

HH>>В основном, то что я читал, это были достаточно общие слова, которые очень сложно увязать с программированием.

IT>Почему сложно? Например, MVC паттерн легко объясняется в терминах теории систем, которая утверждает, что сложность системы определяется не её составляющими, а связями между ними. Так при наличии 3-х компонентов (как в MVC) в системе у нас возникает даже не 6 возможных связей, как думают многие, а 12. А для 4-х компонентов это уже не 12, а 32 и т.п. MVC как раз и пытается рещить проблему связей, по возможности устранить их или ослабить. Ещё интересней обстоит дело с БД. По ER диаграме можно легко выявить косяки в системе даже не зная что она делает. Только смотреть нужно не на квадратики, а на стрелочки.

А откуда 12, 32 ?

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

IT>>Опыт штука обманчивая, т.к. базируется на том что и как НЕ надо делать в определённой ситуации. На вопрос как делать правильно в любой ситуации он не отвечает. Поэтому опыт — это плохой аргумент в споре на глобальные темы.

_A_>Очень странное трактование опыта.

Так это не моя трактовка. Ещё Александр Сергеевич писал "И опыт, сын ошибок трудных...". Или вот ещё народное — за одного битого двух не битых дают. Т.е. без ошибок опыт не опыт и только набивая шишки мы его получаем.

_A_>У меня почему-то опыт другой: как нужно действовать в определенной ситуации. Ну и конечно как не нужно. Но стараюсь анализировать свои действия и таким образом вырабатывать свои практики. И когда чутье говорит что дело идет как-то не так (говнокод придется писать, или потом костылями изменения приделывать), то включается мыслительный процесс придумывания нового решения. Даже на подсознательном уровне. И через некоторое время (может пройти несколько дней) приходит лучшее, в данной ситуации, решение.

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

Взять, к примеру, моего оппонента, который несколькими постами выше пишет

нет, к сожалению мне не удается применять SRP везде где это было бы нужно.

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

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

I>А откуда 12, 32 ?

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

Кстати, с 32 я похоже напутал. Там получается гораздо больше.

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

IT>Взять, к примеру, моего оппонента, который несколькими постами выше пишет

IT>

нет, к сожалению мне не удается применять SRP везде где это было бы нужно.

IT>Это что — здравый смысл? Нет, конечно, это даже не опыт. Это личные предпочтения. SRP ему просто очень нравится. Но, к его сожалению, его же здравый смысл не даёт ему применять SRP везде где только можно.
нет, я имел ввиду что лень мешает мне разносить фичи по разным классам (и потом я получаю из за этого проблемы когда мне надо править этот код)

IT>И стоит хоть чуточку наехать на SRP, показать, что это не везде и не всегда работает
где ты это показал?

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

IT>>Это что — здравый смысл? Нет, конечно, это даже не опыт. Это личные предпочтения. SRP ему просто очень нравится. Но, к его сожалению, его же здравый смысл не даёт ему применять SRP везде где только можно.
A>нет, я имел ввиду что лень мешает мне разносить фичи по разным классам (и потом я получаю из за этого проблемы когда мне надо править этот код)

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

IT>>И стоит хоть чуточку наехать на SRP, показать, что это не везде и не всегда работает
A>где ты это показал?

Ну хорошо, раз непонятно из статьи, то вот специально для тебя:

using System;
using System.IO;
using System.Linq;
using System.Xml.Linq;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            // Parsing.
            //
            var xml    = XDocument.Load("test.xml");
            var values = xml.Descendants("value").ToList();

            // Transformation.
            //
            var ints = values.Select(v => int.Parse(v.Value) * 2).ToList();

            // Output.
            //
            var html = File.CreateText("test.html");

            html.WriteLine("<html><table>");

            foreach (var @int in ints)
                html.WriteLine("<tr><td>{0}</td></tr>", @int);

            html.WriteLine("</table></html>");
        }
    }
}

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

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

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

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

IT>Кстати, с 32 я похоже напутал. Там получается гораздо больше.

Дай почитать что ли ? Книга, сайт и тд. Я одно время интересовался, но в разных источниках совершенно разные вещи пишут и не совсем очевидно, как такие знания применять на практике.

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

IT>Ну хорошо, раз непонятно из статьи, то вот специально для тебя:
IT>Здесь просматриваются три чёткие ответственности, помеченные комментариями. Всё как в настоящем компиляторе, где без SRP не обойтись.
а где юнит-тесты/регрессионные-тесты?

конечно для программ уровня hello world никакой SRP не нужен.
но ты начни добавлять туда код, и сразу понадобится отрефакторить так что получится соблюдение SRP.

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

I>Это понятно, мне интересно как ты для мвц посчитал. Пудозреваю, моделька сложности это примерно мультиграф всех путей.

Так задача MVC как раз устранять или в крайнем случае ослаблять все эти связи. А разные MVx как раз и отличаются тем над какими именно связями они глумятся в большей степени.

I>Дай почитать что ли ? Книга, сайт и тд. Я одно время интересовался, но в разных источниках совершенно разные вещи пишут и не совсем очевидно, как такие знания применять на практике.

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

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

A>а где юнит-тесты/регрессионные-тесты?

Для данного кода они не имеют смысла.

A>конечно для программ уровня hello world никакой SRP не нужен.

Я должен тебя огорчить. Правильно спроектированное приложение в идеале — это набор хэлоу вордов.

A>но ты начни добавлять туда код, и сразу понадобится отрефакторить так что получится соблюдение SRP.

Правильно. Молодец. Теперь перечитай статью и увидишь что ты сам догадался до вывода, обозначенного в ней. А если почитаешь ещё внимательнее, то узнаешь, что, к сожалению, формальной грани между где надо, а где не надо применять SRP не существует. В результате применить SRP не по делу проще простого.