Я сейчас как раз вынужден дорабатывать одно приложение, в котором в БД нет nullable-полей, зато в каждой таблице-справочнике есть специальное значение (0, '_НЕ задано'). Иногда мне хочется придушить автора этого безобразия... ;)
А Вам, конечно же, спасибо и плусик. Надеюсь, кого-то эта статья научит не создавать проблем себе и другим :)
Даже если чисто теоретически Вы подключите бесконечный своп, то все равно в один прекрасный момент банально закончатся pid-ы. Это если шедьюлер с ума раньше не сойдет - уж он-то вряд ли свапит структуры с описаниями процессов.
Можете.
А теперь представьте ситуацию, что рыбка каждого типа — это плагин, который подгружается в "аквариум". И у каждой рыбки плавники расположены по-разному, соответственно, чтобы рыбка плыла, нужно описать движения плавников.
Если каждая рыбка будет наследоваться от абстрактного класса "рыбка", определять положения и форму плавников и перегружать метод "плыть", то все просто и элегантно.
А в случае с процедурным подходом: как узнать, какой метод "плыть" вызвать для конкретной рыбки?
Описывать все возможные типы рыбок? А как же быть, если появится новая рыбка? Переделывать аквариум?
Хранить указатель на нужный метод в структуре, описывающей рыбку? Это и будет упрощенным понятием объекта, от которого Вы так стремились уйти в сторону процедурного программирования.
Кстати, несмотря на свою корявость, MFC-то еще вполне поддерживаемая технология. Вот, например, Feature Pack для VC++2008 включает кучу компонентов и улучшений именно под MFC. Так что пока рановато его хоронить, даже при всей прелести шарпа... :)
но вот потом кодить свой код в стиле ООП — как то муторно :), проще процедурками.
В то время, когда делался ATL, MFC и сотоварищи, C# нам только снился :)
Это все равно, что заикаться о флешках во времена перфокарт и магнитных лент :)
Довольно часто СОМ провозглашается как отличная технология для создания plugin-подобным программ
При этом, на глазах у меня был Far, WinAmp, Photoshop - у них есть plugin архитектура, и всё прекрасно работает
У программ с нативным кодом, как мне это видится, есть две основных объектных модели расширения (чисто процедурные плагины, типа TotalCommander-овских оставим в стороне):
1. Интерфейсы аля COM.
2. Базовые классы в SDK, от которых наследуются классы-плагины (например, Far, Foobar2000, etc.).
И у тех, и у других есть плюсы и минусы. И COM-подход в некоторых случаях гибче. Например, объект может инициализироваться разными способами — из файла, потока, урла, другого объекта, но делать одно и то же. В таком случае разумнее предусмотреть несколько интерфейсов инициализации, чем предусматривать все перегрузки в базовом классе (плюс, сами плагины могут предоставлять интерфейсы для "общения" между собой, о которых программа-хост не знает).
Кроме того, в обоих случаях vTable-ы и их внутреннее устройство совершенно не парят разработчика — пусть о них заботится компилятор. QueryInterface давно не проблема — она прозрачно сводится к вызову одной функции.
Хотя, конечно, проблем у COM-а выше крыши. Отсутствие разделения прав, параметризованных конструкторов, необходимость регистрации в системе (или геморрой с динамической загрузкой — тут уже никакой помощи от CoCreateInstance)...
Так что, наверное, правильно, что пора менять эту технологию на что-нибудь новенькое. Например, на .net-модель... :)
А что их перечислять? Они есть в спецификации.
Если совсем кратко, то:
1) LINQ
2) неявное объявление локальных переменных (var)
3) методы-расширители
4) лямбда-выражения
5) анонимные типы (в примере не используются)
6) инициализация свойств/коллекций в конструкторе
7) авто-свойства (в примере не используются)
как-то так :)
> ssh
мм... окошко путти? :)
> работа с базой
Честно говоря, мне гуи больше по душе. Во-первых нагляднее, во-вторых — даже затрудняюсь сказать, как "читать" план выполнения запроса в консольке :)
> svn/git
Предпочитаю приблуду к IDE, либо один раз написать скрипт для чекина-чекаута проекта и всех связанных действий. Вроде тоже особо консольных функций здесь не требуется...
Особо вебом не занимаюсь, так что, вероятно, не могу прочувствовать какого-то особого момента :)
Что именно — "это" ?
Я вот видел, как слетает оформление странички логина и половины Гнома на Убунте после какого-то штатного апдейта из-за кривых xml-ок в пакетах. Вообще без вмешательства пользователя :)
Еще я видел, как Compiz отказывается сохранять свои супер-пупер-желейные окошки из-за какого-то конфликта с обновленными драйверами видеокарты.
И еще я видел две висты у себя на лаптопах, которые (одна — полтора года, вторая — 5 месяцев) весьма стабильно служат службу. И зачем мне, скажите, продавать душу за возможность вращать окна на кубике?
Для тех задач, которые требуют линуса, у меня есть путти и виртуальные машины.
Странно. Я вот (как девелопер) почти и не пользуюсь консолью.
Даже не придумаю задачи, которую девелоперу нужно часто делать именно в консоли и для которой нельзя один раз написать скрипт.
Или это особый фетиш веб-девелоперов?
А Вам, конечно же, спасибо и плусик. Надеюсь, кого-то эта статья научит не создавать проблем себе и другим :)
А теперь представьте ситуацию, что рыбка каждого типа — это плагин, который подгружается в "аквариум". И у каждой рыбки плавники расположены по-разному, соответственно, чтобы рыбка плыла, нужно описать движения плавников.
Если каждая рыбка будет наследоваться от абстрактного класса "рыбка", определять положения и форму плавников и перегружать метод "плыть", то все просто и элегантно.
А в случае с процедурным подходом: как узнать, какой метод "плыть" вызвать для конкретной рыбки?
Описывать все возможные типы рыбок? А как же быть, если появится новая рыбка? Переделывать аквариум?
Хранить указатель на нужный метод в структуре, описывающей рыбку? Это и будет упрощенным понятием объекта, от которого Вы так стремились уйти в сторону процедурного программирования.
Наверное, именно оттого, что проекты небольшие :)
Это все равно, что заикаться о флешках во времена перфокарт и магнитных лент :)
1. Интерфейсы аля COM.
2. Базовые классы в SDK, от которых наследуются классы-плагины (например, Far, Foobar2000, etc.).
И у тех, и у других есть плюсы и минусы. И COM-подход в некоторых случаях гибче. Например, объект может инициализироваться разными способами — из файла, потока, урла, другого объекта, но делать одно и то же. В таком случае разумнее предусмотреть несколько интерфейсов инициализации, чем предусматривать все перегрузки в базовом классе (плюс, сами плагины могут предоставлять интерфейсы для "общения" между собой, о которых программа-хост не знает).
Кроме того, в обоих случаях vTable-ы и их внутреннее устройство совершенно не парят разработчика — пусть о них заботится компилятор. QueryInterface давно не проблема — она прозрачно сводится к вызову одной функции.
Хотя, конечно, проблем у COM-а выше крыши. Отсутствие разделения прав, параметризованных конструкторов, необходимость регистрации в системе (или геморрой с динамической загрузкой — тут уже никакой помощи от CoCreateInstance)...
Так что, наверное, правильно, что пора менять эту технологию на что-нибудь новенькое. Например, на .net-модель... :)
Если можно, ту же мысль, но более развернуто...
Если совсем кратко, то:
1) LINQ
2) неявное объявление локальных переменных (var)
3) методы-расширители
4) лямбда-выражения
5) анонимные типы (в примере не используются)
6) инициализация свойств/коллекций в конструкторе
7) авто-свойства (в примере не используются)
как-то так :)
Держите плюс в карму за энтузиазм :)
мм... окошко путти? :)
> работа с базой
Честно говоря, мне гуи больше по душе. Во-первых нагляднее, во-вторых — даже затрудняюсь сказать, как "читать" план выполнения запроса в консольке :)
> svn/git
Предпочитаю приблуду к IDE, либо один раз написать скрипт для чекина-чекаута проекта и всех связанных действий. Вроде тоже особо консольных функций здесь не требуется...
Особо вебом не занимаюсь, так что, вероятно, не могу прочувствовать какого-то особого момента :)
Что именно — "это" ?
Я вот видел, как слетает оформление странички логина и половины Гнома на Убунте после какого-то штатного апдейта из-за кривых xml-ок в пакетах. Вообще без вмешательства пользователя :)
Еще я видел, как Compiz отказывается сохранять свои супер-пупер-желейные окошки из-за какого-то конфликта с обновленными драйверами видеокарты.
И еще я видел две висты у себя на лаптопах, которые (одна — полтора года, вторая — 5 месяцев) весьма стабильно служат службу. И зачем мне, скажите, продавать душу за возможность вращать окна на кубике?
Для тех задач, которые требуют линуса, у меня есть путти и виртуальные машины.
Гораздо более странно, что для этого нету 3rd-party решений.
Даже не придумаю задачи, которую девелоперу нужно часто делать именно в консоли и для которой нельзя один раз написать скрипт.
Или это особый фетиш веб-девелоперов?