Вся книга написана в полуразговорном стиле, с постоянными попытками пошутить (да, они не всегда смешны и уместны) и рассказать о паттернах максимально доступным языком. Иногда это звучит неоднозначно, но мысли заложены очень толковые:
Programming stuff
И небольшое продолжение: о паттернах и просветленном разуме
11.05.201210:5611.05.2012 10:56:17
Вся книга написана в полуразговорном стиле, с постоянными попытками пошутить (да, они не всегда смешны и уместны) и рассказать о паттернах максимально доступным языком. Иногда это звучит неоднозначно, но мысли заложены очень толковые:
О паттернах из Head First Design Patterns
11.05.201210:5111.05.2012 10:51:36
В целом впечатление положительное, хотя после книги Мейера разница ощущается уж очень серьезная.
Инициализаторы объектов в блоке using
10.05.201213:1010.05.2012 13:10:56
О публичных и опубликованных интерфейсах.
05.05.201212:3305.05.2012 12:33:10
"Лестничное остроумие" (очередные интересные мысли из книги Бертрана Мейера)
26.04.201207:4026.04.2012 07:40:27
О повторном использовании кода
20.04.201214:0220.04.2012 14:02:26
Видеоматериалы, блоги и подкасты для .NET разработчика
11.04.201210:1411.04.2012 10:14:20
В одной из своих статей Бьёрн Страуструп (папа С++) признался, что он не признает видеоматериалы в качестве источника для самообразования. И с ним сложно не согласиться, когда речь касается изучения с нуля языка программирования или технологии. Я правда сомневаюсь, что можно одолеть такого монстра, как С++, или стать гуру WPF лежа на диване и просматривая обучающее видео типа «Узнай все за 24 часа». Но если вы ставите себе цель познакомиться с некоторой технологией или новой возможностью языка программирования, или просто послушать философско-компьютерные размышления умного товарища, то в этом случае веб-касты, записи конференций или другой вид видеоматериалов может быть очень кстати.
Что значат для вас юнит-тесты?
06.04.201207:4306.04.2012 07:43:05
Замыкание на переменных цикла в C# 5.0
04.04.201210:4304.04.2012 10:43:38
Бертран Мейер. Объектно-ориентированное конструирование программных систем
20.03.201213:4320.03.2012 13:43:04
DISCLAIMER: более навороченной книги по ООП в природе нет и в ближайшее время, скорее всего, не будет; эта книга заслуженно считается по объектной технологии и не зря является первой в списке рекомендуемых книг по этой теме (причем она первая не только в моем списке).
15 возможностей ReSharper-а для навигации и редактирования
16.03.201213:2816.03.2012 13:28:17
Энди Хант и Дейв Томас «Программист-прагматик. Путь от подмастерья к мастеру»
Наследование интерфейсов и контракты
13.03.201215:5813.03.2012 15:58:21
Альтернативная проверка предусловий в Code Contracts
13.03.201208:5013.03.2012 08:50:32
Принцип замещения Лисков и контракт
05.03.201211:0205.03.2012 11:02:41
Повторное использование знаний
14.02.201213:5614.02.2012 13:56:27
Об иерархиях наследования
13.02.201213:0913.02.2012 13:09:51
Цитата
| Произвольно или нет, но многие учебные презентации создают впечатление, что структуру наследования следует проектировать от наиболее общего (верхней ее части) к более специфическим частям (листьям). В частности, это происходит потому, что лучший способ описать существующую структуру – это идти от общего к частному, от фигур к замкнутым фигурам, затем к многоугольникам, прямоугольникам, квадратам. Но лучший способ описания структуры вовсе не означает, что он является и лучшим способом ее создания.
В идеальном мире, населенном совершенными людьми, мы бы сразу же обнаруживали правильные абстракции, выводили бы из них категории, их подкатегории и так далее. В реальном мире, однако, мы часто вначале обнаруживаем частный случай и лишь потом открываем общую абстракцию. |
Attached свойства для ограничения текстового ввода
08.02.201213:4108.02.2012 13:41:02
Одной из таких задач является ограничение ввода пользователем определенных данных. Например, мы хотим, чтобы в некоторое текстовое поле можно было вводить только целочисленные значения, а в другое – дату в определенном формате, а в третье – только числа с плавающей запятой. Конечно, окончательная валидация подобных значений все равно будет происходить во вью-моделях, но подобные ограничения на ввод делают пользовательский интерфейс более дружественным.
В Windows Forms эта задача решалась довольно легко, а когда в распоряжении был тот же TextBox от DevExpress со встроенной возможностью ограничения ввода с помощью регулярных выражений, то все было вообще просто. Примеров решения этой же задачи в WPF , большинство из которых сводится к одному из двух вариантов: использование наследника класса или добавление с нужными ограничениями.
18 фактов о Джоне Ските
03.02.201208:4603.02.2012 08:46:00
Чтобы рассказать о том, кто есть Джон и что он сделал для индустрии, достаточно привести о нем несколько фактов. Многие слышали , такие как «Чак Норрис досчитал до бесконечности. Дважды» или что «Чак Норрис – единственный человек, который обыграл стену в теннис». Но далеко не все знают о том, что подобные факты есть и о Джоне Ските (сам факт существования которых уже о многом говорит).
Сказка о повторном использовании
01.02.201210:2001.02.2012 10:20:00
Об изучении языков программирования
19.01.201209:4019.01.2012 09:40:56
Цитата
| Язык, который не влияет на ваш способ мышления, не стоит изучения.
Алан Перлис |
Влияние психологии команды на архитектуру
18.01.201210:1718.01.2012 10:17:38
The Art of Unit Testing
13.01.201213:3513.01.2012 13:35:26
Ретроспектива 2011
11.01.201209:0111.01.2012 09:01:25
Стабы и моки
20.12.201110:4620.12.2011 10:46:32
Это самый простой и эффективный способ тестирования, и любой толковый дизайн отталкивается от подобных классов, которые являются «строительными блоками» нижнего уровня, на основе которых затем уже строятся более сложные абстракции. Но классов, которые живут в такой «изоляции», немного по своей природе. Даже если мы по нормальному выделили всю логику по работе с базой данных (или сервисом) в отдельный класс (или набор классов), то рано или поздно появится кто-то, кто эти классы будет использовать для получения более высокоуровневого поведения, и этого «кого-то» тоже нужно будет тестировать.
Кто такой «хороший программист»?
02.12.201108:5902.12.2011 08:59:25
Идеальная архитектура
25.11.201109:2425.11.2011 09:24:51
Другие, наоборот, считают, что «думать уже поздно» и давным-давно пора «делать», поэтому они кидаются на баррикады с криками «Ура», выдавая на гора тонны никому не нужного кода. Как и любая крайность, такой подход не приводит ни к чему хорошему. Но, как и во многих других случаях, существует промежуточный вариант, когда проектированию и архитектуре уделяется должное внимание, когда они не ставятся во главу угла, а используются для выявления правильных абстракций и поиска компромиссов в противоречивых требованиях заказчика.
Observable.Generate и перечисление списков
23.11.201109:0023.11.2011 09:00:33
Код
IObservable<string> xs = Observable.Generate<int, string>(
initialState: 0, // начальное значение
condition: x => x < 10, // условие завершения генерации
iterate: x => x + 1, // изменение значения
resultSelector: x => x.ToString() // преобразование текущего значения в результат
); xs.Subscribe(x=> Console.WriteLine("x: {0}",x)); |
ПРИМЕЧАНИЕ
Обратите внимание на явное указание параметров обобщенного метода. Причина такого странного поведения (ведь обобщенные параметры методов должны спокойно выводиться компилятором) в том, что в компиляторе языка C# есть известный баг, в результате которого вывод типов плохо дружит с именованными параметрами. Подробнее об этом можно почитать на или на . Да, кстати, это дело пофиксили в Visual Studio 11.
Повторная генерация исключений
16.11.201109:0716.11.2011 09:07:37
Дополнительную сложность добавляют конкретные платформы и языки программирования. Сегодня на собеседовании C# разработчика, когда речь заходит об обработке исключений, обязательно прозвучит вопрос: «А в чем отличие «проброса» исключения с помощью конструкций throw; и throw ex;?». И хотя, это страшный баян, и большинство разработчиков давно знают правильный ответ на этот вопрос, в реальном коде встретить «некошерный» вариант очень даже просто.
Проблемы передачи списка перечислений или Почему абстракции «текут»?
15.11.201113:3515.11.2011 13:35:35
Джоэл Спольски (Закон дырявых абстракций)
А иногда дырявятся и довольно простые абстракции.
Автор этой статьи
Большинство современных разработчиков знакомы с «законом дырявых абстракций» по Джоэла Спольски с одноименным названием. Заключается этот закон в том, что как бы ни был хорош протокол взаимодействия, фреймворк или набор классов, моделирующих предметную область, рано или поздно нам приходится спускаться на уровень ниже и разбираться с тем, как же эта абстракция устроена. Внутреннее устройство абстракции должно быть проблемой самой абстракции, но возможно это только в наиболее общих случаях и лишь до тех пор, пока все идет хорошо (*).
Когда-то давно, в «небольшой» мелкомягкой компании решили, а почему бы нам не «абстрагироваться» от местоположения объекта и сделать сам факт того, является ли объект локальным или удаленным, лишь «деталью реализации». Так появились технологии DCOM и ее наследник .NET Remoting, которые скрывали от разработчика, является ли объект удаленным или нет. При этом появились все эти «прозрачные прокси», которые позволяли работать с удаленным объектом, даже не зная об этом. Однако со временем выяснилось, что эта информация архиважна для разработчика, поскольку удаленный объект может генерировать совершенно другой перечень исключений, да и стоимость работы с ним несравнимо выше, чем взаимодействие с локальным объектом.
Dispose pattern
03.10.201108:3103.10.2011 08:31:06
что так делают все или так где-то написано.
Мысли автора статьи во время чтения и рефакторинга чужого кода
Ни для кого не будет секретом, что платформа .NET поддерживает автоматическое управление памятью. Это значит, что если вы создадите объект с помощью ключевого слова new, то вам не нужно будет самостоятельно заботиться о его освобождении. Сборщик мусора определит «достижимость» объекта, и если на объект не осталось корневых ссылок, то он будет освобожден. Однако, как только речь заходит о ресурсах, таких как сокет, буфер неуправляемой памяти, дескриптор операционной системы и т.д., то сборщик мусора, по большому счету, умывает руки и весь «головняк» по работе с такими ресурсами ложится на плечи разработчика.
«А как же финализаторы?» – спросите вы. Ну,да, есть такое дело, финализаторы действительно предназначены для освобождения ресурсов, но проблема в том, что время их вызова не детерминировано, а это значит, что никто не знает, когда они будут вызваны и будут ли вызваны вообще. Да и порядок вызова финализаторов не определен, поэтому при вызове финализатора некоторые «части» вашего объекта уже могут быть «разрушены», поскольку их финализаторы уже были вызваны. В общем, финализаторы – они-то есть, но это скорее «страховочный трос», а не нормальное средство управления ресурсами.
Еще раз о повторном использовании
15.09.201108:2215.09.2011 08:22:00
Цитата
| «Поднаторевшие в объектно-ориентированном проектировании разработчики скажут вам, что обеспечить «правильный», то есть в достаточной мере гибкий и пригодный для повторного использования дизайн, с первого раза трудно, если вообще возможно. Прежде чем считать цель достигнутой, они обычно пытаются опробовать найденное решение на нескольких задачах, и каждый раз модифицируют его». |
Эрик Липперт, один из разработчиков компилятора C#, очень часто говорит о проблеме «преждевременного обобщения» (premature generalization), с которой я, например, сталкиваюсь постоянно.
Принцип самурая
14.09.201112:0114.09.2011 12:01:38
Еще одной метафорой, или скорее принципом разработки, является «принцип самурая», призванный описать «контракт» между функцией и вызывающим ее кодом и заключается в следующем. Любая функция, реализующая некоторую единицу работы должна следовать тому же кодексу чести «бусидо», по которому живет любой самурай. Так, самурай не будет выполнять никаких заданий, противоречащих его «кодексу чести» и если к нему подойти с «непристойным» предложением, то он снесет вам башку раньше, чем вы успеете глазом моргнуть. Но если уж самурай возьмется за дело, то можно быть уверенным в том, что он доведет его до конца (**).
Вы, конечно, шутите, мистер Фейнман
07.09.201108:4807.09.2011 08:48:40
Wanted! Старые хиты Эрика Липперта
01.09.201111:4301.09.2011 11:43:34
Занимаюсь я этим делом вот уже и ни разу не пожалел потраченного времени. Я надеюсь, что чтение статей Эрика на русском языке доставляет хоть малую толику того удовольствия, которое я получаю при переводе!
Неявно типизированные поля в C#
30.08.201116:0830.08.2011 16:08:43
На самом деле, такое положение дел вовсе не случайно; так что давайте рассмотрим несколько причин, почему компилятор ведет себя именно так, а не иначе.
О книге “MS Visual C++ 2010 в среде .NET. Библиотека программиста”
29.08.201112:1029.08.2011 12:10:53
Effective Concurrency от Герба Саттера
18.08.201113:0018.08.2011 13:00:50
Но именно в данном случае интересно не это. Сегодня я отправил Гербу мыло с просьбой разрешить перевод и публикацию у себя в блоге его серии статей Effective Concurrency, и получил от него ответ через 40 (!) минут. То что ответ был отрицательным, это уже второе, но сам факт, что такие люди отвечают столь оперативно не может не радовать.
Гарантии безопасности исключений
16.08.201112:5316.08.2011 12:53:20
Существует множество точек зрения о том, что же такое «правильно», большая часть из которых сводится к тому, что нужно перехватывать только те исключения, которые ты можешь обработать, а все остальные пробрасывать вызывающему коду. Ну, а в случае, если на верхний уровень пробралось дерзким образом непонятное исключение, то стрелять все приложение целиком, поскольку уже не понятно, находится ли оно, родимое, в согласованном состоянии или нет.
О синглтонах и статических конструкторах
03.08.201108:5503.08.2011 08:55:53
О вреде изменяемых значимых типов
20.07.201111:5220.07.2011 11:52:19
