Велосипедостроение это конечно хорошо, но задачу минимум можно было решить гораздо проще — поиск плагинов по ключевому слову backup. Как итог — например addons.mozilla.org/ru/firefox/addon/febe/. Там можно выбрать, что именно бэкапить, а что нет.
Правда сложности должны проявиться с плагинами, которые любят хранить свои данные по своему. У таких придется вручную делать сохранение настроек.
Ну как бы имхо либо код надо отрефакторить и тогда уже делать статью, чтобы кодом хотя бы могли воспользоваться, либо же вообще не прикладывать код, ограничившись графиками, блоксхемами, алгоритмом, выводами. Чисто практической пользы от такого кода для читателей по моему мнению очень мало. Вряд ли он приведет«к большей ясности» =)
По самой идее ничего комментировать не могу, ибо не настолько часто пишу чтото на шарпе и не очень разбираюсь в архитектуре .NET
ooad.asf.ru/Pattern.aspx?IdKat=7&IdPat=50
Так как в фразе не было слова «только описания объектов реального мира» я подозреваю, что тут просто недопонимание. Вспомогательные классы нужны практически всегда.
Ну и еще важный момент — объекты не просто повторяют, точнее не полностью повторяют, мало того некоторые детали опускают, делают некоторые допущения, не выделяют отдельные сущности в классы. В общем очень много нюансов. Советую почитать литературу.
Поддерживаю. ООП как раз таки чаще используется для моделирования реальных сущностей: счета, переводы, документы, тарифы, покупатель, продавец итп итп итп. Вот немного процитирую Лармана:
«Проблемы:
Какой класс должен обеспечить реализацию шаблонов High Cohesion и Low Coupling или других принципов проектирования, если шаблон Expert (например) не обеспечивает подходящего решения?
Объектно-ориентированные системы отличаются тем, что программные классы реализуют понятия предметной области, как, например, классы Sale и Customer. Однако существует множество ситуаций, когда распределение обязанностей только между такими классами приводит к проблемам с зацеплением и связыванием, т.е. с невозможностью повторного использования кода.»
А для тех самых нереальных сущностей у Лармана есть вполне толковое название — чистая синтетика(pure fabrication). Цитата как раз оттуда.
Ну а в целом с ООП не все так просто. У каждого подхода проектирования свое видение, что есть класс, когда нужно его создавать, как разделять обязанности. Поэтому такая подборочка. Тут от итеративной когда все классы проектируются в юмл, до итеративной, когда класс выделяется только если больше никак, иначе все лепится в текущий класс и очень малое количество юмл диаграмм.
на практике никто не будет ничего готовое переделывать. создадут новый класс и все, максимум если есть полезный функционал либо перенесут в новый, либо если совсем ленивые — композиция, ну а если и не очень разумные — то и наследование используют.
не, не вручат. по математике по крайней мере. придется впихивать ее в какое нить физическое или химическое научное достижение. Ну или на Абелевскую надеяться.
struct Foo{};
Foo foo[5];
std::cout << sizeof(foo) / sizeof(foo[0]); // выведет 5
Но это так, на уровне легенды
struct Foo{};
Правда сложности должны проявиться с плагинами, которые любят хранить свои данные по своему. У таких придется вручную делать сохранение настроек.
По самой идее ничего комментировать не могу, ибо не настолько часто пишу чтото на шарпе и не очень разбираюсь в архитектуре .NET
Так как в фразе не было слова «только описания объектов реального мира» я подозреваю, что тут просто недопонимание. Вспомогательные классы нужны практически всегда.
Ну и еще важный момент — объекты не просто повторяют, точнее не полностью повторяют, мало того некоторые детали опускают, делают некоторые допущения, не выделяют отдельные сущности в классы. В общем очень много нюансов. Советую почитать литературу.
«Проблемы:
Какой класс должен обеспечить реализацию шаблонов High Cohesion и Low Coupling или других принципов проектирования, если шаблон Expert (например) не обеспечивает подходящего решения?
Объектно-ориентированные системы отличаются тем, что программные классы реализуют понятия предметной области, как, например, классы Sale и Customer. Однако существует множество ситуаций, когда распределение обязанностей только между такими классами приводит к проблемам с зацеплением и связыванием, т.е. с невозможностью повторного использования кода.»
А для тех самых нереальных сущностей у Лармана есть вполне толковое название — чистая синтетика(pure fabrication). Цитата как раз оттуда.
www.books.ru/shop/books/30688
www.books.ru/shop/books/487119
www.books.ru/shop/books/806536
www.books.ru/shop/books/816634
www.books.ru/shop/books/728454
www.books.ru/shop/books/455133 — просто полезно для усвоения паттернов и понимания как они могут упростить жизнь. В дополнение к GoF
Ну а в целом с ООП не все так просто. У каждого подхода проектирования свое видение, что есть класс, когда нужно его создавать, как разделять обязанности. Поэтому такая подборочка. Тут от итеративной когда все классы проектируются в юмл, до итеративной, когда класс выделяется только если больше никак, иначе все лепится в текущий класс и очень малое количество юмл диаграмм.
Ну а про внезапное добавление — ru.wikipedia.org/wiki/Декоратор_%28шаблон_проектирования%29