Russian Qt Forum

Привет!

Обращаюсь к тем, кто активно использовал и использует паттерны проектирования на практике. Напишите, пожалуйста, названия паттернов с которыми вы работали. Если есть ссылочка под рукой с хорошей статьёй или туториалом, то укажите, пожалуйста.

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

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

Может есть какие-то специальные паттерны для проектов на Qt? Может специфика сигнал-слотового взаимодействия между объектами накладывает свой отпечаток на паттерны?

P.S. Нашёл вот такую книжку, но для меня она пока тяжеловата: "Гамма Э. и др. - Приемы объектно-ориентированного проектирования. Паттерны проектирования - 2010"

Заранее спасибо за ответы!

offtop: сразу вспоминается анекдот про зоологов. Когда зоолог помнил названия всех всех зверей, но не помнил как они выглядят :D

Злой ты Верес  ;D

Такие звери как: класс, метод, исключение, полиморфизм, наследования и т.д. мне уже знакомы. Теперь хочется начать узнавать более крупных :)

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

P.S. И быть знакомым со зверями - мало - надо уметь их приручить  ;)

паттерны - это сейчас маст-хэв для senior c++ девелопера, и тем более для архитектора

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

в качестве первой книги рекоммендую http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124/
книга "банды четырех" может быть трудновата для новичка, но ее тоже надо прочитать и осмыслить

Она на русском кстати есть, я в озоне покупал - офигенно написана  ;D

Спасибо за книжку! :)

Решил для начала разобраться с частным случаем паттерна "Шаблонный метод", который реализован с помощью идиомы невиртуального интерфейса. Вот здесь подробно написано:
- http://www.e-reading.ws/chapter.php/1002058/86/Mayers_-_Effektivnoe_ispolzovanie_CPP.html
- http://www.e-reading.ws/chapter.php/1002058/87/Mayers_-_Effektivnoe_ispolzovanie_CPP.html

Этот паттерн часто ли используется в таком виде?

Там написано про какие-то "инварианты класса". Что это такое?

Как там написано (если я правильно понял), смысл в том, что в базовом классе находится реализация по умолчанию виртуальной функции, которая объявляется закрытой или защищённой. А вызывается эта функция с помощью открытой невиртуальной (невиртуальные функции в C++ не переопределяют, так как это приводит к трудноуловимым ошибкам). Клиент при наследовании может переопределить закрутую виртуальную функцию.

Я в примере для класса Monster оставил doHealthValue() по умолчанию из класса GameCharacter. А для класса Player переопределил:

main.cpp

C++ (Qt)
#include <iostream>
#include "Player.h"
#include "Monster.h"
 
int main( ) {
    Player p( "Player" );
    Monster m( "monster" );
 
    std::cout << p.name( ) << ": " << p.healthValue( ) << std::endl;
    std::cout << m.name( ) << ": " << m.healthValue( ) << std::endl;
 
    return 0;
}
 

Output:

GameCharacter.h

C++ (Qt)
#ifndef GAMECHARACTER_H
#define GAMECHARACTER_H
 
#include <string>
 
class GameCharacter {
public:
 
    GameCharacter( std::string name ) : m_name( name ) {
    }
 
    int healthValue( ) const {
        //...
        // выполнить предварительные действия
        //...
 
        // выполнить реальную работу
        int retVal = doHealthValue( );
 
        //...
        // выполнить завершающие действия
        //...
 
        return retVal;
    }
 
    std::string name( ) const {
        return m_name;
    }
 
private:
 
    virtual int doHealthValue( ) const { /* производные классы могут
                                         * переопределить эту функцию
                                         */
        // алгоритм по умолчанию для вычисления
        // жизненной силы персонажа
        return 1;
    }
 
    std::string m_name;
};
 
#endif // GAMECHARACTER_H
 

Monster.h

C++ (Qt)
#ifndef MONSTER_H
#define MONSTER_H
 
#include "GameCharacter.h"
 
class Monster : public GameCharacter {
public:
 
    Monster( std::string name ) : GameCharacter( name ) {
    }
};
 
#endif // MONSTER_H
 

Player.h

C++ (Qt)
#ifndef PLAYER_H
#define PLAYER_H
 
#include "GameCharacter.h"
 
class Player : public GameCharacter {
public:
 
    Player( std::string name ) : GameCharacter( name ) {
    }
 
private:
 
    int doHealthValue( ) const {
        return 2;
    }
};
 
#endif // PLAYER_H
 

 ;D ;D ;D


Уже жду, что скажет Old  ;)

Какие у паттерна "Шаблонный метод" недостатки и приимущества?

Широко ли используется сейчас идиома невиртуального интерфейса (NVI) в индустрии разработки ПО для реализации паттерна "Шаблонный метод"?

Скачал ту книжку, что советовали выше. Потрясающее оформление: столько картинок, юмора, примеров! Буду параллельно пытаться читать книгу "банды четырёх" :)

(http://i.pixs.ru/storage/7/7/3/193png_9397059_11853773.png)

Да я уже говорил, тут нужно из разряда читателя переходить уже в разряд писателя, писателя на C++. :)

Как я могу разрабатывать средние и сложные приложения без уверенного знания паттернов? :)

Паттерны это обычные приемы программирования, какие то удачные решения.
До многих паттернов программист доходит сам, в процессе своей работы.
Когда они еще не были систематизированы этими приемами все равно пользовались, называли их по разному, но пользовались. :)

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

Это всё следствие от программирования. Тем программист и отличается от "учителя-теоретика по программированию".
Программист сначала напишет программу. Всё нормально, она работает. Он посмотрит на код - перепишет. Понадобится ещё что-то, допишет. И вот когда уже нехватает места и/или возможностей для расширения кода, тогда таки программист обращается к опыту других :)

PS допустим вот итераторы, интерфейсы - изучены мной в ходе разработки пары программ. И да, настоящая программа переписывается как минимум 1 раз :D

Легко! С помощью С++!


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

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

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

Когда-то баловался этим (http://www.prog.org.ru/topic_24069_0.html) :). Подробно об используемых в Qt паттернах написано в книге "An Introduction to Design Patterns in C++ with Qt 4 (http://qt-project.org/books/view/an_introduction_to_design_patterns_in_c_with_qt_4)".

Или здесь (http://ptgmedia.pearsoncmg.com/images/9780131879058/downloads/0131879057_Ezust_book.pdf)  ;)

Спасибо за ссылки! Я начинаю понимать, что не надо всё подряд читать. Ибо книг море. А важно, для глубокого понимания, иметь сразу много разных источников и сравнивать: в одном месте тема лучше раскрыта, а в другом - другая. Хотя некоторые книги достойны быть прочитанными от корки до корки... Некоторые сразу, а некоторые постепенно, пока какие-то моменты не будут доведены до автоматизма.

В этой книге "An Introduction to Design Patterns in C++ with Qt 4" я нашёл пример "CardGame" :) Это Божий Промысел :)

Мне всё равно никуда уже не деться от изучения всех паттернов :) Думаю, стоит потратить время, чтобы изучить досконально все паттрены. Конечно хорошо бы учиться применять это на практике. Здесь вижу единственный вариант: заучивать примеры из книг и развивать их, фантазиваровать. А паттернов не так уж и много :)


Ответ на этот вопрос здесь: http://www.e-reading.ws/chapter.php/1002058/88/Mayers_-_Effektivnoe_ispolzovanie_CPP.html

Вот он ответ:

Ещё, судя из правила выше, место реализации паттерна "Шаблонный метод" (через идиому невиртуального интерфейса) предлагается другой паттерн - "Стратегия". Из-за того, что в данной задаче более логично указывать функцию вычисления жизненной силы при создании объекта, то есть передавать указатель на функцию в конструкторе и\или же менять функцию вычисления жизненной силы с помощью void setHealthCalculator( HealthCalcFunc hcf ). Это повышает гибкость. Теперь функция вычисления жизненной силы не зависит от типа объекта и её можно менять во время исполнения.

Правда теперь мы лишили себя возможности "выполнять предварительные действия" и "выполнять завершающие действия". Хотя мы эти "действия" притягиваем за уши в данном примере. Тут очевидно паттерн "Стратегия" - лучше.

Как я понял - открытые виртуальные функции это плохо если мы хотим проводить какие-то инициализирующие операции до вызова переопределяемого метода и проводить какие-то завершающие операции после вызова.

Как мне кажется, когда говорят, что мы применяем "Шаблонный метод", то имеется ввиду, что мы применяем идиому NVI. Или NVI - это уже только для C++?

Здесь приведена реализация паттерна «Стратегия» посредством указателей на функции: http://www.e-reading.ws/chapter.php/1002058/88/Mayers_-_Effektivnoe_ispolzovanie_CPP.html

Повысилась гибкость (это цитаты по ссылке выше):
- Разные экземпляры персонажей одного и того же типа могут иметь разные функции вычисления жизненной силы.
- Функция вычисления жизненной силы для одного и того же персонажа может изменяться во время исполнения. Например, класс GameCharacter мог бы предложить функцию-член setHealthCalculator, которая позволяет заменить текущую функцию вычисления жизненной силы.

На этом примере более или менее понятно почему мы перешли от паттерна "Шаблонный метод" к паттерну "Стратегия". Надеюсь, что это можно будет применить где-то ещё :)

Я сделал пример реализации более наглядным. В файле main.cpp сначала создаю персонажа класса Player и монстра класса EvilBadGay. У них функция вычисления жизненной силы - по умолчанию. Потом меняю им функции с помощью метода базового класса: void setHealthCalculator( HealthCalcFunc hcf )

main.cpp

C++ (Qt)
#include <iostream>
#include "Player.h"
#include "EvilBadGay.h"
#include "functionsForHealthCalc.h"
 
int main() {
    GameStuff::Player player(std::string("David"));
    GameStuff::EvilBadGay monster(std::string("Black"));
 
    std::cout << "Name: " << player.name( ) << std::endl;
    std::cout << "Health Value: " << player.healthValue( ) << std::endl;
    std::cout << std::endl;
 
    std::cout << "Name: " << monster.name( ) << std::endl;
    std::cout << "Health Value: " << monster.healthValue( ) << std::endl;
    std::cout << std::endl;
 
    // Change health functions
    player.setHealthCalculator(GameStuff::loseHealthSlowly);
    monster.setHealthCalculator(GameStuff::loseHealthQuickly);
 
    std::cout << "After changing health functions:" << std::endl;
    std::cout << std::endl;
 
    std::cout << "Name: " << player.name( ) << std::endl;
    std::cout << "Health Value: " << player.healthValue( ) << std::endl;
    std::cout << std::endl;
 
    std::cout << "Name: " << monster.name( ) << std::endl;
    std::cout << "Health Value: " << monster.healthValue( ) << std::endl;
 
    return 0;
}
 

Output:

Весь код примера: https://github.com/8Observer8/pattern_StrategyByFuncPointers

Эффект применения паттернов проблематичен, отрицательная сторона = шаблонный, догматичный подход без учета специфики задачи. А ведь есть еще и анти-паттерны, вот прекрасное описание 

http://insidecpp.ru/antipatterns/ (http://insidecpp.ru/antipatterns/)

Многие из них ТС уже успешно освоил  :)

Спасибо за ссылку. А где конкретно я напортачил? :)

Не знаю где напортачили вы, т.к. вы еще ничего не сделали, а вот Igors многие из них усвоил и использует в повседневной жизни. :)
http://insidecpp.ru/antipatterns/reinventing_the_wheel/
http://insidecpp.ru/antipatterns/blob/
http://insidecpp.ru/antipatterns/premature_optimization/

Ну не без этого, а колесо вообще мой любимый :)  Ну неинтересно мне, подобно девочке-отличнице, что-то усердно заучивать, а интересно самому что-то придумать. А Ваши какие любимые?  :)

Я нашёл описание паттернов с примерами в книге на русском: "Быстрая разработка программного обеспечения" http://rutracker.org/forum/viewtopic.php?t=905917

В этой книге есть параграф, который вынесен отдельно в содержании - "Перечень шаблонов проектирования". В этом перечне указаны названия паттернов с номером страницы. Написано кратко, но с разбором рабочих примеров. Примеры на Java и C++.

Такие паттерны приведены в перечне:
- Abstact Server
- Active Object
- Acyclic Visitor
- Adapter
- Bridge
- Command
- Composite
- Decorator
- Extension Object
- Facade
- Factory
- Mediator
- Monostate
- Null Object
- Observer
- Proxy
- Singleton
- Stairway to Heaven
- State
- Strategy
- Taskmaster
- Template Metod
- Visitor

Это правильно, заучивать НЕ неинтересно, а не эффективно. Применить заученное вряд ли получиться.

К сожалению, без знаний можно придумывать только ерунду.

Да как то я к ним таких нежных чувств не испытываю. :)

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

Вы правда так думаете?  ::)
Мне кажется, что за метаниями от темы к теме, он уже ничего изучать не успевает.
Вот же последняя тема: http://www.prog.org.ru/topic_26931_0.html
Уперся, задал вопрос, получил ответ и забыл разобраться. :)

P.S. Если 8Observer8 для вас знает "очень, очень много", то ... ;)

А Вы? Чего-то успеваете? Ведь Вы же изучаете "все новое" - где уж там успеть  :)

Да, "слишком много" :) Спокойнее относитесь к др точке зрения - может быть она имеет смысл...

Конечно.
Вы неадекватно воспринимаете изучение, наверное, из-за того что давненько этим не занимались. :)
Изучение это приятный и не обременительный процесс. Вот например, где нибудь я сталкиваюсь с информацией по какому то проекту в интересной для меня области.
Скажем это библиотека. Я захожу на их сайт и первым делом смотрю примеры использования. Для меня, в первую очередь интересен, ее интерфейс с внешним миром. Если интерфейс адекватный, то я качаю ее исходники и выборочно смотрю внутренности. Если мне нравится, то я могу подробно на нее посмотреть, написать тесты, погонять/попробовать. Соответственно, у меня в голове откладывается информация, что есть такой проект и его можно использовать для этого или этого. Плюс, если код действительно интересный, то можно выхватить из него интересные решения или подходы.
Вот и все. Этим я занимаюсь в свободное время, когда я не программирую, а что то обдумываю.

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

Как врач, должен учится всю жизнь, как учитель, так и программист просто обязан... :)
Грустно, что это вызывает у вас улыбку. :(

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

На данный момент, я усвоил два паттерна: паттерн "Шаблонный метод" и паттерн "Стратегия".

Понял, что для реализации функции вычисления жизненной силы паттерн "Шаблонный метод" не подходит. Во всяком случае, в этом примере у нас нет "предварительный действий" с инициализацией и "завершающих действий" с освобождением ресурсов. Ссылка: http://www.e-reading.ws/chapter.php/1002058/87/Mayers_-_Effektivnoe_ispolzovanie_CPP.html

Для реализации функции вычисления жизненной силы лучше всего подойдёт паттерн "Стратегия". С его помощью мы можем менять функцию вычисления жизненной силы во время выполнения программы с помощью этого метода:

C++ (Qt)
void setHealthCalculator( HealthCalcFunc hcf ) {
    healthFunc = hcf;
}
 

Ссылка: http://www.e-reading.ws/chapter.php/1002058/88/Mayers_-_Effektivnoe_ispolzovanie_CPP.html

Вот здесь описана более универсальная реализация паттерна "Стратегия" с помощью класса function (С++11) http://www.e-reading.ws/chapter.php/1002058/89/Mayers_-_Effektivnoe_ispolzovanie_CPP.html

Теперь мы можем задавать алгоритм вычисления жизненной силы не только с помощью передачи функции, но и с помощью передачи функциональных объектов и методов других классов. Главное чтобы сигнатура вызываемой сущности была совместимой с заданной, то есть чтобы параметр можно было неявно преобразовать в const GameCharacter&, а тип возвращаемого значения неявно конвертировать в int. Причём реализация паттерна "Стратегия" с помощью указателя на функцию и реализация паттерна "Стратегия" с помощью класса function отличаются только одной строкой в классе GameCharacter. В первом случае:

C++ (Qt)
typedef int (*HealthCalcFunc)(const GameCharacter&);
 

Во втором случае:

C++ (Qt)
typedef std::function<int (const GameCharacter&)> HealthCalcFunc;
 

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

C++ (Qt)
#ifndef FUNCTIONS_FOR_HEALTHCALC_H
#define FUNCTIONS_FOR_HEALTHCALC_H
 
namespace GameStuff {
 
    class GameCharacter; // опережающее объявление
 
    /**
     * Функции вычисления жизненной силы; она возвращает не int
     */
    short calcHealth( const GameCharacter& gc );
 
    /**
     * Класс функциональных объектов, вычисляющих жизненную силу
     */
    struct HealthCalculator {
 
        int operator()(const GameCharacter&) const {
            return 5;
        }
    };
 
    /**
     * Функция алгоритма по умолчанию для вычисления жизненной силы персонажа
     */
    int defaultHealthCalc( const GameCharacter& gc );
 
    /**
     * Функции вычисления жизненной силы с другим поведением
     */
    int loseHealthQuickly( const GameCharacter& gc );
 
    /**
     * Функции вычисления жизненной силы с другим поведением
     */
    int loseHealthSlowly( const GameCharacter& gc );
}
 
#endif // FUNCTIONS_FOR_HEALTHCALC_H
 

Исходный код реализации паттерна "Стратегия" с помощью класса function: https://github.com/8Observer8/pattern_StrategyByFunctionClass

Прости, Игорь, но тут я не могу не поддержать Old. Информатики должны всю жизнь учится чему-то новому потому, что мы выбрали профессию, которая безостановочно развивается, и нужно обязательно идти в ногу, или не будешь востребован на рынке. (Конечно, не во все стороны одновременно развиваться, а углублять специализацию).

90% врачей не учатся ничему новому) На себе испытано, 5 операций :D
А вот насчёт всё знать - это плохо. Потому что глубоко знать не получится. А поверхностное представление даст только возможность пускать пыль в глаза.

А кто говорит насчет знать все? Вы наверное плохо представляете объемы уже накопленных знаний только по нашей отрасли... А вообще всё.... :)

Есть такое понятие - эрудиция. А уровень знаний всегда можно углубить до нужного состояния, если появиться такая необходимость и возникнет желание.

К сожалению поверхностное представление не мешает огромной куче людей заниматься программированием, так сказать "профессионально". Отсюда имеем миллионы глючный тормозящих огромных программ. Но так дешевле, а значит будем дальше с этим жить. :)

Я считаю, что ничего лишнего я не усваивал. TDD-тесты - неотъемлемая часть современной программной инженерии. Паттерны тоже. Так же документация doxygen - хороший выбор. Я чуть-чуть пощупал геометрию на OpenGL и физику на Bullet. Это просто хобби. Какие-нибудь кубики пороняю, посталкиваю предметы, может ещё что придумаю. Может сделаю простую игру, где персонаж сможет перемещаться в 3D пространстве. Но это так, для души. Ну, а без PHP и jQuery современному разработчику, я считаю, сейчас никуда. Так как некоторые решения лучше всего делать не настольным приложением, а размещать в интернете. Разработчик выбирает подходящее решение.

Вот с алгоритмами у меня ещё большие проблемы... На этой слабости и надо будет сконцентрироваться позже. На решении задач.

А сейчас надо паттерны усвоить. Всё равно этот путь придётся пройти...

Ну с этим трудно не согласиться. Но на мой взгляд 8Observer8 - отличный пример интенсивного, но совершенно бесполезного изучения :) За таким изучением дело до написания хоть какой-то программы не доходит. Собственно писать он ничего и не хочет, а полагает достаточно будет  просто применить "знания" - и все напишется само собой. Но почему-то мне кажется что этого не произойдет :) Ну вот хз как можно было после тщательного изучения исключений спороть такое:
Вот он, "не ленивый" программист, copy/paste и все дела. И ведь даже не шевельнулась мысль "как обобщить". Что же дало такое "изучение"? Да ничего. Изучалась-то форма, а не содержание.

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

А у вас сразу шевелилась?
Легко требовать от кого-то понимания того, что уже понял сам.
Эти мысли начинают "шевелится" со временем, после получения достаточного опыта кодирования. А ТС кодированием еще не занимался вообще.

Да, опыта кодирования мне действительно не хватает :) Буду теперь каждый день, как можно больше пальчиками работать :) Кстати, советую вот эту программу для развития слепого десятипальцевого метода набора: "Соло на клавиатуре" http://ergosolo.ru/

Реальные знание это те, которые регулярно применяешь на практике, которые доведены до автоматизма. Думаю, надо стремиться расширять свой "несгораемый запас" :)

Но обзорно я всё же рассмотрю паттерны до конца. Авось, что-то в памяти всплывёт и пригодится :)

Не "кодирования" а "программирования", и собственно все остальное (чем так активно занимается ТС) - вещи побочные, они всего лишь помогают/облегчают. Нет главного - самого программирования, все "вокруг да около"

Те мысли, о которых вы сокрушались, шевелятся именно при кодировании, никакого программирования там нет. Хотя нужно определиться, что считать программированием, а что кодированием.

Кодируют алкоголиков. Программируют приложения. Как бы это странно не звучало :D

offtop: для десятипальцевого набора предлагаю метод - взяться за крупный проект в качестве "ученика" у кого-нибудь.  Или же пойти в фирму на минимальный оклад. Собственно именно при работе (будь то на дядю или на себя программируешь) формируются знания и понимание чего тебе надо.

Или приходишь в любой научный институт и говоришь - хлебом не кормите дайте программку написать - сразу завалят. особенно если к дедушкам подходить  ;D На своем опыте исследовано  ;D

Я считаю, что брать работу надо у тех кто занимается инженерным программированием. А наши "дедушки"-учёные - это ближе к Кнуту. Там мне точно не выжить. Мне нравится направление Agile: http://www.agilealliance.org/ Вот к этим дедушкам я бы подошёл :)

В научных институтах дедушки это те, кто будет давать тебе задания, а не те, кто будет тебя учить  ;D в программировании они сами не бум-бум  ;D

Ну тут от предметной области зависит. :)
У разработчиков ПО: программирование это составление алгоритмов решения задачи, а кодирование это описание алгоритма на конкретном языке программирования.

Программирование - это весь процесс - от алгоритма до работающей программы  ;)

Ага, который разделяется на:
http://tat67183862.narod.ru/jazik1.htm

Вы ещё слово "писать" замените на "рукоприменение c ручкой в трёх плоскостях" :)
Ну да умные люди придумали, пусть им и пользуются. А кодирование это отнюдь не создание кода по всем правилам русского языка :)

А причем здесь русский язык?
Это название пошло от английского "code", "coding", "coder".