четверг, 13 июня 2013 г.

О пользовательских преобразованиях типов

Поскольку мне говорят (точнее пишут), что я немного утомил с философией программирования и стоит браться за ум вспомнить и о технологиях, то я решил не откладывать это дело в долгий ящик, и опубликовать несколько заметок о языке C#. Тем более, что после подготовки к Hot Code остались некоторые наработки, которыми будет интересно поделиться.

Итак, у нас есть структура BigDouble с оператором неявного приведения типов к double и список этих структур:

struct BigDouble
{
private readonly double
_value;

public BigDouble(double
value) { _value = value; }
public static implicit operator double
(BigDouble value)
{
return
value._value; }
}


var bigDoubles = new List
<BigDouble>
{
new
BigDouble(42.0),
new BigDouble(18.0),
};

Вопрос #1. Будет ли работать следующий цикл foreach?
foreach (double d in bigDoubles)
{
   
Console.WriteLine(d);
}
Вопрос #2. Что мы получим в следующих случаях?
var query = from double d in bigDoubles
           
select
d;

foreach (var d in query) { Console.WriteLine(d); }

вторник, 4 июня 2013 г.

О книге Боба Мартина “Чистый код”

image

(Картинка без намека, просто уж очень хотелось котика в статью добавить! Ведь это основной залог популярности в интернетах, правда? :))

У меня очень неоднозначное отношение к книгам Роберта Мартина… В них довольно много здравых и интересных мыслей, но иногда они выражаются столь категорично, что неокрепшим программерским мозгом они могут восприниматься неправильно. Если же мозг читателя достаточно окреп, чтобы воспринимать советы прагматично, то есть все шансы, что ничего нового из этих советов он (мозг или программист) не вынесет.

 

понедельник, 27 мая 2013 г.

О комментариях. Часть 2

В прошлый раз мы рассмотрели основные подходы к комментированию кода, а в этот раз я хочу рассмотреть эти советы на простых практических примерах.

1. Комментарии из серии «ни о чем». Или зачем дублировать код?

Основные претензии к комментариям заключаются в том, что они устаревают или просто дублируют код, описывая его на том же уровне абстракции, что и сам код. Ниже представлен утрированный антипаттерн:

понедельник, 20 мая 2013 г.

О комментариях

"Не стоит относиться к комментариям как к "абсолютному добру". На самом деле, комментарии в лучшем случае являются неизбежным злом. Если бы языки программирования были достаточно выразительными или если бы мы умели искусно пользоваться этими языками для выражения своих намерений, то потребность в комментариях резко снизилась бы, а может быть и вовсе сошла "на нет".
Роберт Мартин "Чистый код"

"Комментарии должны сообщать о коде что-то такое, что он не может сообщить он сам – в виде заключения или в виде намерений".
Стив Макконнелл "Совершенный код"

clip_image002

понедельник, 13 мая 2013 г.

Пример тестируемого дизайна

В комментариях к предыдущей заметке был задан такой вопрос:

«Вот есть, сккажем, класс, который читает какой-нибудь файл и потом его анализирует. Как такое тестировать?

Неужели надо вынести код чтения файла в отдельный класс, создать интерфейс и передать экземпляр через конструктор? Боюсь, если так буду делать, то не закончу и половины вовремя.»

Здесь очень мало информации, поэтому все мои рассуждения можно использовать лишь в качестве отправной точки дизайна и реализации. Любой исходный дизайн эволюционирует по мере развития требований и понимания задачи, но определенные подходы применимы даже при таком наборе «входных данных».

среда, 8 мая 2013 г.

Как тестировать закрытые методы?

В комментариях к одной из заметок в Г+ мне предложили рассказать о тестировании закрытых методов. Поскольку это интересная тема, то в сегодня я постараюсь ответить на этот вопрос.

Q: - Как тестировать закрытые методы?
A: - Напрямую – никак!

Ну а теперь давайте поговорим об этом более подробно.

суббота, 27 апреля 2013 г.

Дизайн и борьба со сложностью

Многие мыслители сходятся на том, что главной целью дизайна является борьба со сложностью. Разбиение приложения на слои, переход от наследования к агрегации, создание приложения из хорошо работающих и проверенных блоков более низкого уровня, все это позволяет смягчить неотъемлемую сложность системы и свести случайную (или привнесенную) сложность к минимуму.