Архитектура программ и прибыль

Архитектура программ напрямую определяет прибыль, которую можно получить от заказчика за разработку программы. Чем лучше архитектура, тем больше прибыль и меньше проблем.

Задача архитектора – создать архитектуру достаточно гибкую и модифицируемую, но не чрезмерно гибкую. Обе границы гибкости грозят проблемами и неприятностями.

Слишком жесткая архитектура будет дорого стоить при модификации (тут мы сильно отличаемся от строителей – в программы часто требуется добавлять новую функциональность). Например, наша программа берет данные из MS Excel 2007. Все работало замечательно, пока не вышла версия MS Excel 2010. Конечно, заказчик хочет добавить в систему поддержку новой версии и вот тут его и ждет сюрприз. Архитектор системы настолько жестко привязался к бинарному формату версии 2007, что для поддержки XML формата версии 2010 требуется фактически переписать всю систему заново. И цена этой работы получится соответствующая – как минимум больше половины стоимости исходной работы. Я думаю, вы будете примерно также удивлены, если вам скажут, что на вашу машину не ставятся зимние шипованные колеса и для того, чтобы можно было ездить зимой, нужно поменять всю машину или, как минимум, кузов и привода. "Кое-что из приборов и руль, наверное, получится не трогать, но остальное точно под замену", ‑ уверенно сообщает вам мастер на авто-сервисе.

Обратный вариант – слишком гибкая архитектура – тоже ничем хорошим не светит. Вы просили сделать вам автомобиль, а получили самолет-амфибию с возможностью ездить по дорогам. Ну т.е. ездить он, конечно, может. Но вот цена… ну и еще – чтобы по дорогам ехать нужно "немного сконфигурировать систему" – колеса привинтить, крылья отвинтить. "Не сложно, не переживайте, да и инструкция же есть. Да, вы этого не просили, но нам так было удобнее – вот будут у нас другие клиенты, а у нас уже готовы и самолет и корабль. Правда, нужно их немного доработать…" Хотя конечно, уверенности что новые клиенты будут, нет. С таким-то подходом… Меня очень напрягают программы, которые для своей работы требуют от меня совершенно не нужных мне действий, но это немного другой разговор, до него мы еще доберемся. Пока же я думаю, основную идею вы поняли – слишком гибко тоже плохо. Обычно это дорого и неудобно.

Хорошая архитектура – где-то посередине. Достаточно гибко, чтобы можно было модифицировать, но в рамках разумной гибкости, чтобы не было дорого и было удобно. Как это влияет на прибыль, наверное, очевидно.

Нечетные числа

Чаще всего я вижу что проверку что число четное делают так:

 if (n % 2 == 0)

Тут проблем нет. А вот с нечетным часто получается засада. Проверка

 if (n % 2 == 1)

не работает для отрицательных числел, т.к. результатом n%2 для отрицательных нечетных чисел будет -1, а не 1. Но об этом постоянно забывают.

Правильно писать (n%2 != 0).

А вообще проще и надежнее проверять последний бит (n & 1 == 1). Да и выполняется эта операция быстрее. Но тогда нужно рассказывать студентам про биты... :)

Стиль кодирования

Что такое стиль кодирования

Конечно, все из вас читают книги, газеты и журналы. Что важно для понимания сути текста или статьи? Наверное, в первую очередь, это понятность изложения (конечно, я не рассматриваю случай, когда статья написана на незнакомом вам языке или в ней изложен материал из совсем не знакомой вам области). То же самое касается и устной речи. Путанный, сбивчивый рассказ очень сложно понять. Бывает и так, что понять о чем хотел сказать автор и вовсе не получается и хорошо, если он близко и можно его переспросить.

Наверное, все в школе писали сочинения. Так вот, сочинение, или, другими словами, изложение своих мыслей на бумаге, ничем не отличается от написания кода! Код – это такое же изложение мыслей, только вместо букв русского языка используются специальные коды. Ведь даже название соответствует – язык программирования.

А кто несет ответственность за то, что написанное будет понятным и даже интересным для читателей? Очевидно, что автор текста. Аналогично автор кода несет ответственность за его понятность для своих коллег.

При написании текста у вас нет никаких шансов обойти правила грамматики и правила оформления текста, если конечно вы хотите, чтобы ваш труд читали. Вы соблюдаете падежи, расставляете знаки препинания, выделяете абзацы. Если текст большой, вы разбиваете его на главы, параграфы и т.д. Глядя на текст, записанный без знаков препинания и единым монолитным блоком, на меня накатывает такая тоска, что и читать его не хочется. Написание кода не отличается ничем. Правда желающих увильнуть от правил оформления и написания кода значительно больше. Кто-то пытается написать код в один блок, а то и в одну строку… Кто-то экономит место в тексте сокращая имена и названия переменных до совершенно не понятных… А ведь даже простое разделение кода на блоки с помощью пустых строк, значительно упрощает чтение кода, как разбиение на абзацы упрощает чтение текста.

Правила написания кода называются стилем кодирования (code style). О нем я и хочу поговорить в этой лекции.

Почему важно писать код понятно

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

Если вы пишите код для себя, просто из интереса – пишите как хотите, лишь бы вам было приятно. Если же вы работаете в команде, то пишите по правилам. Почему? Представьте, что вы написали насколько удивительный и прекрасный код, что на его понимание вашему коллеге потребовалось полчаса времени. А в проекте работает 10 человек. И вот на один кусочек кода 300 минут рабочего времени улетело в трубу. Еще один такой кусочек – еще столько же. А в рамках большого проекта эта цифра вырастает в дни и недели, и прибыль, как я рассказывал, утекает прямо из рук. Причем ничем не обоснованно. Просто вы так написали код.

Кто не согласен считать деньги, просто представьте себя на месте пациента, которому врач говорит, что не может его полечить, так как его лечащий врач ушел в отпуск, а в карточке болезни записал такое, что и понять нельзя. Или надо еще раз пройти все анализы или ждать, пока ваш врач выйдет из отпуска. Мне кажется, это не очень-то хорошо и приятно. А легко ли будет новому человеку, пришедшему в ваш проект, влиться в команду и начать приносить пользу? А легко ли будет заменить вас на проекте на время вашего отпуска? Если нет, значит это ваша проблема в первую очередь. Если, конечно, вы собираетесь вообще ходить в отпуск и не собираетесь работать на одном и том же проекте годами (а проекты, бывает, идут и по десятку лет!).

Очень хочу чтобы вы поняли меня правильно. Я не говорю, что нужно писать такие примитивные книги, чтобы их понял кто угодно, даже тот, кто не в теме. Я не говорю, что нужно писать такой код, чтобы было понятно даже школьнику. Вовсе нет. Я надеюсь, вы понимаете, чем отличается "примитивно" от "понятно" и "интересно". С кодом то же самое: код должен быть понятен и прост, но не примитивен.

Права

Точки-с-запятой и скобки

Некоторым студентам так понравилось ставить точки-с-занятой после конца строки, что они подошли к вопросу с излишним фанатизмом.
В результате получаются такие конструкции:

if (a == b);
{
  // выполнится не зависимо от условия
}

Или так:

for (int i=0; i<10; i++);
{
   // выполнится один раз, без цикла
}

Ну и со скобками в блоках конечно тоже беда:

for (int i=0; i<10; i++)
  a++;
  b++;

К сожалению, выравнивания еще мало - надо бы еще скобки блока поставить. Иначе b++ в цикл не войдет.

Особенности сравнения float.NaN

float.NaN - специальное обозначение бесконечности. Но нужно помнить, что две бесконечности не равны по определению. Да и по спецификации тоже.
Т.е.
 float f = float.NaN;
 if (f == float.NaN)
 {
    // никогда не выполнится
 }

Для правильного сравнения используйте float.IsNaN(f).

Зачем переписывать у соседа код?

Замечаю что многие студенты вместо того чтобы писать программу сами, переписывают ее у соседа с экрана. Я не возражаю - если хочется работать секретарем/секретаршей, то почему не поучиться быстро набирать на клавиатуре текст? Но какое это отношение имеет к программированию понять не могу.

Представил себе занятия по плаванию - стою я на суше, махаю руками, делаю точно также как тот, который в воде барахтается... Интересно - научусь или нет? Что-то сомнительно.... Или в качалке - один потеет, железки таскает, другой повторяет движения... Возможно даже какой-то результат и будет, но совсем не такой, как у того, который сам.

Мой совет - пишите код сами. Лучше взять задачку попроще и сделать ее. Потом взять сложнее, потом еще сложнее... Ни кто же не гонит, не торопит. Зачем хватать очень сложную задачу, понимая что ее не выполнить и этим оправдывать свое бездействие.

В той же качалке - берем сразу огромный вес, который придавит. Зовем здоровенного качка, просим "подними за меня, я не могу". Ну он-то понятно поднимет, может даже и не вспотеет, здоровый он. А вам-то что с этого толку? Даже морального удовольствия нет...

Цитата

Если спросите, то будете дураком 5 минут, а если не спросите, то всю жизнь

Снова про code style...

Еще раз хочу про стиль кода написать. Замучился доказывать, что писать надо в едином стиле. Вот если кино начинается комедией, а заканчивается детективом, все плюются… Если в часть главы в книге написано от первого лица, а потом резко так, без перехода от третьего – странно все это выглядит. Возникает вопрос что курил автор. А если код так писать, почему-то нормально.

Второй вопрос – заглавные буквы. Заглавная буква это начало мысли, начало чего-то большого, обозначение идеи. Название городов пишут с большой буквы, имена людей и т.д. Но если взять и Просто так начать Писать часть слов Не понятно зачем писать с Большой буквы, то читать это сложно. Ну и про автора такого текста мысли какие-то бродят.. Так почему нужно писать имена переменных именно так:

  private int MyTempVar;

Почему с большой буквы-то? Имя метода (имя человека, города) – это понятно. А тут-то зачем? И читать такой код сложно, хотя можно конечно.

Вообще загадочно, почему то что в обычной жизни никто не делает, в программировании считается нормальным и до хрипоты спорят что можно и так.

События

События (event) это почти делегаты, только используется ключевое слово event, что позволяет редактору Visual Studio правильно распределять их по закладкам окна свойств.

Описание класса, использующего события:

namespace EventTest

{

    /// <summary>

    /// Тип метода

    /// </summary>

    public delegate void Progress(int progress);

    public class Parser

    {

        /// <summary>

        /// Описываем событие

        /// </summary>

        public event Progress ProgressHandler;

        /// <summary>

        /// Основной метод

        /// </summary>

        public void Calc()

        {

            for (int i = 0; i < 100; i++)

            {

                // Если обработчик задан - вызываем его

                if (ProgressHandler != null)

                    ProgressHandler(i+1);

            }

        }

    }

}

Использование этого класса:

namespace EventTest

{

    class Program

    {

        static void Main(string[] args)

        {

            // Создаем экземпляр

            Parser parser = new Parser();

            // Вешаем обработчик

            parser.ProgressHandler += new Progress(parser_ProgressHandler);

            // Можно и два метода обработки одного события

            parser.ProgressHandler+=new Progress(parser_ProgressHandlerSecond);

            // Можно описывать обработчики "по месту", хотя это не всегда удобно

            parser.ProgressHandler+= delegate(int progress)

            {

                Console.WriteLine("inline:" + progress);

            };

            // Вызываем метод

            parser.Calc();

        }

        /// <summary>

        /// Этот метод будет вызываться при обработке события

        /// </summary>

        static void parser_ProgressHandler(int progress)

        {

            Console.WriteLine("first:" + progress);

        }

        /// <summary>

        /// Можно вешать и два метода

        /// </summary>

        static void parser_ProgressHandlerSecond(int progress)

        {

            Console.WriteLine("second:" + progress);

        }

    }

}

Подклассы или типы

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

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

public Color Foreground()
{
   swith (type)
   {
     case StoneType.One: return Colors.Red;
   ............
}

Либо вообще вынести эти параметры в конструктор и типы не заводить:

public Stone(Color foreground, int countStrike)
{
  .....
}

А вот если отличий будет очень много, то класс будет замусорен кучей if или switch. Вот тогда имеет смысл делать подклассы и разносить логику и код. Разумеется, если какой-то из "типов" имеет дополнительные свойства, то это однозначно нужно выностить в подкласс.

Еще пример про делегаты

Задача такая: по имени функции (математической) получить результат ее вычисления. Самый простой вариант такой:

public class CallFunc1

{

    /// <summary>

    /// Вызываем функцию по имени

    /// </summary>

    public double GetFuncValue(string funcName, double arg)

    {

        switch (funcName.ToUpper())

        {

            case "SIN": return Math.Sin(arg);

            case "COS": return Math.Cos(arg);

            case "TAN": return Math.Tan(arg);

            case "SQRT": return Math.Sqrt(arg);

        }

        throw new ArgumentException("Такой функции нет в списке зарегистрированных функций", funcName);

    }

}

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

case "SQRT":

    if (arg < 0)

        throw new ArgumentException("Попытка вычислить квадратный корень от отрицательного числа", "arg");

    return Math.Sqrt(arg);

Потом появляются еще функции и свои проверки… В результате метод GetFuncValue напоминает сборную солянку. А хотелось бы как-то попроще и покрасивее сделать.

С помощью делегатов можно сделать так. Описываем делегат, имеющий сигнатуру метода с одним параметром:

        // Делегат- математический метод

        public delegate double MathFunction(double arg);

А теперь описываем словарь соответствия названий и делегатов таких методов:

        // Список функций

        private Dictionary<string, MathFunction> funcList;

Инициализировать его нужно будет в конструкторе:

    /// <summary>

    /// Конструктор

    /// </summary>

    public CallFunc1()

    {

        // Создаем список функций

        funcList = new Dictionary<string, MathFunction>();

        funcList.Add("SIN", delegate(double arg) {

            return Math.Sin(arg);

        });

        funcList.Add("COS", delegate(double arg)

        {

            return Math.Cos(arg);

        });

        funcList.Add("TAN", delegate(double arg)

        {

            return Math.Tan(arg);

        });

        funcList.Add("SQRT", delegate(double arg)

        {

            if (arg < 0)

                throw new ArgumentException("Попытка вычислить квадратный корень от отрицательного числа", "arg");

            return Math.Sqrt(arg);

        });

    }

Обратите внимание, что реализация делегата сделана прямо “по месту” (это называется анонимными методами – методами без имени).

А с помощью LINQ вызов станет совсем простым делом:

    public double GetFuncValue(string funcName, double arg)

    {

        // Ищем нужную функцию в списке

        var func = funcList.Where(f => f.Key == funcName).Select(f => f.Value).FirstOrDefault();

        // Не нашли - генерируем исключение

        if (func == null)

            throw new ArgumentException("Такой функции нет в списке зарегистрированных функций", funcName);

        // Нашли - вызываем эту функцию

        return func(arg);

    }

Теперь каждое имя функции связанно со своей реализацией и своими ограничениями.

Делегаты

В C# нет указателей (про unsafe я молчу). И это хорошо и правильно – указатель он по сути своей не типизирован. Передали в метод ссылку, а как ее интерпретировать – на совести принимающей стороны. Можем передать int, а использовать как float. И т.д. Тоже самое касается и методов – передали указатель на метод с одной сигнатурой, а используем совсем по-другому…

Зато в C# есть делегаты. Я бы назвал делегаты “типизированные указатели на методы”. Покажу на примере как это работает.

Сначала нужно описать тип делегата, т.е. сигнатуру метода. Описание можно не привязывать к конкретному классу:

namespace DelegateTest

{

    public delegate decimal GetVarValue(string name);

Здесь метод имеет один параметр типа string и возвращает decimal.

Теперь этот делегат мы можем использовать при описании параметров и переменных:

public class Parser

{

    /// <summary>

    /// Описание переменной, сохращающей делегат

    /// </summary>

    private GetVarValue getVarValueHandler;

    /// <summary>

    /// Передаем делегат в конструктор

    /// </summary>

    /// <param name="getVarValueHandler"></param>

    public Parser(GetVarValue getVarValueHandler)

    {

        // Сохраняем делегат, т.к. хотим использовать его

        // в другом методе этого класса

        this.getVarValueHandler = getVarValueHandler;

    }

    /// <summary>

    /// Метод расчета

    /// </summary>

    /// <returns></returns>

    public decimal Calc()

    {

        decimal result = 0;

        // Вызываем делегат с параметром var1

        result += getVarValueHandler("var1");

        // Вызываем делегат с параметром var2

        result += getVarValueHandler("var2");

        return result;

    }

Описание переменной типа делегат выглядит совершенно так же как и обычной переменной. Переменная getVarValueHandler имеет тип GetVarValue, т.е. тип делегата с нашей сигнатурой. Отличие от переменной в том, что мы можем вызывать этот метод. Разумеется, вызывать его можно только так, как он описан, т.е. с одним параметром типа string:

                 getVarValueHandler("var1");

Прелесть  в том, что никак иначе вызвать метод по этой ссылке (а передали мы фактически ссылку на метод) нельзя. Только так, как метод описан в описании делегата.

Использовать этот класс тоже очень просто. Во-первых, нам потребуется метод, который мы будем передавать в конструктор нашего класса. Наверное, излишне говорить, что сигнатура этого метода должна совпадать с сигнатурой делегата и передать в конструктор что-то другое нельзя:

class Program

{

    static void Main(string[] args)

    {

        // Передаем в конструктор делегат, т.е. ссылку

        // на наш метод

        Parser parser = new Parser(GetVarValueMethod);

        // Вызываем метод Calc

        Console.WriteLine(parser.Calc());

    }

    /// <summary>

    /// Делегат. Имя у него может быть любое, главное

    /// чтобы сигнатура была той как описана в типе

    /// делегата

    /// </summary>

    static decimal GetVarValueMethod(string name)

    {

        Console.WriteLine("Value of {0}:", name);

        return decimal.Parse(Console.ReadLine());

    }

}

Имя метода может быть может быть любое, главное чтобы сигнатура совпадала с сигнатурой делегата.

Вот и все. Теперь при вызове метода Calc будет два раза вызван метод GetVarValueMethod.