Про толстые контроллеры очень все верно сказано. У меня уже не первый случай, когда приходится сталкиваться с их появлением. Причем в некоторых случаях даже не знаешь, как подступиться к такому монстру, с чего начать рефакторинг.
Почему игнорит? Просто это не озвучено явно. Например, про проблемы тестирования сильно связанных модулей (верхняя правая картинка) — на мой взгляд, очень актуально для написания тестов. Особенно с учетом того, что интерфейсы и реализация таких модулей, по наблюдениям, меняются очень часто. Получается — для того, чтобы поддерживать тесты в идеальном состоянии, придется постоянно вносить в них изменения, поскольку изменяется не только реализация, но и интерфейсы взаимодействующих кусочков. То есть, мы хотим поменять что-то в интерфейсе программы, и у нас есть тест, который мы также вынуждены изменять (а изменение теста при изменении интерфейса равносильно написанию теста с нуля). Таким образом, написание тестов более оправдано в местах, где интерфейс является стабильным, а необходимо поддерживать в основном стабильность реализации.
С каждым новым появившимся движком все больше удивляюсь в том, насколько похожие у них API. Есть некий мир, есть тело, есть геометрия, геометрические объекты связываются, добавляются физические параметры по вкусу — и вуаля — мы получили RigidBody: ) Эти бодисы взаимодействуют при вызове StepSimulation (time). И в каждом движке тела, которые перестают двигаться — становятся неактивными, и их иногда приходится активизировать явно. Даже эта оптимизация уже стала классикой: ) Так приятно, что при переезде с одного движка на другой почти все кажется знакомым. Жаль только, что физические параметры вроде трения, упругости по-разному интерпретируются в различных движках, что приводит к отличиям в поведении даже на самых примитивных случаях.
Интересная метода с параллельными иерархиями.
Жаль только, что в макросе Q_DECLARE_PRIVATE используется reinterpret_cast.
Мне почему-то даже кажется, что есть способ извратиться с шаблонами и получить аналогичный результат без макросов и безопасный по отношению к типам.
Немного занудства:
Смысл в том что объявляется класс XXXPrivate и переменная публичного класса в защищенной секции. В отдельном заголовочном файле или в .cpp файле уже пишется объявление приватного класса
Во втором предложении точнее будет сказать «определение» (definition против declaration).
А вообще, интересная, похоже, штука — эта Qt. Надо будет обязательно тоже попробовать.
> преподаватель вуза… знать свой предмет как свои пять пальцев
Покажите мне такого препода. У нас таких нет. Вынужден констатировать, что преподаватели предметов, связанных с программированием (Языки высокого уровня, Программирование на Си, Технологии программирования, ООП, Реляционные базы данных) отстали в развитии лет на 10 минимум. К примеру, преподаватель технологий программирования и ооп (его специализация — ооп, java, c#, платформа .net) пишет абсолютно нулевые по уровню абстракции программы. В его программах классы наподобие Ball спокойно могут быть занаследованы от класса Form, и притом содержать в себе различные логически несвязанные филды (например, типа Thread). Зачем разделять логику представления и бизнес-логику? Это не для нас. Такие вот технологии программирования. Я не говорю уже о глубоком понимании (т.е. отсутствии понимания) механизмов работы платформы .net, на которой он якобы специализируется.
А ведь человек зрелого возраста, столько лет уже преподает.
А почему же тогда такой низкий уровень? Да по одной простой причине. А именно — из-за отсутствия какой бы-то ни было реальной практики разработки. Чему может научить человек, который не использовал инструменты в реальных проектах? Правильно. Только базовому синтаксису, который и так доступен обычным людям за неделю чтения мануала.
Вот и получается, что квалифицированным преподом может оказаться только молодой талантливый аспирант, который параллельно работает в профессиональной команде над реализацией настоящих проектов.
Так что если хотите преподавать и преподавать качественно — ни в коем случае не забивайте на реальное ежедневное программирование и проектирование.
Для вводной статьи было бы здорово написать, хотя бы вкратце, что это за устройства такие и где применяются. Я лично название «МК PIC16/18» вижу впервые.
Джобс надоел уже своими джинсиками и черным одеянием. Вечно один и тот же стиль, одни и те же декорации, одни и те же слова-завлекалки «easy, awesome, great». По-видимому, для большинства пользователей i-штучек этого хватает. Лично я пользуюсь счс iMac'ом и не вижу ничего особенного, что можно было бы описать этими словами. iPhone тоже — хорошая штука, но не более того. Хорошо еще, что он не описывает «элегантность» Objective-C в таких же терминах для разработчиков.
В принципе, ошибки такого плана возникают не так уж часто. Причем в более чем половине случаев с первого взгляда на строчку уже понятно, в чем проблема. А если не ясно — то можно и прочитать детали.
С другой стороны, может, кому-нибудь и пригодится.
Очень было бы интересно почитать про снятие защит с .NET программ. И еще интереснее — как лучше от этого защититься. Я так понимаю, намечается целый цикл статей. С нетерпением жду, удачи автору!
Хорошая метода, я аналогичным образом теоремы по матану учил на 1 курсе. Прочитал теорему — прописал. Прочитал еще одну — прописал вместе с первой. Только нужно следить, чтобы запоминалось равномерно, и если последние в такой «лесенке» еще не вошли в сознание, то изменить порядок.
Наша преподаватель, кстати, мысль, что для того, чтобы выучить формулу или теорему на отлично, ее следует прописать 5 раз. Соответственно, на троечку — достаточно 3 раза. Вообще, неплохо коррелирует с реальностью. :) Только опять же, лучше не подряд несколько раз прописывать одну и ту же формулу, а возвращаться к ней после изучения других вещей для большей эффективности.
Перечитал и понял вашу мысль. Сверху вниз — на уровне паблик интерфейса класса и снизу вверх — на уровне реализации. Раз вы акцентировали внимание на реализации, мне именно эта часть и запала в голову.
Хех, разве написание реализации при помощи копипаста и последующий рефакторинг не подразумевает методики «снизу вверх»?
Да, думаю рановато мне писать что-то конструктивное, раз я не разбираюсь в элементарнейших вещах, таких как всемогущество копипаста.
Не всегда идея проектирования снизу вверх подходит. В некоторых случаях лучше продумать архитектуру системы/подсистемы заранее, до написания кода.
Еще чаще приходится комбинировать оба подхода.
Только не совсем ясно, почему именно копипаст стал «лицом» идеи проектирования снизу вверх.
Жаль только, что в макросе Q_DECLARE_PRIVATE используется reinterpret_cast.
Мне почему-то даже кажется, что есть способ извратиться с шаблонами и получить аналогичный результат без макросов и безопасный по отношению к типам.
Немного занудства:
Во втором предложении точнее будет сказать «определение» (definition против declaration).
А вообще, интересная, похоже, штука — эта Qt. Надо будет обязательно тоже попробовать.
Покажите мне такого препода. У нас таких нет. Вынужден констатировать, что преподаватели предметов, связанных с программированием (Языки высокого уровня, Программирование на Си, Технологии программирования, ООП, Реляционные базы данных) отстали в развитии лет на 10 минимум. К примеру, преподаватель технологий программирования и ооп (его специализация — ооп, java, c#, платформа .net) пишет абсолютно нулевые по уровню абстракции программы. В его программах классы наподобие Ball спокойно могут быть занаследованы от класса Form, и притом содержать в себе различные логически несвязанные филды (например, типа Thread). Зачем разделять логику представления и бизнес-логику? Это не для нас. Такие вот технологии программирования. Я не говорю уже о глубоком понимании (т.е. отсутствии понимания) механизмов работы платформы .net, на которой он якобы специализируется.
А ведь человек зрелого возраста, столько лет уже преподает.
А почему же тогда такой низкий уровень? Да по одной простой причине. А именно — из-за отсутствия какой бы-то ни было реальной практики разработки. Чему может научить человек, который не использовал инструменты в реальных проектах? Правильно. Только базовому синтаксису, который и так доступен обычным людям за неделю чтения мануала.
Вот и получается, что квалифицированным преподом может оказаться только молодой талантливый аспирант, который параллельно работает в профессиональной команде над реализацией настоящих проектов.
Так что если хотите преподавать и преподавать качественно — ни в коем случае не забивайте на реальное ежедневное программирование и проектирование.
А перевод хороший получился, респект.
С другой стороны, может, кому-нибудь и пригодится.
«Дальше может находиться код, способный пошатнуть ваше психическое или душевное равновесие.»
вполне обыкновенный себе код…
Наша преподаватель, кстати, мысль, что для того, чтобы выучить формулу или теорему на отлично, ее следует прописать 5 раз. Соответственно, на троечку — достаточно 3 раза. Вообще, неплохо коррелирует с реальностью. :) Только опять же, лучше не подряд несколько раз прописывать одну и ту же формулу, а возвращаться к ней после изучения других вещей для большей эффективности.
Да, думаю рановато мне писать что-то конструктивное, раз я не разбираюсь в элементарнейших вещах, таких как всемогущество копипаста.
Еще чаще приходится комбинировать оба подхода.
Только не совсем ясно, почему именно копипаст стал «лицом» идеи проектирования снизу вверх.