Здравствуйте, moudrick, Вы писали:
ВН>>Интересная статья. Однако предпочитаю догматично следовать господам Саттеру и Александреску, которые утверждают что public-поля могут иметь только классы "без поведения". У них достаточно подробно расписано, почему лучше делать так. В частности, для целей отладки/тестирования и соблюдения инвариантов.
M>Господа, ну что вы прям как дети, извините...
M>Как только public/protected (or other non-private) поле M>становится непрозрачным для чтения и/или записи, M>мы немедленно применяем рефакторинг Encapsulate Field
M>В любой мало-мальски приличной среде программирования для любого мало-мальски приличного ОО языка имеются средства сделать это немедленно в одно движение.
Ага, в одно движение оббегаете несколько отделов. Спрашиваете у каждого, а не использует ли он Ваш класс в своём проекте. Переспрашиваете его ещё раз, что бы повысить достоверность. Потом в одно движение выкачиваете все эти проекты. В одно движение check-out'ите половину файлов проекта. В одно вдижение проводите рефакторинг. В одно движение заливаете всё это на обратно.
На следующий день всё равно получаете люлей за несобравшиееся проекты. Потому как всё равно никто не стал думать на вопрос "А используете ли в своём проекте...".
Причём это не единичный случай. Это — просто Ваш стиль работы.
... или просто меняете реализацию getter/setter. Решать каждому самому.
Здравствуйте, FDSC, Вы писали:
FDS>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов. Получается, что с небольшими комментариями этот код — самый удобный для написания и чтения (ну, лично для меня) и вызывает наименьшее число ошибок в использовании (собственно, ошибки в использовании функции перемножения перестали появляться вообще).
Для многих проектов (я не утвержаю, что для этого) такой стиль программирования — смерть.
ВСА>Авторы: ВСА> moudrick
ВСА>Аннотация: ВСА>Если Вы программируете как большинство, и даже, вероятно, все программисты (скромненько включая автора этой статьи), то ваш код — отстой. Возможно, не целиком; возможно, не всегда, но наверняка какая-то его часть и в какой-то момент времени.
Слепо и бездумно надерганная из классиков статья.
Лучше и полезней прочесть того же Макконнелла.
Re[3]: Тривиальная задача - как неотстойно написать?
Здравствуйте, moudrick, Вы писали:
FDS>>Можно вообще написать только внутреннее произведение и транспонировать матрицу — это не эффективно. M>Первейший вопрос от меня как работающего с тобой в паре — имеет ли значение эффективность на текущем этапе работы над задачей, учитывая ВСЁ? очень много проблеми возникает, когда начинаешь заниматься эффективностью раньше, чем она того заслуживает.
Очень много проблем (причём зачастую фатальных) возникает, когда эффективностью начинают заниматься слишком поздно.
Она заслуживает заниматься её ровно с того момента, когда в ТЗ появляется первое требование к ней, ровно как и другие требования.
<< Под музыку: Аквариум — Новая Песня О Родине >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Re[3]: Как спроектировать для автомат. тестирования?
Здравствуйте, moudrick, Вы писали:
M>Тиражы на рынках, в магазинах и инет магазинах закончились ((.
Проверил, так и есть...
M>А мне надо.
Нашел! второе сообщение сверху, вторая ссылка !
R>Ага, в одно движение оббегаете несколько отделов. Спрашиваете у каждого, а не использует ли он Ваш класс в своём проекте. Переспрашиваете его ещё раз, что бы повысить достоверность. Потом в одно движение выкачиваете все эти проекты. В одно движение check-out'ите половину файлов проекта. В одно вдижение проводите рефакторинг. В одно движение заливаете всё это на обратно. R>На следующий день всё равно получаете люлей за несобравшиееся проекты. Потому как всё равно никто не стал думать на вопрос "А используете ли в своём проекте...".
Возражение из серии: "а если завтра война?"
Библиотечный (публичный) код, используемый одновременно со своим развитием во многих проектах встречается не часто, и по отношению к нему применяются совершенно другие правила, чем к прикладному коду в контексте некоторой задачи. Причем этот самый прикладной код (не пуличный) по объему составляет подавляющую часть проектов и именно в этом коде геттеры/сеттеры совершенно не нужны (если понадобятся, они могут быть автоматически созданы одним нажатием на шорткат). То есть выходит, что геттеры/сеттеры не нужны в подавляющей части кода, следовательно, они там будут только мешаться.
Здравствуйте, prVovik, Вы писали:
V>Здравствуйте, remark, Вы писали:
R>>Ага, в одно движение оббегаете несколько отделов. Спрашиваете у каждого, а не использует ли он Ваш класс в своём проекте. Переспрашиваете его ещё раз, что бы повысить достоверность. Потом в одно движение выкачиваете все эти проекты. В одно движение check-out'ите половину файлов проекта. В одно вдижение проводите рефакторинг. В одно движение заливаете всё это на обратно. R>>На следующий день всё равно получаете люлей за несобравшиееся проекты. Потому как всё равно никто не стал думать на вопрос "А используете ли в своём проекте...".
V>Возражение из серии: "а если завтра война?" V>Библиотечный (публичный) код, используемый одновременно со своим развитием во многих проектах встречается не часто, и по отношению к нему применяются совершенно другие правила, чем к прикладному коду в контексте некоторой задачи. Причем этот самый прикладной код (не пуличный) по объему составляет подавляющую часть проектов и именно в этом коде геттеры/сеттеры совершенно не нужны (если понадобятся, они могут быть автоматически созданы одним нажатием на шорткат). То есть выходит, что геттеры/сеттеры не нужны в подавляющей части кода, следовательно, они там будут только мешаться.
Здравствуйте, FDSC, Вы писали:
FDS>>>В итоге я прихожу к самому удобному (я не шучу, я так и делал) варианту — когда нужно что-то перемножать я просто пишу код этого перемножения (цикл с двукратной вложенностью) прямо в код, без всяких вызовов.
K>> А я в этой ситуации использую макрос. Который, конечно же, компилируется в тот же самый код, что у вас. Только мой код читабельней и сопровождабельней вашего на пару порядков.
FDS>Макрос — та же функция — в плане чтения и написания. И она так же неудобна
Вы говорите полную чушь. Макрос это функция, которая генерит код. Пожалуйста, никогда больше не пытайтесь писать о том, в чём не разбираетесь.
Re[2]: Тривиальная задача - как неотстойно написать?
Здравствуйте, FDSC, Вы писали:
FDS>Вопрос по неотстойному написанию: допустим мне нужно написать код перемножения двух матриц.
FDS>Я могу его написать 4 функциями, соответствующими AijBjk; AjiBjk; AijBkj; AjiBkj; FDS>Но это будет дублирование кода, причём почти copy-paste — то есть код — отстой
FDS>Можно вообще написать только внутреннее произведение и транспонировать матрицу — это не эффективно.
FDS>А теперь представим себе, что это не просто матрица, а часть другой матрицы (это не надуманная задача). Тогда к каждой функции ещё надо будет прибавлять по два параметра — FDS>начальные и конечные индексы суммирования.
Напрашиваются прокси "подматрица" и "транспонированная матрица", не выполняющие копирования данных, а являющиеся шлюзами к исходной матрице.
Будет ли это на шаблонах или на виртуальных вызовах — дело хозяйское и зависит от языка. На шаблонах эффективность практически гарантирована.
Другое решение — таки написать мега-функцию с дополнительными параметрами (всё равно в цикле они участвуют — ну будет не от 0 до N, а от X1 до X2) и сокращённые формы к ней для типичных случаев использования.
Здравствуйте, moudrick, Вы писали:
L_S>>Набор слов без пояснения, доказательств, выводов... Цена такой статье = 0.
M>А свои мозги, чтобы делать выводы, мы уже не умеем применять?
M>Пояснений же в статье достаточно, только они достаточно компактны, и оттого производят на непосвященного впечатление их отсутствия.
M>Статья призвана обнажить проблему во всей ее красе, а выбрать путь ее разрешения — это дело целой серии книг. И не одной серии.
Статья отстой, цена == 0.
Какой то сборник прописных истин и не более того. Какую проблему она поднимает, какую проблему может поднять заповедь не укради . Может сдесь, кто-то и нашел для себя в этой статье, что-то стоящее, но, как-то мало вериться. А потом, вот на таком отстое начинаеться целая пляска по раскрутке серий отстояный книг типа "как завоевать друзей и при этом остаться настоящей подругой " а философию пытаться развести на пустом месте, это первый признак не проффесионализма, так как профессионал делает, а специалист думает как ему сделать лучше и пока он думает, профессионал уже все сделал, и не важно в принципе как он сделал, главное чтобы это работало и полностью удовлетворяло заказчика, так как программирование уже давно из искуство превратилось в ремесло. Еще Генри Форд сказал: "Если я захочу нагадить конкурентам, то я им проплачу сто спечиалистов, которые приведут 1000 причин почему это нельзя делать или почему это необходимо делать именно так." Читайте классиков госпада
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Вернее — сразу диагностировать поломку. Предотвратить её юнит-тесты не могут.
Как-то вы странно понимаете TDD.. Это не автоматическое тестирование
TDD и юниттесты — это
1. способ описать, что конкретно будет делать код. Не в терминах классов, domain models etc, а в совершенно конкретных вещах — берем на входе a,b,c — получаем на выходе d,e,f. Не больше, но и не меньше. Не надо писать "на будущее", надо только то, что надо.
2. юниттесты — это не способ тестить приложение, этим занимаются тестеры. Юниттесты — это снапшот кода, работающего по описанным правилам.
3. Не тесты пишутся под код, а код под тесты. Это заставляет тщательно продумывать, чего, собственно, должен делать код, на совершенно конкретных примерах и ситуациях.
А то в большинстве случаев программирование сводится к
"Высоко-высоко над Небесным Градом, на небольшой площадке, венчающей
собою верхушку Шпиля Высотою в Милю, стоял Владыка Иллюзий, Мара-Сновидец.
Одет он был в плащ всех цветов — и не только радуги. Воздел он над головой
руки, и, сливаясь воедино с собственной силой, хлынула через его тело мощь
всех остальных богов.
В уме его обретала форму греза. И излил он ее наружу, как разливается
по пляжу накатившаяся на берег высокая волна." (c) понятно кто
Изливаем в редактор грезу вместо того, чтобы сделать работу.
A>Если бы юнит-тесты были панацеей, то профессия тестировщика (QA Engineer) уже давно канула бы в лету, но нет, они живы-здоворы и неплохо зарабатывают Что, тестеров нанимают только те, кто не умеет пользоватся юнит-тестами? А может надо признать что тезис "код не проходящий регулярное юнит-тестирование — отстой" сам является отстоем?
Ваше суждение исходит из непонимания того, что есть unit-testы
Темы для чтения:
unit-testы, их определение, назначение и ограничения.
Перекуём баги на фичи!
. Может сдесь, кто-то и нашел для себя в этой статье, что-то стоящее, но, как-то мало вериться. А потом, вот на таком отстое начинаеться целая пляска по раскрутке серий отстояный книг типа "как завоевать друзей и при этом остаться настоящей подругой 
