Фаулер хорошо понимает принципы проектирования, эт точно.
Кстати, это очень хорошо работает. Не нашел ни одного случая, где путем рефакторинга не удалось бы избавиться от комментариев и излишней запутанности кода.
Это не такая уж клиника, как может показаться.
Не каждый программист поддерживает чужие комментарии. Да и свои не всегда.
Поэтому, IMHO, лучше следовать мантре «Читай код».
Если вы, как менеджер по персоналу или владелец фирмы, вдруг читаете в чьем-то резюме слова о «5-6 лет опыта разработки», то знайте — их нельзя перевести как “опытный”. Это переводится так: чувствующий свою неуязвимость малолетка, с вероятностью 50 на 50 напишет вам кучу дерьма, в которой потом не разберется ни его команда, ни он сам, и которую он вероятнее всего не один раз будет переделывать. Но все это в порядке вещей — любой разработчик бывает подростком в своей профессиональной жизни.
Категорически не согласен с подобными высказываниями.
Здесь очень многое зависит от самоподготовки, и от того, что называть «5-6 лет опыта разработки». Я предпочитаю под этим понимать написание коммерческих приложений. Если же отсчитывать от точки начала программирования вообще… тогда, возможно, автор прав. И то не могу сказать с уверенностью, т.к. у многих программирование начинается с университета, а после выпуска они уже устраиваются на работу. Я шел немного другим путем, и программирование начинал до универа, поэтому мне сложно судить адекватно…
@Test
public void testSomeXmlGeneration() {
// здесь подготавливаются данные для генератора
String result = someModule.generateXML();
Diff diff = new Diff(getResourceAsString("/expeced_data.xml"), result);
assertTrue("XML результат не совпал", diff.similar());
Tools.showXmlDiff(diff);
}
assertTrue и Tools.showXmlDiff, IMNSHO, необходимо поменять местами.
Иначе в случае непрохождения теста, когда нам как раз и интересны различия в файлах, мы их не увидим, т.к. assertTrue выкинет исключение.
Зато у машины есть псевдослучайные генераторы случайных чисел.
И, в зависимости от характера случайной примеси, их можно считать более или менее случайными.
А сказать, насколько делека фантазия от случайных чисел, пока нельзя — не хватает знаний в данной области )
Согласен.
Компонентные движки на данный момент имеют два минуса:
1) Их компонентной базы не хватает под все множество задач.
2) Расширение компонентной базы обходится дорого, и, как правило, этим занимаются только те, кто разрабатывает framework.
На самом деле здесь не дублирование, а определение точек стыковки.
И, понятное дело, необходимо следить за соответствием имен в модели и в представлении.
К счастью, в наше время за соответствием следит IDE.
Да и программист не всегда верстальщик :-)
Конечно, базовые принципы он знать обязан, и проверить верстку должен уметь, мелкие фиксы сам сделать. Но сделать полноценную верстку — часто уже за пределами.
Не согласен.
Если разрешить использование в некоммерческих продуктах, то они могут очень быстро догнать коммерческий софт. В итоге коммерческий софт не успеет набрать обороты, т.е. даже не окупится.
Так что использование в некоммерческих продуктах логично разрешать также только после превышения срока действия патента.
Как, например, IE в свое время убил Netscape, хотя сам IE (в рамках Windows, логично) был бесплатен.
Или как FlashGet стал бесплатным довольно быстро после появления Download Master'а.
Я бы не сказал — очень уж много места отъедает.
Не говоря уже о том, что операция находится в отдельном блоке относительно аргументов, что очень сбивает с толку.
И — самое главное — семантика элементов управления не соответствует семантике условия, приходится переходить на другой уровень мышления.
Как пользователь я интуитивно формулирую выражение следующим образом:
«Хочу выбрать модели DIR-300 или DIR-320, полученные после 1.01.2011».
Соответственно, удобнее было бы формировать условие таким образом:
Дата получения | позже (не включительно) | 1.01.2011
И [
Модель | содержит | [
DIR-300
ИЛИ DIR-320
]
]
Следовательно:
Блоки И и ИЛИ разрешены не только для всей тройки целиком, но и для частей
И и ИЛИ используются в инфиксной форме (как в речи), а не в префиксной (функциональный стиль).
Кстати, это очень хорошо работает. Не нашел ни одного случая, где путем рефакторинга не удалось бы избавиться от комментариев и излишней запутанности кода.
Не каждый программист поддерживает чужие комментарии. Да и свои не всегда.
Поэтому, IMHO, лучше следовать мантре «Читай код».
Категорически не согласен с подобными высказываниями.
Здесь очень многое зависит от самоподготовки, и от того, что называть «5-6 лет опыта разработки». Я предпочитаю под этим понимать написание коммерческих приложений. Если же отсчитывать от точки начала программирования вообще… тогда, возможно, автор прав. И то не могу сказать с уверенностью, т.к. у многих программирование начинается с университета, а после выпуска они уже устраиваются на работу. Я шел немного другим путем, и программирование начинал до универа, поэтому мне сложно судить адекватно…
IMHO.
assertTrue и Tools.showXmlDiff, IMNSHO, необходимо поменять местами.
Иначе в случае непрохождения теста, когда нам как раз и интересны различия в файлах, мы их не увидим, т.к. assertTrue выкинет исключение.
И, в зависимости от характера случайной примеси, их можно считать более или менее случайными.
А сказать, насколько делека фантазия от случайных чисел, пока нельзя — не хватает знаний в данной области )
Компонентные движки на данный момент имеют два минуса:
1) Их компонентной базы не хватает под все множество задач.
2) Расширение компонентной базы обходится дорого, и, как правило, этим занимаются только те, кто разрабатывает framework.
И, понятное дело, необходимо следить за соответствием имен в модели и в представлении.
К счастью, в наше время за соответствием следит IDE.
Это дааа. Вытаскивать из колес палки, которые сам себе туда засунул — пренепреятнейшее занятие, в итоге желание засовывать палки в колеса отпадает.
Конечно, базовые принципы он знать обязан, и проверить верстку должен уметь, мелкие фиксы сам сделать. Но сделать полноценную верстку — часто уже за пределами.
Если разрешить использование в некоммерческих продуктах, то они могут очень быстро догнать коммерческий софт. В итоге коммерческий софт не успеет набрать обороты, т.е. даже не окупится.
Так что использование в некоммерческих продуктах логично разрешать также только после превышения срока действия патента.
Как, например, IE в свое время убил Netscape, хотя сам IE (в рамках Windows, логично) был бесплатен.
Или как FlashGet стал бесплатным довольно быстро после появления Download Master'а.
Numeric n = new Numeric().value(-10); Note r = new Note().bind(new Fork‹String›() .condition(new Toggle().less(n, -5)) .then("Frost") .otherwise(new Fork‹String›() .condition(new Toggle().less(n, +15)) .then("Cold") .otherwise(new Fork‹String›() .condition(new Toggle().less(n, +30)) .then("Warm") .otherwise("Hot") ))); r.value("Hot"); System.out.println(n.value()); // Что будет выведено?Я согласен, что это ДНФ, в этом меня убеждать не нужно.
При этом в комментарии фокус на минусах такого представления, а не на соответствии терминологии.
В частности, подобным образом задаются условия для сортировки писем в небезызвестном почтовике The BAT!
Не говоря уже о том, что операция находится в отдельном блоке относительно аргументов, что очень сбивает с толку.
И — самое главное — семантика элементов управления не соответствует семантике условия, приходится переходить на другой уровень мышления.
Как пользователь я интуитивно формулирую выражение следующим образом:
«Хочу выбрать модели DIR-300 или DIR-320, полученные после 1.01.2011».
Соответственно, удобнее было бы формировать условие таким образом:
Дата получения | позже (не включительно) | 1.01.2011 И [ Модель | содержит | [ DIR-300 ИЛИ DIR-320 ] ]Следовательно:
Например, A & (B | (C & D)) = A & (B | C) & (B | D) — условие B дублируется.
А то какое-то натянутое впечатление после применения команды «ping» для подбора пароля :-D