Искусство метапрограммирования: Часть 3. Корпоративное метапрограммирование

Это кто ж такое название придумал?

+1 мда... OMG...

Всем желающим написать "OMG!!!" и подобное: загляните в удалённый ;)

Новость - провокация флуда.

>class Person { public: int id; text name; text address;

Закопать срочно! Афтар бестолочь, я за такое увольнял.

Читаю "Листинг 2. Пример описания ресурсов Win32"

Вопрос: А причем тут UNIX ???????? :)))))))))))))))))))))))))))

>А причем тут UNIX ?

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

ИБМ отжигает, впрочем как всегда.

это просто пример DSL

"Итак, ценой почти двухсот строк кода вы можете создавать диаграммы вместо того, чтобы писать код SQL и C++. Конечно, получается еще веселее, когда программу преобразования пишет кто-то другой." (c)

Это бимеры предлагают нам переползти с ихней веб-с-феры на C++ EMBEDDED SQL??? Чё, уже никто эту их монстру не покупает? А я вот Hibernate annotations или всякие там JPA юзаю, не зная шибкограмотных слов о "метапрограммировании" и прочих "нанотехнологиях". :-(((

Видать, отстал я от жизни-то.... Бимеры отжигают!

Пока не видел ни одного удобного инструмента для этих целей. Может лет через 10 появятся... Или мода пройдёт... А так - жуткое дело. В динамичных проектах с итерациями, например, по две недели все эти инструменты и подходы вообще нежизнеспособны. Сказочники...

Прочитал как "Искусство метанирования"

> ..."Искусство метанирования"

Медаль!!!

плюспитсот.

>>class Person { public: int id; text name; text address;

>Закопать срочно! Афтар бестолочь, я за такое увольнял.

поясните а то меня уволят

новость для замутнения незамутненных :))

сходи по ссылке. Get_ Set_ нету да?

> сходи по ссылке. Get_ Set_ нету да?

типа public поля и всё такое, инкапсуляции кирдык... впрочем это просто пример

>> сходи по ссылке. Get_ Set_ нету да?

> типа public поля и всё такое, инкапсуляции кирдык... впрочем это просто пример

На UML диаграммах обычно опускают методы доступа. Они просто подразумеваются. Покрайней мере часто такое вижу и сам делаю - чтобы не загромождать чертеж. Вот видать какое-то умное средство (возможно белкового происхождения) и сгенерировало код по диаграмме.

> Разработать модель в начале проекта, а затем не использовать ее кажется расточительным. Также кажется расточительным разработать модель в программе построения диаграмм, а позже переписывать ее в виде кода.

Подобные модели нахрен никому не нужны.

>это просто пример DSL

Это _не_ пример DSL.

>типа public поля и всё такое, инкапсуляции кирдык...

В каком месте инкапсуляция кирдык?

>>>class Person { public: int id; text name; text address;

>>Закопать срочно! Афтар бестолочь, я за такое увольнял.

>поясните а то меня уволят

То что в классе объявляются паблик мемберы - нормально? А зачем тогда на плюсах писать? Короче штудировать основы ООП до просветления, да и в институт на профильную специальность поступить неплохо было бы.

>То что в классе объявляются паблик мемберы - нормально?

А что тут такого?

>Короче штудировать основы ООП до просветления

Какой принцип ООП запрещает обявлять паблик мемберы?

> Какой принцип ООП запрещает обявлять паблик мемберы?

Религия.

Сейчас модно под термином "инкапсуляция" понимать "скрытие данных", даже в учебниках проскальзывает, а инкапсуляция, как известно, основа ООП...

> В каком месте инкапсуляция кирдык?

Имя public доступ к id можно сделать его некорректным, например, выходящим за домен значений. Утверждения типа `внимательно смотри что правишь` не принимаются. Для этого объекты и делают - чтобы сами себя обслуживали. В том числе и контролировали корректность своих полей.

> Короче штудировать основы ООП до просветления

Начни с себя.

> да и в институт на профильную специальность поступить неплохо было бы.

Нам следует признать питон не-ООП языком или что?

> Имя public доступ к id можно сделать его некорректным, например, выходящим за домен значений.

1) Design by Contract давно вошел в *принпипы* ООП?

2) Проверяйте состояние при выполнении метода объекта.

3) В яве геттеры и сеттеры обычно генерятся IDE и нифига не проверяют.

>Имя public доступ к id можно сделать его некорректным, например, выходящим за домен значений

А "не вижу никаких контрактов вокруг значений указанного поля в вышеприведенном тексте" - принимаются?

>Для этого объекты и делают - чтобы сами себя обслуживали. В том числе и контролировали корректность своих полей.

Предположим это объект маппинга на бд - а это так и есть - каким образом ты в него инкапсулируешь уникальность значения id по базе?

> Предположим это объект маппинга на бд

А, даже так...

>> Имея public доступ к id можно сделать его некорректным, например, выходящим за домен значений.

> 1) Design by Contract давно вошел в *принпипы* ООП? > 2) Проверяйте состояние при выполнении метода объекта.

Поясни, пункт 2 не понял. Проверять что-то перед измененим public поля объекта? А если забудешь проверить? Set при некорректных параметрах исключение бросит, а у тебя что?

> 3) В яве геттеры и сеттеры обычно генерятся IDE и нифига не проверяют.

Естественно. Откуда IDE знать какие требования ты накладываешь на поля? Предполагается, что ты сам это напишешь. IDE не заменяет программиста.

> А "не вижу никаких контрактов вокруг значений указанного поля в вышеприведенном тексте" - принимаются?

Да. Такое принимается. Мое высказывание относится к теме 'чем плохи public поля'. В учебном примере методы доступа дают только лишние строки кода. Но в реальной жизни ими нужно пользоваться.

> Поясни, пункт 2 не понял. Проверять что-то перед измененим public поля объекта?

void Class:method() { this->checkState()...

Но учитывая что это объект маппинга, то мы занимаемся пустобрехством.

>Но в реальной жизни ими нужно пользоваться.

Реальная жизнь ограничивает реальными требованиями, а не безосновательными "паблик поля низзя" на пустом месте. В том собственно и состоял суть намека:)

> Предположим это объект маппинга на бд - а это так и есть - каким образом ты в него инкапсулируешь уникальность значения id по базе?

Если мне нужен уникальный id по базе - надо взять current значение нужной последовательности (sequence) в конструкторе класса, который генерирует новый объект.

>Если мне нужен уникальный id по базе - надо взять current значение нужной последовательности (sequence) в конструкторе класса, который генерирует новый объект.

Это если у нас такой сферический мир где в базу никто кроме этой программы не ходит. А если нет?

>>Если мне нужен уникальный id по базе - надо взять current значение нужной последовательности (sequence) в конструкторе класса, который генерирует новый объект. > Это если у нас такой сферический мир где в базу никто кроме этой программы не ходит. А если нет?

А что случится, если у нас будут сотни клиентов и несколько программ? Субд будет им разные последовательности что ли давать? Имеются ввиду sequences, которые в субд.

>а не безосновательными "паблик поля низзя" на пустом месте

Надеюсь ты на плюсах не пишешь, потому что смысла этого языка пока видимо не осилил. По какому критерию создается класс, как думаешь? На классы объекты можно разбить как угодно, но если подключить мозг, то станет ясно, что поля объекта _взаимосвязаны_ а их связь между собой осуществляется методами класса. Так вот, если тебе понадобились паблик поля - ищи ошибки в иерархии классов. Более того, если почитаешь например такого автора как Александреску, то даже методы типа Get и Set на одно и тоже поле занимающиеся его банальным возвращением/установкой - тоже нельзя.

> По какому критерию создается класс, как думаешь?

Да, а _ты_ как думаешь?

> На классы объекты можно разбить как угодно, но если подключить мозг, то станет ясно, что поля объекта _взаимосвязаны_ а их связь между собой осуществляется методами класса.

Н-да... Неужели ты в конструкторе всегда все поля инициализируешь вызовом соответствующих методов? Ну, в принципе, сейчас такая мода имеется. Недаром всякие FF _так_ тормозят!

> Неужели ты в конструкторе всегда все поля инициализируешь вызовом соответствующих методов? Ну, в принципе, сейчас такая мода имеется. Недаром всякие FF _так_ тормозят!

Конструкторы сами собой подразумевают прямой доступ к полям класса, разумеется, при необходимости поля будут определяться соответствующими методами для обеспечения их связи. Но, пожалуйста, не надо подставлять единично вызываемые конструкторы в критерии оценки скорости приложений, написанных на ООП языке.

Безусловно, следовать парадигмам ООП строго обязательно. Но надо уметь вовремя отказаться от ООП вообще в некоторых случах.

а зачем ограничение ?название технологий провоцирует флейм?:)

> Так вот, если тебе понадобились паблик поля - ищи ошибки в иерархии классов. ... даже методы типа Get и Set на одно и тоже поле занимающиеся его банальным возвращением/установкой - тоже нельзя

Очень интересно: есть абстрактная графическая среда. Соотвественно объекты имеют поля с координатами и цветом. Координаты - double, цвет - int, ограничений на значения нет. Что предложишь вместо
point.x = 
point.y = 
rect.x[0] = 
rect.y[0] = 
...
?

точки, многоугольники и т.д. -- объекты, хотя бы из-за виртуального метода render() (+ всякие события типа onclick, onmove, ...).

> Безусловно, следовать парадигмам ООП строго обязательно.

Парадигмы ООП ничего не говорят про скрытие данных. Скрытие не имеет ничего общего с инкапсуляцией, это разные понятия. В ЦеПП скрытие обеспечивается с помощью инкапсуляции, только и всего. Паблик поля ни разу не нарушают парадигму ООП. Без них всегда можно обойтись без потери эффективности, но существуют модели разработки, в которых используются именно паблик поля.

Вдогонку --

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

>Надеюсь ты на плюсах не пишешь, потому что смысла этого языка пока видимо не осилил.

НАверное страуструп тоже этого не осилил раз существует возможность обявлять паблик поля. ТИебе надо в стандартизирующий комитет и обяснить им почему это их язык такую порочную практику предоставляет.

>Искусство метанирования: Часть 3. Копрофагическое метанирование

это про большинство лоровцев-фетишистов, завсегдатаев пометанировать в топиках о языках программирования

а я прочитал как "искусство программирования". и пока не посмотрел, что от ibm, так и не перечитал.

короче я подумал что у кнута крыша поехала))

>>Надеюсь ты на плюсах не пишешь, потому что смысла этого языка пока видимо не осилил.

>НАверное страуструп тоже этого не осилил раз существует возможность обявлять паблик поля. ТИебе надо в стандартизирующий комитет и обяснить им почему это их язык такую порочную практику предоставляет.

Местный дурачок или пытаешься казаться? По твоему Вирт не освоил структурное программирование раз в паскале оператор goto сделал? Возможность безграмотно программировать не стоит перекладывать на создателей языка.

Ну и зачем же тогда в C++ есть public члены в classах, хотя есть structуры?

P.S. goto хотя бы имеет практический смысл в плане быстродействия. А вот зачем бы Страуструпу вводить public члены в class`ы, когда есть публичные по умолчанию struct`уры.

Структуры от классов отличаются только областью видимости по умолчанию, поэтому противопоставлять их друг другу некорректно.

А я о чём? Средства, аналогичного goto (по производительности) - нет. Средство, аналогичное class с публичными членами - есть. Тогда какая рациональ в публичных членах в class`ах, если они удовлетворяют кошерности ООП?

>Возможность безграмотно программировать не стоит перекладывать на создателей языка.

Я не перекладываю. Ты говоришь - паблик поля не тру, Из этого я делаю прямой вывод что создатели языка этого не знали раз есть такая возможность которая по твоему утверждению не нужна и вредна - правильно? Или нужна и невредна? Ты уж определись.