GoF, SOLID Мартина, GRASP Лармана, Шаблоны корпоративных приложений Фаулера.
Ведь если честно все это ужасно, не хватает четкости мышления, систематичности, ясности, местами эти рекомендации просто вредны.
Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Здравствуйте, HrorH, Вы писали:
HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Это извечная проблема теории и практики -- в книжках/учебниках все хорошо, а
на практике все гораздо сложнее. Тут многое приходит с опытом, с набиванием шишек,
с рефлексией, т.е. отдавать отчет и осмысливать свои действия. Научиться грамотно
проектировать ПО по книгам вряд ли удастся, к этому надо годами идти и не факт,
что придешь. А так, все вышеперечисленные аббревиатуры и методологии это всего лишь
некий набор рекомендаций, общих решений, знать и понимать которые крайне желательно, но
еще лучше понимать границы их применимости, т.е. опять же практика.
Здравствуйте, HrorH, Вы писали:
HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Придумали. Думать своей головой, а не копировать бездумно прочитанное в книжках.
То, что в книжках — это так, для вдохновения.
Посмотреть как люди уже решили какие-то задачи и на какие грабли наткнулись.
Здравствуйте, Sharov, Вы писали:
S>Это извечная проблема теории и практики -- в книжках/учебниках все хорошо, а S>на практике все гораздо сложнее. Тут многое приходит с опытом, с набиванием шишек, S>с рефлексией, т.е. отдавать отчет и осмысливать свои действия. Научиться грамотно S>проектировать ПО по книгам вряд ли удастся, к этому надо годами идти и не факт, S>что придешь. А так, все вышеперечисленные аббревиатуры и методологии это всего лишь S>некий набор рекомендаций, общих решений, знать и понимать которые крайне желательно, но S>еще лучше понимать границы их применимости, т.е. опять же практика.
Понятно, что практику никто не отменяет.
Но то что в книжках "все хорошо", это неправда. В лучшем случае в них кое что хорошо.
Поэтому и спрашиваю, может чего-то другое кто-то знает приличное, кроме книг означенных авторов?
Здравствуйте, HrorH, Вы писали:
HH>GoF, SOLID Мартина, GRASP Лармана, Шаблоны корпоративных приложений Фаулера. HH>Ведь если честно все это ужасно, не хватает четкости мышления, систематичности, ясности, местами эти рекомендации просто вредны.
Кому не хватает четкости мышления и остального перечисленного?
HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Светлая голова, прямые руки и 10+ лет опыта.
Здравствуйте, vmpire, Вы писали:
V>Придумали. Думать своей головой, а не копировать бездумно прочитанное в книжках.
V>То, что в книжках — это так, для вдохновения. V>Посмотреть как люди уже решили какие-то задачи и на какие грабли наткнулись.
Спасибо, КО.
Для вдохновения хочется чего-то более приличного...
HH>Понятно, что практику никто не отменяет. HH>Но то что в книжках "все хорошо", это неправда. В лучшем случае в них кое что хорошо. HH>Поэтому и спрашиваю, может чего-то другое кто-то знает приличное, кроме книг означенных авторов?
Я про контекст, а не про содержание. Рассматриваются типовые примеры, и как правило, не очень
сложные и не очень жизненные.
Здравствуйте, HrorH, Вы писали:
HH>GoF, SOLID Мартина, GRASP Лармана, Шаблоны корпоративных приложений Фаулера. HH>Ведь если честно все это ужасно, не хватает четкости мышления, систематичности, ясности, местами эти рекомендации просто вредны.
Обычно, чёткости мышления не хватает тому, кто начиташись этих книг бежит пременять везед где это не нужно. А так, солди, грасп(Ларман божественнен, имхо), гоф вполне решают те проблемы, которые описаны в паттёрнах. HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Ну... есть визуальные языки для спец задач. Попробуй испоьлзовать их.
Если наш исходный алгоритм занимал сотню простых и понятных строк, то теперь [соблюдая SRP] мы получим в сумме три, четыре, может быть, пять сотен строк, разнесённых по разным модулям.
Будет ли полученная выгода адекватна усложнению? Ответ очевиден.
наверное раз исходные строки названы "понятными" — в SRP получатся непонятные строки? всякие там "class Foo {" — так непонятно.
ну и тестируемость/удобство внесения изменений это конечно незначительная выгода
Здравствуйте, HrorH, Вы писали:
HH>GoF, SOLID Мартина, GRASP Лармана, Шаблоны корпоративных приложений Фаулера. HH>Ведь если честно все это ужасно, не хватает четкости мышления, систематичности, ясности, местами эти рекомендации просто вредны. HH>Неужели не придумали ничего лучше на тему, как проектировать качественные программы?
Книга Сергея Тарасова "Дефрагментация мозга. Софтостроение изнутри" не даёт особых надежд на это, но какие-то мысли всё-таки пробиваются.
Интересно, а как помогает ТРИЗ и теория систем? Есть какие-нибудь примеры, что какая-то идея из ТРИЗ реально помогла?
Слишком много там все-таки завязано на физику.
А по теории систем что можно почитать?
В основном, то что я читал, это были достаточно общие слова, которые очень сложно увязать с программированием.
Здравствуйте, Sharov, Вы писали:
S>Это извечная проблема теории и практики -- в книжках/учебниках все хорошо, а S>на практике все гораздо сложнее.
Это книги прежде всего написаны исходя из практического опыта при этом людьми с ~20+ лет опыта промышленного программирования. Ну и да — только дураки учатся только на своих ошибках.
Здравствуйте, IncremenTop, Вы писали:
IT>Здравствуйте, Sharov, Вы писали:
S>>Это извечная проблема теории и практики -- в книжках/учебниках все хорошо, а S>>на практике все гораздо сложнее.
IT>Это книги прежде всего написаны исходя из практического опыта при этом людьми с ~20+ лет опыта промышленного программирования. Ну и да — только дураки учатся только на своих ошибках.
Я бы не стал так высоко ценить навыки людей и качество книг.
Во-первых, кроме банды четырех, мало кто занимался научной деятельностью в этом направлении. Большая часть книг это компиляция где-то услышанного, где-то увиденного, где-то просто придуманного.
Во-вторых, паттерны не универсальны. Они сильно зависят от языка, фреймворка, типа приложения и конкретных требований. Эта часть в книгах идет обычно в начала и очень небольшого объема, зачастую читающим просто не усваивается.
В-третьих книги по принципам\паттернам пишутся на основе прошлого опыта и, часто бывает, что отстает на 3-5-7 лет от уровня зрелости индустрии в целом. Кроме того опыт может оказаться просто нерелевантным с учетом новых технологий. Например Linq в C# сделал бесполезным 60% книги фаулера АКПП, а mvc и razor сделал бесполезным еще 20%.
12/27/2013 9:10 AM, HrorH пишет:
> Интересно, а как помогает ТРИЗ и теория систем? Есть какие-нибудь > примеры, что какая-то идея из ТРИЗ реально помогла?
Есть, помогла бывшему совладельцу Научсофта и фанату ТРИЗа в Минске
заработать денег.
Здравствуйте, gandjustas, Вы писали:
G>Во-первых, кроме банды четырех, мало кто занимался научной деятельностью в этом направлении. Большая часть книг это компиляция где-то услышанного, где-то увиденного, где-то просто придуманного.
Если понимать под научной деятельностью исключительно сидение на должности в вузе — то да. Большая часть книг — это синтез практики и теории. Например, Рефакторинг Ф. закономерно опирается на диссеры Опдайка и Робертса, хотя из указанных выше наименее наукообразен.
ИТ переживает такой период, когда многим выгоднее заниматься наукой на "практике".
G>Во-вторых, паттерны не универсальны. Они сильно зависят от языка, фреймворка, типа приложения и конкретных требований. Эта часть в книгах идет обычно в начала и очень небольшого объема, зачастую читающим просто не усваивается.
Если читающий не болеет чукчизмом, то он без труда заметит, что в книгах говорится и об ограничениях, и о том, что примеры являются прежде всего примерами, а не руководством к действию. Но ведь большинство бежит на форум жаловаться на неправильные книги и концепции(!). Наверное, надо это писать очень крупными буквами.
G>В-третьих книги по принципам\паттернам пишутся на основе прошлого опыта и, часто бывает, что отстает на 3-5-7 лет от уровня зрелости индустрии в целом.
Эту индустрию во многом подобные товарищи двигают. Ну и не стоит забывать об актуализации знаний — не только об указанных выше товарищах, хотя и они многие тенденции подмечают и указывают.
Здравствуйте, HrorH, Вы писали:
HH>Интересно, а как помогает ТРИЗ и теория систем? Есть какие-нибудь примеры, что какая-то идея из ТРИЗ реально помогла?
Классическая ТРИЗ действительно предназначена для решения другого класса задач. Это задачи "железячные", связанные с прогнозированием и развитием материальных технических систем. Прямое применение ТРИЗ в программировании невозможно. Знание ТРИЗ лишь поможет подойти к проектированию программных систем более осознанно, т.к. ТРИЗ помогает, что называется, поставить системное мышление.
HH>А по теории систем что можно почитать?
IT>Это книги прежде всего написаны исходя из практического опыта при этом людьми с ~20+ лет опыта промышленного программирования. Ну и да — только дураки учатся только на своих ошибках.
Полностью согласен. Но, во-первых, эти книги написаны опытными разработчиками для неопытных,
во-вторых, двадцатилетний опыт просто так в книгу не запихнешь. Некие общие эвристики, рекомендации и т.п.
А вообще, ради мысленного эксперимента замените "проектировать качественные программы" на "рисовать".
И посмотрите, можно ли научиться рисовать, прочитав множество книжек, изучив (по книгам) множество техник,
но так и не пробуя рисовать, набивать руку?
Здравствуйте, 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 диаграме можно легко выявить косяки в системе даже не зная что она делает. Только смотреть нужно не на квадратики, а на стрелочки.
Здравствуйте, _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 не по делу проще простого.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, IT, Вы писали:
I>>Это понятно, мне интересно как ты для мвц посчитал. Пудозреваю, моделька сложности это примерно мультиграф всех путей.
IT>Так задача MVC как раз устранять или в крайнем случае ослаблять все эти связи. А разные MVx как раз и отличаются тем над какими именно связями они глумятся в большей степени.
Это понятно. Мне не совсем понятно, будет ли мультиграф всех путей адекватной моделью сложности системы. Если так, то сложность растет в лучшем случае факториально от количества связей. Т.е. как то слишком круто — добавил одну мутную связь и получилось чудовище
I>>Дай почитать что ли ? Книга, сайт и тд. Я одно время интересовался, но в разных источниках совершенно разные вещи пишут и не совсем очевидно, как такие знания применять на практике.
IT>Надо поискать. К сожалению, применительно к программированию я ничего не видел, поэтому приходилось читать что-то очень общее, применительное чуть ли не к бизнесу.
Здравствуйте, Ikemefula, Вы писали:
I>Это понятно. Мне не совсем понятно, будет ли мультиграф всех путей адекватной моделью сложности системы. Если так, то сложность растет в лучшем случае факториально от количества связей. Т.е. как то слишком круто — добавил одну мутную связь и получилось чудовище
Ну я бы лучше оперировал измерениями — новая сущность, новое измерение.
I>Короче, толку от тебя никакого
Хамство всегда было твоей визитной карточкой.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Artem Korneev, Вы писали:
AK>Интересно, почему бы этим "самым опытным разработчикам" не написать книгу лучше?
Так а смысл писать? Прежде чем писать книгу об искусстве проектирования, надо написать книгу об искусстве мышления.
Ведь принципы проектирования — это почти философская вещь, они требуют умения мыслить философски.*
А теперь скажите кому будет нужна такая книга, на стыке философии и программирования?
*То есть в человеческом мышлении также как и в программировании можно выделить паттерны и антипаттерны.
Если взять книги по проектированию, то можно видеть, что антипаттернов мышления в логике их авторов больше, чем паттернов.
Тот же принцип открытости-закрытости дает прекрасный пример антипаттерна, который в философии называют "смешение".
Под одним и тем же названием фигурирует принцип Бертрана Мейера и принцип Мартина, а ведь эти принципы существенно отличаются друг от друга. Да и Ларман пытается отождествить этот принцип с Protected variations, делая ту же ошибку.
Кстати, если почитать этот принцип у Мейера, написано там все почти хорошо и мощно, по сравнению с остальными.
(Ошибки конечно тоже есть. Например не учтено что наследование реализации часто является злом.)
Если нам не помогут, то мы тоже никого не пощадим.
