Здравствуйте, IB, Вы писали:
A>>Ок, за исключением одной вещи -- смерти человека. IB>Ну пока код для игрушечных приложений пишется — оно конечно да, исправить можно все. Аты представляешь какой кровью дается обратная совместимость с предыдущими версиями API своего же продукта?
Так что вообще свой фреймворк не развивать? Пусть топчется на ровном месте -- исправляем баги и увеличиваем перформанс?
Посмотри на .net FW нет там обратной совместимости.
Посмотри на DevExpress: они даже номер версии в название сборки включают -- чтобы не было бездумного (автоматического) перехода на новую версию библиотеки.
Общий сценарий замены таков:
1) Потребовалось заменить существующую реализаци, сделать новую более эффективную, удобную, ...
2) Реализовываешь ее параллельно с первоначальной
3) Помечаешь старую реализацию Obsolete и останавливаешь работу над ней -- все пользователи старого варианта получают предупреждения: "реализация устарела, в один прекрасный момент ее может совсем не стать, используйте то-то и то-то взамен"
4) Несколько версий библиотеки выпускаются с Obsolete, чтобы дать пользователям время перейти на новый дизайн
5) Методы удаляются -- кто не заменил -- сам дурак, было дано куча времени.
IB>Я бы посмотрел, как ты будешь исправлять свой код, на котором кастомер уже пару решений построил и впарил третьему клиенту.
Построил? -- Замчательно.
Впарил клиенту? -- Значит с текущей версией библиотеки его приложение работает неплохо.
Хочет исползовать новую версию библиотеки? -- А, зачем раз все работает и продается?
Хочет развивать приложений? -- Ну тогда пусть изменяет пользователей измененного класса -- ему же лучше, так как новый дизайн удобнее.
A>> Да, есть масса общепринятых практик. Твое правило к которым очевидно не относится. IB>Очевидно относится, так как основано на тех же самых практиках.
Раз мы ведем этот спор, то для нас это неочевидно.
Есть другой вариант этого правила
, вот он мне нравится. В первую очередь некатегоричностью в отличии от твоего:
If you're writing a function that can be implemented as either a member or as a non-friend non-member, you should prefer to implement it as a non-member function.
Мало того, что should -- наименее "должный" из всех английских глаголов "должен" (should, have to, must), так еще тут фигурирует слово "предпочесть".
Против этого правила я ничего не могу возразить так как оно действительно соответствует истине: "у вас должны быть причины, чтобы поместить такой метод в класс". Таких причин в этом топике было дано много и много еще будет дано.
A>>Программист страдающий амнезией? Занятно. IB>Это не занятно, это жизнь.
Общие слова. Иван, предоставь, пожалуйста пример когда прогаммисту нужно метаться от одного варианта к другому по несколько раз в неделю в течении месяца.
Здравствуйте, AndrewVK, Вы писали:
AVK>Мне вот кажется, что твоя ошибка в следующем — в начале ты зачем то абсолютизируешь обсуждаемое правило, а потом с этой абсолютизацией споришь.
Я в шоке от таких приемов ведения дискуссии.
Абсолютизировали его вы:
IB>Это не "прыжек в сторону". Андрюша уже писал об этом, как, впрочем, и я. Принцип сформулирован очень четко. Если метод использует только публичный контракт для работы с классом, значит он должен находиться вне класса. IB>Уже использует, понимаешь? Это данность, его так задизайнили, не важно по каким причинам. Если по каким либо причинам методу нужно использовать приватные данные, не важно по каким, дизайн ли, производительность ли, еще что-то, то его место внутри. IB>Все очень четко, конкретно, понятно и прозрачно. В данном случае части методов, из соображений производительности, нужно иметь доступ к внутреннему состоянию, значит их место внутри класса.
И я спорю именно с вашим возведением в абсолют, не с тараканами в моей голове которые это сделали.
Я 10 раз писал, что не согласен только с безусловностью данного правила.
Здравствуйте, Aikin, Вы писали:
A>Так что вообще свой фреймворк не развивать?
Где я такое сказал?
A>Посмотри на .net FW нет там обратной совместимости.
Ты серьезно?
A>5) Методы удаляются -- кто не заменил -- сам дурак, было дано куча времени. Этот "дурак" тебе платит деньги и каждый breaking change потенциально грозит потерей клиента.
A>Построил? -- Замчательно. A>Впарил клиенту? -- Значит с текущей версией библиотеки его приложение работает неплохо. A>Хочет исползовать новую версию библиотеки? -- А, зачем раз все работает и продается? A>Хочет развивать приложений? -- Ну тогда пусть изменяет пользователей измененного класса -- ему же лучше, так как новый дизайн удобнее.
Я уже расписывал Роме, как такой сценарий выглядит на практике. Тебе повторить?
A>Раз мы ведем этот спор, то для нас это неочевидно.
Для меня очевидно, что этот спор вы ведете уже из чистого упрямства, потому что возразить по делу нечего но все еще хочется.
A> Таких причин в этом топике было дано много
Таких причин, кроме "удобнее" не было дано ни одной. И это "удобнее" весьма сомнительный аргумент, в первую очередь потому, что еще не известно что удобнее.
A> и много еще будет дано.
Все обещаете...
A>Иван, предоставь, пожалуйста пример когда прогаммисту нужно метаться от одного варианта к другому по несколько раз в неделю в течении месяца.
Как ты себе представляешь этот пример? Подними историю любого своего приложения, и если будешь честен перед собой, то увидишь ровно эту картину..
Здравствуйте, adontz, Вы писали:
A>А я не сдаю назад, я же говорю, тут только ты впадаешь в крайности.
Причем тут мои крайности, ты тему-то не меняй..
A> На глазок ли? Ну не наобум, но да, в каждом конкретном случае решение может приниматься индивидуально, на основе личного опыта.
Ну, то есть, на глазок..
A>Конфигурационные файлы определённого формата могут быть непривычны.
У тебя проблемы с XML файлами? В третий раз спрашиваю, App.config — не жмет?
A>А за процесс обучения кто заплатил? КПСС?
Тот же, кто заплатит за изнурительное выпиливание по библиотеке с кривым дизайном и отлов в ней невынужденных ошибок.
, на которое я отвечал, слово HTML? Это тебе надо повнимательнее, мысли я читать не умею. И с HTML DOM, который в каком нибудь JavaScript доступен, мне знаком плохо и твои примеры мне ни о чем не говорят.
Здравствуйте, IB, Вы писали:
A>>Конфигурационные файлы определённого формата могут быть непривычны. IB>У тебя проблемы с XML файлами? В третий раз спрашиваю, App.config — не жмет?
То есть разницы между форматом XML и форматом конфигурационного файлы ты в упор не видишь.
A>>А за процесс обучения кто заплатил? КПСС? IB>Тот же, кто заплатит за изнурительное выпиливание по библиотеке с кривым дизайном и отлов в ней невынужденных ошибок.
Ай, неувязочка. За библиотеку платят один раз, а за обучение много раз.
Здравствуйте, AndrewVK, Вы писали:
AVK>Любая, я повторяю, любая причина, по которой метод не может быть оторван от класса без изменения реализации этого метода, является причиной того, что этот метод должен остаться в классе.
Вобщем, AndrewVK и IB, обсуждение вы слили. Ваша позиция постоянно меняется. На фоне общего хамства и угроз бана пропало всякое желание кому-то что-то объяснять. А всё что я хотел сказать по существу я сказал и так.
Здравствуйте, adontz, Вы писали:
A>>>Нужен знакомый. AVK>>Знакомый, простите, кому?
A>Тому, кто будет использовать.
То есть всем потенциальным пользователям? Отлично, ничего не скажешь.
A>HTML был на два сообщения выше и очень много раз.
Ну вот и не надо его приплетать, либо сразу оговаривай, о чем ты речь ведешь. По остальному, я так понимаю, возражений нет?
A>Ты уже через два сообщения забыл тему обсуждения?
Я ничего не забывал. Два сообщения назад никакого DOM еще не упоминалось.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Ziaw, Вы писали:
Z>И я спорю именно с вашим возведением в абсолют
Нет там никакого возведения. В приведенной цитате наоборот — явно упоминуто, что причины неважны.
Z>Я 10 раз писал, что не согласен только с безусловностью данного правила.
Не путай безусловность и возведение в абсолют, это не одно и то же. Правило обязано выполняться практически всегда, но это совсем не означает, что это единственное правилдо, которое определяет разнесение по методам. Вот в УК РФ — за грабеж тебя обязательно посадят, но это не единственная причина, по которой тебя могу посадить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1095 on Windows Vista 6.0.6001.65536>>
Здравствуйте, Aikin, Вы писали:
<...> A>Против этого правила я ничего не могу возразить так как оно действительно соответствует истине: "у вас должны быть причины, чтобы поместить такой метод в класс". Таких причин в этом топике было дано много и много еще будет дано.
На все эти причины ответом будет: поведение меняется намного чаще, чем данные.
Именно поэтому так популярна SOA(по аналогии — RDBMS vs OODB), где данные вообще живут отдельно, и изменение логики их не затрагивает. Попытка добавления к классу метода(выразимого существующими методами) автоматически добавляет классу новые обязанности. Самое противное — рано или поздно наступит момент когда это зашитое поведение нужно менять — это приводит к изменению интерфейса класса, со всеми вытекающими последствиями. Есть вероятность что этот момент может и не наступить, но она очень маленькая, поскольку с течением времени эволюционирут требования, изменяется предметная область и т.д. Это то самое место где применение "классического" OOP приводит к несоизмеримым затратам при сопровождении. В условиях постоянно изменяющихся требований необходимы методы которые упрощают эти изменения. Вот тут рулят любые техники(принципы =) ), позволяющие снизить связывание взаимодействующих компонентов. Проще быть готовым(по умолчанию применяя обсуждаемое правило(и не только его) к изменениям, чем производить масштабный "рефакторинг"(а по сути исправление архитектурных ляпов, которые можно было предвидеть) в будущем.
Здравствуйте, adontz, Вы писали:
A>То есть разницы между форматом XML и форматом конфигурационного файлы ты в упор не видишь.
Я не вижу какие проблемы может создать формат файла основаный на XML, с проверкой на соответствие схеме и полным автокомплитом.
app.config в этом плане реально менее удобен — с ним проблем нет?
A>Ай, неувязочка. За библиотеку платят один раз, а за обучение много раз.
Я вот примерно представляю, где у кого неувязочка..
Если ты считаешь, что при наличии автокомплита обучение не нужно, то оно конечно да.
А если по уму, то достаточно один раз принцип выучить, чем корячиться над каждой библиотекой.. Тяжело в учении — легко в продакшене.. =)
Здравствуйте, adontz, Вы писали:
A>Где я говорил это?
Прямо в предыдущем сообщении.. ) Если все понапихать в класс, то обучать не надо, а обучать не надо, потому, что методы и так подскажет автокомплит => автокомплит заменяет обучение.
Здравствуйте, adontz, Вы писали:
A>Наводит на мысль, что единого метода оценки качества кода как не было так и нет, а значит применять любой из существующих надо аккуратно.
Причем тут методы оценки? Это не методы оценки, это практики, следование которым помогает лучше и качественнее поддерживать код.
Здравствуйте, Ziaw, Вы писали:
Z>Практически каждый сторонник выноса всего подряд из класса кто приходит в эту ветку Z>сразу придумывает это неотразимый аргумент.
Если практически каждому приходящему в эту ветку, при взгляде на вашу аргументацию приходит эта мысль, может надо в консерватории что-то поправить? Может это у вас с аргументами что-то не так, если наблюдается такое трогательное единодушие — не было такой идеи? )
Здравствуйте, IB, Вы писали:
IB>Если практически каждому приходящему в эту ветку, при взгляде на вашу аргументацию приходит эта мысль, может надо в консерватории что-то поправить? Может это у вас с аргументами что-то не так, если наблюдается такое трогательное единодушие — не было такой идеи? )
Вобщем-то я вышел из дискуссии. Все что можно было из нее вынести я вынес. Если мои аргументы кого-то наводят на такие мысли я бы хотел увидеть эти аргументы и логическую цепочку рассуждений ведущих к вышеизложеной идее.
Пока не увижу, буду считать это не следствием наших аргументов, а попыткой бросить первый камень который попался под руку.
Здравствуйте, IB, Вы писали:
IB>Если практически каждому приходящему в эту ветку, при взгляде на вашу аргументацию приходит эта мысль, может надо в консерватории что-то поправить? Может это у вас с аргументами что-то не так, если наблюдается такое трогательное единодушие — не было такой идеи? )
А может каждый мерит на свой аршин и привык доволить любую идею: расщепление классов, слияние, до крайности.
Мы уже победили, просто это еще не так заметно...
