10 лет практики. Часть 1: построение программы

Простите, но причем здесь это «lisp»?

Скандалы, интриги, расследования.
Последние бастионы лисперов пали. Представители NASA признались, что в марсоходах код на C и C++ (да, в самих марсоходах и да, C++ явным образом назван). Даже в ответе на вопрос о DSL-ах не было никакого упоминания lisp.
channel9.msdn.com/blogs/nicfill/channel-9-live-at-pdc09-dr-jeff-norris-nasa (перемотать на 23:30)
Рекомендую прослушать все, чтоб представить какие проблемы решаются

с таким ником написал бы хаскелл)

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

Инопланетный тролль? Приглашён НЛО…

думаю, это небольшое вступление, для в вступления норм. ждем следующей части.

тоже немного оффтопа: хорошо бы хабру заиметь понятие «цикл статей»…

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

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

Был бы очень благодарен за конкретные идеи как упорядочить данную статью.

Вы задали два отличных вопроса. Спасибо.

Для начала, небольшое введение. ООП, в отличие от того, что считают некоторые, это не просто объекты со свойствами. В этом смысле оно мало чем отличается от С-структур. Главная мощь ООП/С++ раскрывается в слабом связывании классов. Это значительно снижает стоимость отладки и поддержки для больших программ.

Когда мы говорим о каноническом применении инкапсуляции, нам становится понятно: с точки зрения логики построения классов, гуишные контролы, которые несут некую важную информацию каких-то объектов, должны являться их включениями. Очень важный момент. Я на нём остановлюсь особо.

Ещё раз: вот есть Бункер, он управляется (или нет) рядом гуишных контролов. Эти контролы несут внутреннее представление Бункера, они, по всей логике, механизмы Бункера по общению с человеком. Вывод: они должны быть частью бункера. Это будет правильно с точки зрения семантики, правильно с точки зрения инкапсуляции:
class Silo
{
private:
ComboBox type;
Button manualMeasure;
};

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

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

В противном случае, Вам приходится писать дополнительные «связующие» функции-члены класса, которые «привязывают» его к внешним контролам, обновляют его из внешних контролов и наоборот. Это не смертельно, но несколько увеличивает связующий интерфейс между ГУИ и самим классом:
//хороший случай, когда фреймворк позволяет классу хранить контролы у себя
class Silo
{
public:
void InitializeGUI(Window *);
private:
Button manualMeasure;
};

//когда фреймворк этого не позволяет
class Silo
{
public:
void InitializeGUI(Button *manualMeasure);
private:
Button *manualMeasure;
};


Теперь что касается MVC. Очевидно, что взаимосвязь между M, V и C слишком сильна, так как переносит всю внутреннюю кухню в открытый интерфейс. По сути, это означает, что три компонента являются друг для друга полностью открытыми. Соответственно, пользоваться ей, разделяя M, V и C по разным классам, я не рекомендую. Эти три компонента очень неплохо разделяют внутренний функционал класса, будучи оформленными как три блока членов и функций-членов класса.
Мой опыт показал: проще реализовать всю кухню внутри одного класса, чем искусственно делить на некие абстракции, которые к тому же слишком сильно связаны, что грозит адскими интерфейсами, которые тупо «гоняют» все логически связанные внутренности (которые по идее никто не должен видеть) между какими-то левыми классами. Зачем вводить внешнее управление над контролами Бункера, если он, по идее, сам с этим отлично справится? Это не только уменьшит код, но и сделает его стабильнее и более поддерживаемым, в конечном итоге.

В итоге, для реализации бункера НЕ были использованы детали ГУИ, потому что все контролы принадлежат самому бункеру (мой фреймворк это позволяет). Для инициализации мне достаточно указателя на окно. Соответственно, когда потребовалось удалённое управление, интерфейс не изменился. Просто в случае удалённых бункеров, я создаю другие контролы (и много чего другого, с ГУИ не связанного).

Что смутило?

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

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

Цикл статей о программировании — это конечно хорошо, но без законченной мысли и структурного изложения — все это бессмысленно.

Что ценного я лично вижу в своей статье:
1) Напоминаю об делении на куски и отладке по кускам. TDD — лишь один из вариантов тестирования этих кусков, который, конечно, имеет право на существование. Я специально нигде не навязываю стиль создания этих элементов, потому что каждому ближе своё, всё зависит от навыков и специфики проекта. Мне, например, ближе тестирование по граничным условиям, а потом уже переход к автоматизированным тестам, по необходимости. Это позволяет идти от задачи и экономить время, так как я не делаю развёрнутое тестирование там, где оно, в ходе отладки этюда, становится ненужным.
2) Рассказываю о важности переносить сложные алгоритмы на бумагу и отлаживать их на бумаге, для начала — в простом русском языке.
3) Напоминаю о простой методике создания структуры классов.
4) Предлагаю использовать инкапсуляцию *правильно*, объясняю почему так следует делать на жизненных примерах.
5) Заранее готовлю начинающих к тому, что переписывать с нуля — это нормально.

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

Да бросьте, не так много хороших тематических статей на Хабре, может, из нескольких частей будет что-то толковое, зачем рубить на корню.

В случае разделения логики и управления интерфейсом, Вам приходится «размазывать» семантику класса по ряду других объектов. Это увеличивает код за счёт интерфейсов-сцепок. Зачастую это также разносит логически близкий функционал по разным файлам, что затрудняет чтение кода. И, наконец, когда Вы будете что-либо менять в своей программе, Вам придётся менять не только содержимое классов логики и интерфейса, но и интерфейс между ними. Почти всегда это можно организовать в одном классе, в одном файле спп.
Ни в коем случае не навязываю свой подход, но подумайте, взвесьте ещё раз все «за» и «против» — возможно, объединение логики с интерфейсом в едином классе, не так уж плохо, особенно когда речь идёт о средних и небольших интерфейсах пользователя.

Вы зря так категорично. Нужно понимать уместность каждого подхода в программировании. Отделение имеет смысл, когда предполагается взаимозаменяемость компонентов. Излишняя универсальность — неоправданное усложнение программы со всеми вытекающими.

Приношу извинения, если статья правда сумбурная.
Я, правда, рассчитывал на внимательное и «с карандашом» её изучение.

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

если прочитать коменты, то все разъясняется, кроме того в коментах сразу разъясняються и другие подходы к проектированию

Вы взяли отличный классический пример. Он поможет очень быстро объяснить суть идеи.
Давайте задумаемся. Задумаемся как профессионалы — практики. Зачем в чистом абстрактном классе координаты? Почему Вы заставляете всех наследников Фигуры иметь математическое описание через точку на декартовой плоскости? Подумайте об этом искусственном ограничении, которым Вы сами себя связали.
Что Вы хотите на самом деле? Вы хотите, чтобы фигура выводилась в указанным координатам. Что это? Правильно, это интерфейс, то есть класс с чисто виртуальными функциями-членами:
class Shape
{
public:
virtual void Paint(int x, int y) = 0;
};


А что если мой объект — сплайн, описываемый вещественными уравнениями? Ему не надо навязывать внутреннюю структуру, завязанную на паре целочисленных координат. У него вообще нет такого понятия как «координата центра».

Мораль такова: не нужно создавать лишнее сцепление там, где оно не нужно. Объект сам отлично разберётся что и как ему иметь внутри. Ваша задача — продумать хороший общий интерфейс.

И последнее. Наследование само по себе — это довольно сильное сцепление. Лучше проектировать сравнительно «широкую» иерархию классов, чем делать наследование там, где без него можно обойтись.

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

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

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

Вы правы в том что касается сумбурности и краткости. Слишком много сложного материала дальше. Приходится делать введение кратким. Ни в коем случае не пытаюсь заменить собой классические книги, приведённые в списке литературы. Моё дело — заинтересовать, вызвать желание разобраться. Желающие смогут разобраться «с карандашом» с моей статьёй и книгами, либо задать вопросы в комментариях.

За ценное замечание — спасибо.

лучше поищите доку от Сони pitfalls of object oriented programming
и что нибудь об Data Oriented Design и Aspect Oriented Programming чтоб зря не терять время в ожидании неизвестно чего…

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

«Поэтому сериализацию и подобные операции имеет смысл разнести как минимум по разным интерфейсам, а порой и по вспомогательным классам.»
— Что мешает спрятать сериализацию в классе? void Entity::Serialize(Stream *);
Всё отлично работает. Если сериализацию делает внешний код, в него требуется передать всё содержимое объекта. А зачем? Проще хранить внутри.

«А насчет «выведи себя в интерфейс» — по моему мнению вообще за гранью добра и зла.»
— Подумайте, пожалуйста, об этом:
habrahabr.ru/blogs/cpp/111120/#comment_3543396

Что касается продуктивности — вопрос спорный. Готов обсудить подробнее, на тех примерах, которые Вы приведёте. Доводы в защиту моего подхода я привёл в самой статьи.
Что касается оптимизации — здесь согласен на 100%. На эту тему я даже писал статью. Но, согласитесь, это немного иной вопрос, выходящий за рамки введения в методики программирования.

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

если почитать статью, то становится ясно, что автор имел в виду.
отсутствие сеттеров приводит к слабому взаимодействию между классами, а значит более быстрая масштабируемость и быстрый рефакторинг.
в случае, когда класс внезапно передумал быть машей, а стал сашей, то все классы, которые до этого дергали свойство Masha->SetSiski придется переписать. И нет никакой гарантии, что это не повлечет за собой цепочку других изменений.

В принципе верно, инкапсуляция, только более строгая. Подход как минимум имеет право на то, чтобы быть. Правильно или нет — это уже вопрос применимости в той области, где ты работаешь.

например как то так (извиняюсь за стиль, на сях уже давненько не писал)

class GUIController
{
public:
void AddButton(char* Text, ClickHandler* PressHandler)
};

class Silo
{
public:
void InitializeGUI(GUIController *GController);
private:
GUIController *FGUIController;
};

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