![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Удар головой о стенку, обитую войлоком
"Хочу строгой типизации"
Удар головой о стенку, обитую войлоком
"Хочу автоматический вывод типов"
Удар головой о стенку, обитую войлоком
"Хочу метапрограммирование"
переход к началу.
Альтернатива:
для объекта Config регистрируется TypeDescriptionProvider, который создает и возвращает CustomTypeDescriptor, который из ServiceProvider достает XmlConfigProvider, загружает из него список кастомных свойств объекта, для каждого из них генерит ConfigPropertyDescriptor, добавляя к нему CategoryAttribute,DisplayNameAttribute,DescriptionAttribute,иногда TypeConvertorAttribute и ChoiceDescriptionAttribute, указав для них ChoiceConverter, который возвращает StandardValuesCollection, исходя из ChoiceDescriptionAttribute, найденного в TypeDescriptorContext.
Это всего лишь показ объекта в user-friendly виде с локализованными именами пропертей и динамически меняющимся их списком в PropertyGrid.
PS: А тут еще
max_posedon всякую завлекаловку с LVEE про линуксы и железо пишет. Хоть ты точно, на линукс и какой-нибудь трэшак типа руби с питоном пересядь, чтобы этого дотнета с его гирляндами типов никогда не видеть. Или вообще на low-level работу с железом, там уж ТОЧНО НИКОГДА не придется писать что-нить вроде IServiceProviderFactoryOfProviderForServiceProviderFactoryFacade.
"Хочу строгой типизации"
Удар головой о стенку, обитую войлоком
"Хочу автоматический вывод типов"
Удар головой о стенку, обитую войлоком
"Хочу метапрограммирование"
переход к началу.
Альтернатива:
для объекта Config регистрируется TypeDescriptionProvider, который создает и возвращает CustomTypeDescriptor, который из ServiceProvider достает XmlConfigProvider, загружает из него список кастомных свойств объекта, для каждого из них генерит ConfigPropertyDescriptor, добавляя к нему CategoryAttribute,DisplayNameAttribute,DescriptionAttribute,иногда TypeConvertorAttribute и ChoiceDescriptionAttribute, указав для них ChoiceConverter, который возвращает StandardValuesCollection, исходя из ChoiceDescriptionAttribute, найденного в TypeDescriptorContext.
Это всего лишь показ объекта в user-friendly виде с локализованными именами пропертей и динамически меняющимся их списком в PropertyGrid.
PS: А тут еще
![[livejournal.com profile]](https://www.dreamwidth.org/img/external/lj-userinfo.gif)
no subject
Date: 2009-07-04 01:35 pm (UTC)так есть же метапрограммирование со строгой типизацией, зачем к началу-то. Дальше идти надо.
а гирлянда -- жесть. Я бы ебанулся. Если .net является требованием, проще F# взять.
no subject
Date: 2009-07-04 03:05 pm (UTC)А еще мне всегда казалось, что System.ComponentModel несколько ущербно задизайнена, как и виндовс формс, для которого, вроде, оно было сделано.
no subject
Date: 2009-07-04 03:15 pm (UTC)А вот ComponentModel и Windows.Forms это да, безумие. В рефлекторе на внутренности страшно смотреть.
no subject
Date: 2009-07-04 03:33 pm (UTC)no subject
Date: 2009-07-04 03:51 pm (UTC)no subject
Date: 2009-07-04 03:56 pm (UTC)Но я предполагаю, что это ненамного страшнее реализации самодельных языков, виртуальных машин для микроконтроллеров и использования в продакшене llvm :)
no subject
Date: 2009-07-04 04:00 pm (UTC)llvm в продакшене это уже от отчаяния, думаю ничего не получится. Дальше или откат процессора, или забивание на расширенную память и трамбовка кода.
no subject
Date: 2009-07-04 04:16 pm (UTC)no subject
Date: 2009-07-04 04:20 pm (UTC)no subject
Date: 2009-07-05 02:15 pm (UTC)no subject
Date: 2009-07-04 07:48 pm (UTC)те, кто вовремя успел перейти на линукс, сейчас тут загорают, жарят шашлыки и купаются в озере ;-)
no subject
Date: 2009-07-07 09:52 am (UTC)no subject
Date: 2009-07-07 10:49 am (UTC)no subject
Date: 2009-07-07 06:01 pm (UTC)Лично я произвожу декомпозицию сначала процедурную, а по мере взросления проекта разбиваю задачу на модули, которые вовсе не обязаны быть объектами.
no subject
Date: 2009-07-07 06:22 pm (UTC)А вот всевозможные запросы-отчеты-расчеты-ведомости используют функциональную декомпозицию, на нее они ложатся гораздо лучше.
no subject
Date: 2009-07-07 11:50 am (UTC)Ещё раз, напоминаю, в чём именно проблема:
* Надо позволить юзерам создавать БД и описывать формы для его взаимодействия путём показа описывающих сущности этой БД форм. БД заранее неизвестна. Также юзер должен мочь изменять это своё описание. Также юзер должен мочь добавлять произвольные атрибуты, которые потом будут использоваться сторонней программой.
Вы сделаете абсолютно такой же дизайн. Да, названия сущностей и методов будут другие, а состав данных - тот же.
Проблема не в ООП совсем -- если приглядитесь, в записи только обычные типы, никакого наследования не требуется. Можно точно так же пенять, дескать XML виноват. Альтернатива ничем не будет лучше.
no subject
Date: 2009-07-07 12:13 pm (UTC)no subject
Date: 2009-07-07 05:56 pm (UTC)Не ООП подход такой, что задачу стоит рассмотреть с точки зрения поставляемых сервисов. То есть ход мысли примерно такой:
1. Что мы будем поставлять клиенту - сервис предоставления отчётов и форм и прочей дребедени на каждый чих? Тогда не будем давать пользователю ничего в руки и писать такие сервисы самостоятельно.
2. Если мы будем предоставлять клиенту сервис для самостоятельного создания дребедени, то пишем такой сервис с приемлемым АПИ (типа REST) и ставим бэкендом хоть БД, хоть что угодно.
3. Нужно ли тут ООП? Вопрос религии. В любом случае это будет внутренняя кухня и клиент никаких иерархий не увидит, а видеть будут создатели сервиса.
Но это всё домыслы, а критерий истины практика. Поэтому я и предложил метаклассу сообщить, как только он придумает идеальный дизайн этой кухни.
no subject
Date: 2009-07-14 01:32 pm (UTC)Здрасьте-приехали. Бухгалтера уже лет 10 как метадату редактируют в 1С, а вообще-то небось ещё в 1980-х было. Ничего там монстроидального нет.
> Тогда не будем давать пользователю ничего в руки и писать такие сервисы самостоятельно.
А конкуренты будут. И дают. Что-то бухгалтера не Ваше поделие юзают, а почему-то 1С.
> Нужно ли тут ООП? Вопрос религии.
Повторюсь: "С удовольствием выслушаю Ваше не-ООП решение этой проблемы."
По факту, современные ООП-классы выросли из С++-ных, а те -- из struct-ов. Ранний Страуструп так и говорил: это альтернативная нотация для struct, у которых ещё и методы есть. Просто в какой-то момент Вы сами запаритесь всюду передавать this и тягать из него поля, и вуаля.
no subject
Date: 2009-07-15 06:14 am (UTC)1C очень долго был глюкавым чудищем. Я же не говорю, что так делать совсем нельзя - просто поддерживать сложнее, чем без такого подхода. Что и почему юзают бухгалтера не очень сильный довод - тут масса факторов, начиная со времени выхода на рынок, имеющихся ресурсов...
"По факту, современные ООП-классы выросли из С++-ных, а те -- из struct-ов."
Как устроен ООП я как бы в курсе. Но его необходимость преувеличена. Я видел кучу фреймворков и АПИ без всяких признаков ООП.
Чтобы не тягать this можно его просто разместить видимым внутри модуля и все методы модуля о нём знают. Для "как бы" полиморфизма используются коллбэки. Наследование вообще не используется как опасное.
Чтобы дать конкретное не-ООП решение "этой проблемы" нужно уточнить, какая проблема имеется в виду. Если под проблемой понимается реализация собственных форм и обработчиков пользователя, то я бы сделал систему типа плагинов и регистрировал точку входа в плагин в некотором реестре. Сами же плагины чтобы писались на произвольном языке.
no subject
Date: 2009-07-15 06:44 am (UTC)Где-то в интернете валяется статья на тему OOP vs Haskell. Там описывается, что большая часть ООП становится нахрен не нужна при наличии функций высших порядков/лямбд/замыканий. Конкретно в моем описанном случае половина интерфейсов/классов исключительно служат оболочками для реализации этого всего вручную.
Полиморфизм добавляется классами типов, за одним исключением - разные объекты внутрь списка просто так не поместишь для однообразной обработки, поэтому нужен экзистенциальный тип(насколько я понял, это оболочка вокруг обычного типа, накладывающая на него условие вроде "все вложенные типы являются экземплярами класса типов X).
А наследование просто нахрен не нужно, да его и в обычном ООП уже почти не используют - кроме наследования классов от интерфейсов, что в свою очередь и реализуется классами типов.