Для начала, небольшое введение. ООП, в отличие от того, что считают некоторые, это не просто объекты со свойствами. В этом смысле оно мало чем отличается от С-структур. Главная мощь ООП/С++ раскрывается в слабом связывании классов. Это значительно снижает стоимость отладки и поддержки для больших программ.
Когда мы говорим о каноническом применении инкапсуляции, нам становится понятно: с точки зрения логики построения классов, гуишные контролы, которые несут некую важную информацию каких-то объектов, должны являться их включениями. Очень важный момент. Я на нём остановлюсь особо.
Ещё раз: вот есть Бункер, он управляется (или нет) рядом гуишных контролов. Эти контролы несут внутреннее представление Бункера, они, по всей логике, механизмы Бункера по общению с человеком. Вывод: они должны быть частью бункера. Это будет правильно с точки зрения семантики, правильно с точки зрения инкапсуляции: 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. Вас ввели в заблуждение: главенствующие признаки социалистической модели присутствуют в большинстве стран северной и западной Европы (особенно в Швеции). Такие страны как Германия или Норвегия уже многие десятилетия стоят на принципах социального государства. И делают это вполне успешно для жителей этих самых государств.
2. Если вы посмотрите зарплатную сетку, например, конца 30-х годов, то увидите, насколько
а) зарплата зависела от качества труда человека
б) насколько умный и образованный профессионал получал больше простых рабочих (в разы больше). И речь идёт не об «элите» а о вчерашних рабочих, которые при свете лучины штудировали книжки.
То есть, никакой уравниловки, которая появилась позже. Было трудно, но была возможность работать, была возможность зарабатывать хорошие деньги честно и своим умом. Могу в качестве пруфлинка дать сканы соответствующих документов.
4. Просил бы уточнить, какой конкретно исторический период, когда «все жили одинаково» вы имеете в виду. От этого зависит мой ответ на вашу ремарку.
Хочу отдельно отметить, что ситуация, при которой на 10% населения «пашут» остальные 90%, формирует разный набор доступных благ. Но хорошо ли это?..
5. По поводу того, что жили плохо — надо опять же не грести все исторические периоды под одну гребёнку. Давайте обсуждать конкретно. После 50-х пошла деградация системы управления (судя по качеству экономических мер), поэтому, к сожалению, всё было как оно было. Хочу напомнить, что капиталистической системе также присущи системные кризисы, но при этом вы не говорите что капитализм плох.
3.
Я бы всё-таки предложил не мешать всё в кучу. Во-первых, в советском периоде можно выделить как минимум (как минимум!) три этапа: «сталинский», «хрущёв+брежнев», «перед перестройкой». Каждый из них характеризовался не только существенно разными экономическими характеристиками, но и отличался по системе социальных взаимоотношений внутри страны.
Кроме того, я бы рассматривал не только вместе, но и отдельно чисто экономические меры, принимаемые руководителями.
И если уж говорить о последнем, ссылаясь на фразы «как было в СССР», я бы сказал что ускоренная индустриализация, технологическое развитие и ряд других экономико-социальных мер в первом из указанных мною периодов, вполне достойны внимательного изучения в виду достигнутых результатов.
Конечно, можно возражать «попранием прав человека» и прочего — и здесь, в определённой степени, нечего возразить. Но я бы хотел заметить следующее: те, кто носится с плакатами Иосифа Джугашвили хотят не столько «возврата железной руки», сколько элементарного порядка и социальной справедливости (в том числе, что касается прав владения средствами производства).
Мне, да и многим здесь, как непрофессиональным сторонним наблюдателям, было бы крайне интересно прочитать ваши впечатления от личного прослушивания продукта в ИНФОРКОМ-е, который, как написано выше, приглашает.
Поверьте, я никак не связан с данной компанией. Но уж больно «вкусные» возможности обещают. Было бы интересно «натравить» на них профессионалов.
Кстати, я бы не хотел вешать ярлыки «зла» или «добра». Корпорация имела законное право создать тот формат, который пожелает (создание сложных форматов не преследуется по закону). Также, корпорация имеет право исходить из тех оснований, которые считает нужными. Мало того, Микрософт оказалась достаточно сильной, чтобы отстаивать свои позиции в течение десятилетий. Это, конечно, очень достойный результат.
Кстати, с тезисом об оптимизации для инкрементальных сохранений, также не согласен: всё то же самое можно было сделать, внедряя более простые схемы. Тем более что в реальных ситуациях, в старых версиях программ, где реальная сложность документов была ниже, подобная реализация была избыточной в квадрате. Даже если предположить, что реализация своего ФАТа была необходима, можно было реализовать гораздо проще. В ситуациях, когда приходилось делать свою мини-файловую систему для хранения разнородных данных в ЕЕПРОМ контроллера, моя реализация была на порядки менее монструозной. А этот, извините, Франкенштейн, вызывает единственную мысль: любой ценой необходимо было сохранить уникальность продукта на рынке. Как показала практика, с этой задачей формат справился.
Очень хорошо понимаю автора и поддерживаю отношению к формату. За эту вводную статью, также, большое спасибо.
Тезис критиков о том что формат старый, считаю несостоятельным: раньше как раз тяготели к эффективным бинарным форматам, которые читаются за один проход и, чаще всего, «ложатся» в обычный с-шный struct. С точки зрения быстродействия это наиболее оптимально. Считаю, что имею право рассуждать об этом, так как в течение более 10 лет разрабатываю форматы и протоколы обмена в областях, где важна эффективность и устойчивость к сбоям (соответственно, компьютерные игры, а также промышленная автоматика).
На мой взгляд (я не претендую на Истину), основной задачей при создании формата было внедрение неочевидной схемы, которую очень трудно воспроизвести в сторонних приложениях. Т.е. задача создать сложнейший формат, который бы сохранил эксклюзивную возможность работы с файлами только в «фирменных» приложениях, была выполнена «на отлично».
Для начала, небольшое введение. ООП, в отличие от того, что считают некоторые, это не просто объекты со свойствами. В этом смысле оно мало чем отличается от С-структур. Главная мощь ООП/С++ раскрывается в слабом связывании классов. Это значительно снижает стоимость отладки и поддержки для больших программ.
Когда мы говорим о каноническом применении инкапсуляции, нам становится понятно: с точки зрения логики построения классов, гуишные контролы, которые несут некую важную информацию каких-то объектов, должны являться их включениями. Очень важный момент. Я на нём остановлюсь особо.
Ещё раз: вот есть Бункер, он управляется (или нет) рядом гуишных контролов. Эти контролы несут внутреннее представление Бункера, они, по всей логике, механизмы Бункера по общению с человеком. Вывод: они должны быть частью бункера. Это будет правильно с точки зрения семантики, правильно с точки зрения инкапсуляции:
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. Вас ввели в заблуждение: главенствующие признаки социалистической модели присутствуют в большинстве стран северной и западной Европы (особенно в Швеции). Такие страны как Германия или Норвегия уже многие десятилетия стоят на принципах социального государства. И делают это вполне успешно для жителей этих самых государств.
2. Если вы посмотрите зарплатную сетку, например, конца 30-х годов, то увидите, насколько
а) зарплата зависела от качества труда человека
б) насколько умный и образованный профессионал получал больше простых рабочих (в разы больше). И речь идёт не об «элите» а о вчерашних рабочих, которые при свете лучины штудировали книжки.
То есть, никакой уравниловки, которая появилась позже. Было трудно, но была возможность работать, была возможность зарабатывать хорошие деньги честно и своим умом. Могу в качестве пруфлинка дать сканы соответствующих документов.
4. Просил бы уточнить, какой конкретно исторический период, когда «все жили одинаково» вы имеете в виду. От этого зависит мой ответ на вашу ремарку.
Хочу отдельно отметить, что ситуация, при которой на 10% населения «пашут» остальные 90%, формирует разный набор доступных благ. Но хорошо ли это?..
5. По поводу того, что жили плохо — надо опять же не грести все исторические периоды под одну гребёнку. Давайте обсуждать конкретно. После 50-х пошла деградация системы управления (судя по качеству экономических мер), поэтому, к сожалению, всё было как оно было. Хочу напомнить, что капиталистической системе также присущи системные кризисы, но при этом вы не говорите что капитализм плох.
3.
Кроме того, я бы рассматривал не только вместе, но и отдельно чисто экономические меры, принимаемые руководителями.
И если уж говорить о последнем, ссылаясь на фразы «как было в СССР», я бы сказал что ускоренная индустриализация, технологическое развитие и ряд других экономико-социальных мер в первом из указанных мною периодов, вполне достойны внимательного изучения в виду достигнутых результатов.
Конечно, можно возражать «попранием прав человека» и прочего — и здесь, в определённой степени, нечего возразить. Но я бы хотел заметить следующее: те, кто носится с плакатами Иосифа Джугашвили хотят не столько «возврата железной руки», сколько элементарного порядка и социальной справедливости (в том числе, что касается прав владения средствами производства).
Поверьте, я никак не связан с данной компанией. Но уж больно «вкусные» возможности обещают. Было бы интересно «натравить» на них профессионалов.
Тезис критиков о том что формат старый, считаю несостоятельным: раньше как раз тяготели к эффективным бинарным форматам, которые читаются за один проход и, чаще всего, «ложатся» в обычный с-шный struct. С точки зрения быстродействия это наиболее оптимально. Считаю, что имею право рассуждать об этом, так как в течение более 10 лет разрабатываю форматы и протоколы обмена в областях, где важна эффективность и устойчивость к сбоям (соответственно, компьютерные игры, а также промышленная автоматика).
На мой взгляд (я не претендую на Истину), основной задачей при создании формата было внедрение неочевидной схемы, которую очень трудно воспроизвести в сторонних приложениях. Т.е. задача создать сложнейший формат, который бы сохранил эксклюзивную возможность работы с файлами только в «фирменных» приложениях, была выполнена «на отлично».
У меня первая ассоциация — какой-то график.
К тому же, мне сложно представить как вписать «Сохранить» в 16х16 пикселей.