среда, 26 марта 2014 г.
суббота, 22 марта 2014 г.
пятница, 21 марта 2014 г.
Заметки на полях. О "силе" тестов, UML и кодогенерации
Я вот за последние два месяца основательно "перетряхнул" код "базовых классов и базовых библиотек".
"Потроганными" или "изменёнными" оказались около 4 миллионов строк.
Коммитов было произведено несколько сотен.
Несколько десятков классов поменяли наследование. Некоторые классы получили "примеси". И наоборот некоторые "примеси" были убиты.
И "НИЧЕГО" не сломалось. Ни в НАШЕМ проекте, ни в "соседних".
НИЧЕГО.
Некоторые люди этого процесса даже не заметили.
А то, что "ломалось", то находилось ОПЕРАТИВНО, в течении ДНЯ.
Считайте это "рекламной паузой"...
Если вам это интересно - я буду продолжать "рассказывать" о том, как сделать так, чтобы "жить так же".
Чтобы можно было "поменять базовые классы". КАРДТИНАЛЬНО. И "НИЧЕГО" бы не сломалось.
Не спрашивайте меня только "ЗАЧЕМ". :-) Хотя и это - "ХОРОШИЙ ВОПРОС".
"Потроганными" или "изменёнными" оказались около 4 миллионов строк.
Коммитов было произведено несколько сотен.
Несколько десятков классов поменяли наследование. Некоторые классы получили "примеси". И наоборот некоторые "примеси" были убиты.
И "НИЧЕГО" не сломалось. Ни в НАШЕМ проекте, ни в "соседних".
НИЧЕГО.
Некоторые люди этого процесса даже не заметили.
А то, что "ломалось", то находилось ОПЕРАТИВНО, в течении ДНЯ.
Считайте это "рекламной паузой"...
Если вам это интересно - я буду продолжать "рассказывать" о том, как сделать так, чтобы "жить так же".
Чтобы можно было "поменять базовые классы". КАРДТИНАЛЬНО. И "НИЧЕГО" бы не сломалось.
Не спрашивайте меня только "ЗАЧЕМ". :-) Хотя и это - "ХОРОШИЙ ВОПРОС".
Offtopic. К сожалению. ОПЯТЬ про Украину и Крым. Не могу промолчать
Я написал это в FaceBook.
Но!
Я не могу оставаться "просто программистом". И рассуждать "о прелестях TDD или UML или Python" при том, что в мире творится "такое".
Я хочу, чтобы моя позиция была ПОНЯТНА и ИЗВЕСТНА тем людям, которые читают меня (если читают) как профессионалы.
Потому, что "обсуждение технических вопросов это конечно ХОРОШО", но БЕЗ понимания "позиции собеседника" - невозможно полностью оценить "его подход".
Кто бы что ни говорил.
Если человек "неприятен тебе с "бытовой точки зрения", то он тебе будет и неприятен как профессионал". Это - ФАКТ.
Посему - пусть я уж лучше буду "неприятен с бытовой точки зрения" и "потенциальные конфликты" могут отсечься "сразу".
Итак.
Вот что я думаю по поводу САЛЮТА в Москве в честь присоединения Крыма:
"считайте меня "русофобом" и "не патриотом", но САЛЮТ в ЧЕСТЬ ПРИСОЕДИНЕНИЯ Крыма, который я наблюдал в Москве - ЭТО ПЕРЕБОР... Понимаете.. Я САМ - "за" присоединение Крыма.. Ну в "таких реалиях".. В силу "исторической справедливости", защиты соотечественников и всё такое.. Хотя и ПОВТОРЮ - я не считаю это ЗАКОННЫМ с точки зрения БУКВЫ и ДУХА... Но уж "получилось как получилось".. МЫ (наша страна) - НЕ ДАЛИ СЕБЯ ПРОГНУТЬ, а ПРОГНУЛИ ДРУГИХ.. Но! Устраивать "танцы на костях".. "ОТЖАЛИ территорию у БРАТСКОГО народа" это - ПЕРЕБОР.. Или НАРОД уже и "не братский"?
Но!
Я не могу оставаться "просто программистом". И рассуждать "о прелестях TDD или UML или Python" при том, что в мире творится "такое".
Я хочу, чтобы моя позиция была ПОНЯТНА и ИЗВЕСТНА тем людям, которые читают меня (если читают) как профессионалы.
Потому, что "обсуждение технических вопросов это конечно ХОРОШО", но БЕЗ понимания "позиции собеседника" - невозможно полностью оценить "его подход".
Кто бы что ни говорил.
Если человек "неприятен тебе с "бытовой точки зрения", то он тебе будет и неприятен как профессионал". Это - ФАКТ.
Посему - пусть я уж лучше буду "неприятен с бытовой точки зрения" и "потенциальные конфликты" могут отсечься "сразу".
Итак.
Вот что я думаю по поводу САЛЮТА в Москве в честь присоединения Крыма:
"считайте меня "русофобом" и "не патриотом", но САЛЮТ в ЧЕСТЬ ПРИСОЕДИНЕНИЯ Крыма, который я наблюдал в Москве - ЭТО ПЕРЕБОР... Понимаете.. Я САМ - "за" присоединение Крыма.. Ну в "таких реалиях".. В силу "исторической справедливости", защиты соотечественников и всё такое.. Хотя и ПОВТОРЮ - я не считаю это ЗАКОННЫМ с точки зрения БУКВЫ и ДУХА... Но уж "получилось как получилось".. МЫ (наша страна) - НЕ ДАЛИ СЕБЯ ПРОГНУТЬ, а ПРОГНУЛИ ДРУГИХ.. Но! Устраивать "танцы на костях".. "ОТЖАЛИ территорию у БРАТСКОГО народа" это - ПЕРЕБОР.. Или НАРОД уже и "не братский"?
Понимаете.. Это НЕ ПОБЕДА под "Курском или Сталинградом"..
ЭТО НЕ "немцев победили".
Это НЕ "взяли Берлин" и "утёрли нос фашистким ГАДАМ".
Это - ВЫНУЖДЕННАЯ МЕРА! Потому, что "так сложилось". Потому что "часть людей захотела "домой"".
Потому что ДРУГАЯ ЧАСТЬ людей - ВЕЛИ СЕБЯ как "идиоты"!
Это НЕ ПРАЗДНИК. Это - ДЕНЬ СКОРБИ.
Скорби по БРАТСКОМУ НАРОДУ, который отвернулся от нас. И от которого МЫ ОТВЕРНУЛИСЬ.
Если бы дело было ТОЛЬКО в "правом секторе", то - БАЗАРА НЕТ - мочить без разговоров. Но!
Остаётся Украина! Как ГОСУДАРСТВО (вообще-то). И это БЕДА, что там к власти пришли ИДИОТЫ. Но это НЕ ПОВОД, что-то ПРАЗДНОВАТЬ.
ЗАЩИЩАТЬ - ДА!
ПОМОГАТЬ - ДА!
ДАВИТЬ НА ИДИОТОВ - ДА!
ПОМОГАТЬ - ДА!
ДАВИТЬ НА ИДИОТОВ - ДА!
Но НЕ ПРАЗДНОВАТЬ...
Простите.. Я хотя и резок на язык, но я - идеалист...
К сожалению."
Можете НЕ ПРИНИМАТЬ или (наоборот) ПРИНИМАТЬ мою точку зрения. Я на ней не НАСТАИВАЮ. Но я ЧЕСТНО ЕЁ озвучил.
P.S. Чтобы меня не записали в "пятую колонну" или что-то подобное - ПОВТОРЮ, я ГОЛОСОВАЛ ЗА Путина. Я НЕ ЧЛЕН "Единой России" и считаю эту партию "слабой пародией на КПСС". Но! Альтернативы Путину - я как не видел, так и НЕ ВИЖУ. К СОЖАЛЕНИЮ...
И ещё... Самая моя БОЛЬШАЯ претензия к слову - ПРАЗДНИК... Не праздник это, а горе... Горе того, что "ни те, ни другие" НЕ СМОГЛИ ДОГОВОРИТЬСЯ.
четверг, 20 марта 2014 г.
Ссылка. Ingword. мисли обо всем. в основном о программировании
http://ingword.blogspot.ru/
Цитата:
Цитата:
Тестирование процедур FireBird.
0. (инициаторы - клиенты либо тестеры).
- Выявили баг.
- Экспортировали данные(все включая метаданные) БД в скрипт.
1. (TODO Распределить роли в алгоритме, если возможно - автоматизировать)
- Скрипт зафиксировали в GIT(TODO Написать структуру.)
- Копируем "АБСОЛЮТНО ЧИСТУЮ" БД.
- Натягиваем на неё скрипт из GIT с данными.
- Это всё подготовка к *Test.SetUp был.
И первая часть вопроса решена.
- У нас есть баг(обращение пользователя).
- У нас есть "состояние окружения" на момент "бага".
2. Конкретная работа программиста, опять же автоматизированная.
- Копируем чистую БД куда-нибудь(TODO придумать структуру).
- Поднимаем SetUp.
3. Собственно тесты.
- Пишем 'execute * from Pr*(x,y,z)' скрипт.
- Запускаем на БД.
- Сравниваем.
- Тут мы должны пролететь с "красной фишкой".
- Меняем процедуру в чистой БД.
- Запускаем пункт 3.1 и ниже, пока не получим "зеленый результат".
- Видим "зеленый" результат.
- Либо ковыряем процедуру, как нам надо с тестами.
- Либо закрываем задачу.
- Оставляем на Confluence ID теста.
среда, 19 марта 2014 г.
Offtopic. Заметки дилетанта "об Украине", бряцаньи оружием и "ядерном потенциале"
Преамбула: Я ВСЮ ЖИЗНЬ считал (слава Советской пропаганде), что Япония была "безвинной жертвой американских бомбардировок". Я ДАЖЕ "не знал", что Япония была ПРОТИВНИКОМ Советского Союза в ВОЙНЕ (в Великой Войне) против Германии "и её саттелитов".
Теперь - я "узнал", что Япония была НАШИМ ПРОТИВНИКОМ.
Но это НИЧЕГО НЕ МЕНЯЕТ.
США применив БОМБУ превысили ВСЯЧЕСКИЕ РАЗУМНЫЕ пределы.
Цель? Цель- БАНАЛЬНА - "указать дядюшке Джо на ЕГО МЕСТО".
Преамбула закончилась.
Итак.
ЕЩЁ РАЗ скажу - Я ПРОТИВ ВОЙНЫ.
Особенно - России с Украиной.
ЕЩЁ РАЗ скажу - Я ПРОТИВ ВОЙНЫ.
И я САМ ЛИЧНО на эту войну - НЕ ПОЙДУ. Если только вдруг не окажется, что "враг у ворот".
Считайте меня "диванной сотней" и пораженцем.
Но! Хочу написать об "истоках бряцанья оружием".
Кто как не США, скинув БОМБУ на Японию показали "Дядюшке Джо" КТО ТУТ ГЛАВНЫЙ.
СССР рассчитывал на "многомиллионную армию" и "армады танков", а тут такая ПОДСТАВА - БОМБА.
РЕАЛЬНАЯ БОМБА.
Бомбардировка Дрездена покажется "детским лепетом".
"Дядюшка Джо" хотел "делить Европу" на ПРАВАХ ПОБЕДИТЕЛЯ, а ему УКАЗАЛИ НА МЕСТО.
Ни тебе проливов, ни тебе "греческого проекта".
Победу - УКРАЛИ.
Это я так сказать "под маской сегодняшнего либерала" написал.
Но это - НЕДАЛЕКО от ИСТИНЫ.
Ни проливов, ни Греции, ни Австрии - "нам не досталось".
"Либералы" скажут - И СЛАВА БОГУ - "чуть меньше от мира досталось "кровавым коммунистическим режимам"".
Может и так.
Хотя я СКЛОНЕН думать ПО-ДРУГОМУ.
У меня (к сожалению, а может и к счастью) - ДАВНИШНЯЯ "советская история".
Я - "продукт СВОЕГО времени".
Но всё же о "бряцаньи оружием":
http://www.ca-c.org/c-g/2008/journal_rus/c-g-2/01.shtml
"Позднее президент США Гарри Трумэн утверждал, что оказал Ирану такую поддержку, послав Сталину ультимативный сигнал. Впервые глава Белого дома упомянул об этом, выступая на пресс-конференции 24 апреля 1952 года. На просьбу обнародовать документ Трумэн ответил отказом, заметив, что никакого "ультиматума" не было, и, употребив этот термин, он допустил техническую ошибку. После вступления советских войск в Афганистан в 1979 году в США вновь вспомнили об "ультиматуме" Трумэна. В январе 1980-го сенатор Генри Джексон опубликовал заявления Трумэна в журнале "Тайм" под заглавием "Прекрасные дни прошлого". По его версии, в ходе азербайджанского кризиса 1946 года Трумэн вызвал к себе посла СССР в США Андрея Громыко и заявил, что если в течение 48 часов Красная Армия не покинет Иран, то Соединенные Штаты применят против Советского Союза атомную бомбу"
ЕЩЁ раз!
"если в течение 48 часов Красная Армия не покинет Иран, то Соединенные Штаты применят против Советского Союза атомную бомбу"
КОГДА у СССР БОМБЫ - НЕ БЫЛО..
Кто бряцал?
И ещё:
http://wordweb.ru/coldwar/101.htm
"Впервые после второй мировой войны в воздухе запахло порохом. Американский консул в Северном Иране ездил с инспекциями: как готовится уход советских войск. В здании госдепартамента была приготовлена большая карта Северного Ирана, и стрелы показывали движение советских войск. Трумэн открыто говорил, что не потерпит «советизированного Ирана».
Во время визита Кавама в Москву советские руководители произносили бравые речи, но практически всем наблюдателям было ясно, что Советский Союз испытывает значительные опасения. И правительство Соединенных Штатов в данном случае действовало исходя из (ложного) предположения, что СССР постарается захватить Иран, как минимум, удержаться в его северной части.
5 марта 1946 г. государственный департамент послал министерству иностранных дел СССР ноту, предупреждающую, что «Соединенные Штаты не могут оставаться индифферентными» к положению в Иране «. США угрожали силой по поводу событий в этом регионе, отстоявшем от США на расстоянии, почти равном половине экватора. Можно вообразить эффект, который имела бы советская нота, пытающаяся регулировать отношения США с Мексикой! Неопровержимо, и с этим согласны большинство американских историков, что СССР был настроен искать компромиссное решение.
Даже генеральный секретарь ООН Трюгве Ли советовал американцам предоставить инициативу советско-иранским переговорам и не вмешивать ООН в решаемое дело. Не тут-то было. Американские дипломаты только повысили тон. Советский представитель с ООН Громыко заявил, что СССР выведет войска к 10 апреля. Американцы оказывали невиданное давление на Тегеран, требуя от того жесткости в отношении СССР. Бирнс лично приехал в Нью-Йорк и далеко не дипломатичным языком требовал ухода русских из Ирана. (Интересно, как американцы восприняли бы советское требование покинуть, скажем, Гуантанамо?) Находясь под невиданным психологическим давлением, Громыко покинул Совет Безопасности. Первый в череде случай.
Советский Союз высоко ценил свои отношения с союзником времен войны. В апреле 1946 г. советские войска покинули иранскую территорию. (Говоря объективно, это был результат советско иранской договоренности, а не давления США). Но американская дипломатия уже закусила удила. Эта акция Советского Союза стала подаваться, как «уступка американской твердости, которой ничто в мире не могло противостоять»"
Если "ссылки на интернет не вызывают доверие" - могу поискать печатные источники.
Вот так...
Разговор с позиции "большой дубины"...
Киселёва с его "ядерным пеплом" это конечно не оправдывает, но "надо смотреть правде в лицо".
И ИМЕННО поэтому ВЕДОМСТВО Берии работало с УТРОЕННОЙ силой, чтобы "Советский Союз получил БОМБУ".
Чтобы было негоже "махать ядерной дубинкой".
Про Украину скажу лишь одно - удивительно (да и хорошо для нас для всех, как выясняется), что "тогда" она отказалась от своей части "ядерного потенциала". Хотя может быть если бы у Украины БЫЛ БЫ "ядерный потенциал", то и Европа и США и Россия - вели бы себя бы СДЕРЖАННЕЕ и ВЗВЕШЕННЕЕ.
Скажу КОНКРЕТНЕЕ - "если бы ГОСПОДА на ЗАПАДЕ, знали бы, что НА УКРАИНЕ есть ядерное оружие, то они бы вряд ли бы "подпустили к кнопке Яроша"". Так ПОНЯТНО?
Но и С ДРУГОЙ стороны - КОНЕЧНО Россия - вряд ли бы "оттяпала бы Крым". Это тоже - понятно.
Но! СКОРЕЕ ВСЕГО (я верю в это) - и ОТТЯПЫВАТЬ ничего бы и не пришлось.
Ибо ВСЕ В МИРЕ сделали бы ВСЁ ВОЗМОЖНОЕ, чтобы НЕ ДОПУСТИТЬ неадекватов к "кнопке".
Я подозреваю вопрос - "а в России у кнопки находятся ли адекваты"? НЕ ЗНАЮ. НАДЕЮСЬ, что ВСЁ ЖЕ НАХОДЯТСЯ. НАДЕЮСЬ!
БЛИЖАЙШАЯ ИСТОРИЯ - покажет :-(
Теперь - я "узнал", что Япония была НАШИМ ПРОТИВНИКОМ.
Но это НИЧЕГО НЕ МЕНЯЕТ.
США применив БОМБУ превысили ВСЯЧЕСКИЕ РАЗУМНЫЕ пределы.
Цель? Цель- БАНАЛЬНА - "указать дядюшке Джо на ЕГО МЕСТО".
Преамбула закончилась.
Итак.
ЕЩЁ РАЗ скажу - Я ПРОТИВ ВОЙНЫ.
Особенно - России с Украиной.
ЕЩЁ РАЗ скажу - Я ПРОТИВ ВОЙНЫ.
И я САМ ЛИЧНО на эту войну - НЕ ПОЙДУ. Если только вдруг не окажется, что "враг у ворот".
Считайте меня "диванной сотней" и пораженцем.
Но! Хочу написать об "истоках бряцанья оружием".
Кто как не США, скинув БОМБУ на Японию показали "Дядюшке Джо" КТО ТУТ ГЛАВНЫЙ.
СССР рассчитывал на "многомиллионную армию" и "армады танков", а тут такая ПОДСТАВА - БОМБА.
РЕАЛЬНАЯ БОМБА.
Бомбардировка Дрездена покажется "детским лепетом".
"Дядюшка Джо" хотел "делить Европу" на ПРАВАХ ПОБЕДИТЕЛЯ, а ему УКАЗАЛИ НА МЕСТО.
Ни тебе проливов, ни тебе "греческого проекта".
Победу - УКРАЛИ.
Это я так сказать "под маской сегодняшнего либерала" написал.
Но это - НЕДАЛЕКО от ИСТИНЫ.
Ни проливов, ни Греции, ни Австрии - "нам не досталось".
"Либералы" скажут - И СЛАВА БОГУ - "чуть меньше от мира досталось "кровавым коммунистическим режимам"".
Может и так.
Хотя я СКЛОНЕН думать ПО-ДРУГОМУ.
У меня (к сожалению, а может и к счастью) - ДАВНИШНЯЯ "советская история".
Я - "продукт СВОЕГО времени".
Но всё же о "бряцаньи оружием":
http://www.ca-c.org/c-g/2008/journal_rus/c-g-2/01.shtml
"Позднее президент США Гарри Трумэн утверждал, что оказал Ирану такую поддержку, послав Сталину ультимативный сигнал. Впервые глава Белого дома упомянул об этом, выступая на пресс-конференции 24 апреля 1952 года. На просьбу обнародовать документ Трумэн ответил отказом, заметив, что никакого "ультиматума" не было, и, употребив этот термин, он допустил техническую ошибку. После вступления советских войск в Афганистан в 1979 году в США вновь вспомнили об "ультиматуме" Трумэна. В январе 1980-го сенатор Генри Джексон опубликовал заявления Трумэна в журнале "Тайм" под заглавием "Прекрасные дни прошлого". По его версии, в ходе азербайджанского кризиса 1946 года Трумэн вызвал к себе посла СССР в США Андрея Громыко и заявил, что если в течение 48 часов Красная Армия не покинет Иран, то Соединенные Штаты применят против Советского Союза атомную бомбу"
ЕЩЁ раз!
"если в течение 48 часов Красная Армия не покинет Иран, то Соединенные Штаты применят против Советского Союза атомную бомбу"
КОГДА у СССР БОМБЫ - НЕ БЫЛО..
Кто бряцал?
И ещё:
http://wordweb.ru/coldwar/101.htm
"Впервые после второй мировой войны в воздухе запахло порохом. Американский консул в Северном Иране ездил с инспекциями: как готовится уход советских войск. В здании госдепартамента была приготовлена большая карта Северного Ирана, и стрелы показывали движение советских войск. Трумэн открыто говорил, что не потерпит «советизированного Ирана».
Во время визита Кавама в Москву советские руководители произносили бравые речи, но практически всем наблюдателям было ясно, что Советский Союз испытывает значительные опасения. И правительство Соединенных Штатов в данном случае действовало исходя из (ложного) предположения, что СССР постарается захватить Иран, как минимум, удержаться в его северной части.
5 марта 1946 г. государственный департамент послал министерству иностранных дел СССР ноту, предупреждающую, что «Соединенные Штаты не могут оставаться индифферентными» к положению в Иране «. США угрожали силой по поводу событий в этом регионе, отстоявшем от США на расстоянии, почти равном половине экватора. Можно вообразить эффект, который имела бы советская нота, пытающаяся регулировать отношения США с Мексикой! Неопровержимо, и с этим согласны большинство американских историков, что СССР был настроен искать компромиссное решение.
Даже генеральный секретарь ООН Трюгве Ли советовал американцам предоставить инициативу советско-иранским переговорам и не вмешивать ООН в решаемое дело. Не тут-то было. Американские дипломаты только повысили тон. Советский представитель с ООН Громыко заявил, что СССР выведет войска к 10 апреля. Американцы оказывали невиданное давление на Тегеран, требуя от того жесткости в отношении СССР. Бирнс лично приехал в Нью-Йорк и далеко не дипломатичным языком требовал ухода русских из Ирана. (Интересно, как американцы восприняли бы советское требование покинуть, скажем, Гуантанамо?) Находясь под невиданным психологическим давлением, Громыко покинул Совет Безопасности. Первый в череде случай.
Советский Союз высоко ценил свои отношения с союзником времен войны. В апреле 1946 г. советские войска покинули иранскую территорию. (Говоря объективно, это был результат советско иранской договоренности, а не давления США). Но американская дипломатия уже закусила удила. Эта акция Советского Союза стала подаваться, как «уступка американской твердости, которой ничто в мире не могло противостоять»"
Если "ссылки на интернет не вызывают доверие" - могу поискать печатные источники.
Вот так...
Разговор с позиции "большой дубины"...
Киселёва с его "ядерным пеплом" это конечно не оправдывает, но "надо смотреть правде в лицо".
И ИМЕННО поэтому ВЕДОМСТВО Берии работало с УТРОЕННОЙ силой, чтобы "Советский Союз получил БОМБУ".
Чтобы было негоже "махать ядерной дубинкой".
Про Украину скажу лишь одно - удивительно (да и хорошо для нас для всех, как выясняется), что "тогда" она отказалась от своей части "ядерного потенциала". Хотя может быть если бы у Украины БЫЛ БЫ "ядерный потенциал", то и Европа и США и Россия - вели бы себя бы СДЕРЖАННЕЕ и ВЗВЕШЕННЕЕ.
Скажу КОНКРЕТНЕЕ - "если бы ГОСПОДА на ЗАПАДЕ, знали бы, что НА УКРАИНЕ есть ядерное оружие, то они бы вряд ли бы "подпустили к кнопке Яроша"". Так ПОНЯТНО?
Но и С ДРУГОЙ стороны - КОНЕЧНО Россия - вряд ли бы "оттяпала бы Крым". Это тоже - понятно.
Но! СКОРЕЕ ВСЕГО (я верю в это) - и ОТТЯПЫВАТЬ ничего бы и не пришлось.
Ибо ВСЕ В МИРЕ сделали бы ВСЁ ВОЗМОЖНОЕ, чтобы НЕ ДОПУСТИТЬ неадекватов к "кнопке".
Я подозреваю вопрос - "а в России у кнопки находятся ли адекваты"? НЕ ЗНАЮ. НАДЕЮСЬ, что ВСЁ ЖЕ НАХОДЯТСЯ. НАДЕЮСЬ!
БЛИЖАЙШАЯ ИСТОРИЯ - покажет :-(
вторник, 18 марта 2014 г.
суббота, 15 марта 2014 г.
пятница, 14 марта 2014 г.
Ссылка. C++ 11 FAQ от Бьярна Страуструпа. Перевод от Теплякова
http://sergeyteplyakov.blogspot.ru/2012/05/c-11-faq.html
Ещё раз публикую ссылку.
Чтобы ВСЕ (интересующиеся) наконец поняли, что такое "НАСТОЯЩЕЕ" мета-программирование.
Чтобы про "макросы" ну не было уж больше разговоров.
Ну 21-й век на дворе.. А "макросы" относятся к 50-60-м годам ПРОШЛОГО века. Вспомним макро-ассемблер PDP-11. Ну смешно. Когда-то БЫЛО АКТУАЛЬНО. Теперь - СМЕШНО.
Надо думать уже о "мета-программировании". И C++ 11 - ШАГ к нему.
ХОТЯ - дальнейшие шаги уже НАДО ДЕЛАТЬ.
Продолжу "дуть в свою дуду" - UML И кодогенерация СТЕРЕОТИПОВ.
Хотя - ДРУГИХ альтернатив - МНОЖЕСТВО.
Например Duck-Typing. Скажете вы. Да! И он - ТОЖЕ!
ХОТЯ я ЛИЧНО - ЗА СТАТИЧЕСКУЮ типизацию. По мере компиляции кода.
Что в C++ 11 мы и ИМЕЕМ.
С одной стороны - "параметризуемость" и "шаблонизация".
А с другой стороны - СТАТИЧЕСКАЯ типизация.
МНЕ ЛИЧНО - ИМЕННО этот подход импонирует.
Ну если откинуть в сторону кодогенерацию.
Ещё раз публикую ссылку.
Чтобы ВСЕ (интересующиеся) наконец поняли, что такое "НАСТОЯЩЕЕ" мета-программирование.
Чтобы про "макросы" ну не было уж больше разговоров.
Ну 21-й век на дворе.. А "макросы" относятся к 50-60-м годам ПРОШЛОГО века. Вспомним макро-ассемблер PDP-11. Ну смешно. Когда-то БЫЛО АКТУАЛЬНО. Теперь - СМЕШНО.
Надо думать уже о "мета-программировании". И C++ 11 - ШАГ к нему.
ХОТЯ - дальнейшие шаги уже НАДО ДЕЛАТЬ.
Продолжу "дуть в свою дуду" - UML И кодогенерация СТЕРЕОТИПОВ.
Хотя - ДРУГИХ альтернатив - МНОЖЕСТВО.
Например Duck-Typing. Скажете вы. Да! И он - ТОЖЕ!
ХОТЯ я ЛИЧНО - ЗА СТАТИЧЕСКУЮ типизацию. По мере компиляции кода.
Что в C++ 11 мы и ИМЕЕМ.
С одной стороны - "параметризуемость" и "шаблонизация".
А с другой стороны - СТАТИЧЕСКАЯ типизация.
МНЕ ЛИЧНО - ИМЕННО этот подход импонирует.
Ну если откинуть в сторону кодогенерацию.
Коротко. Про конструкторы и свойства...
Что лучше?
Так:
Или так:
Для меня лично - "ответ очевиден", а для вас?
К "чему вопрос"? А к тому, что "лучшие производители" делают "часто" не так, как я 2считаю правильным".
И кстати "это всё" тянет за собой "долгое и сложное" обсуждение на тему Mutable и Immutable объектов.
Читаем Барбару Лисков. А именно книгу "Применение абстракций и спецификаций при разработке ПО" (http://padabum.com/d.php?id=34996).
Так очень много внимания уделяется константности и эквивалентности объектов.
Над этим (ИМХО) стоит задуматься... Хотя "людям воспитанным на Delphi" многое может "показаться странным"...
Особенно константность.. И "сопоставление объектов с числами".. Есть атомарное значение - 2 и есть атомарное значение 3. Для того чтобы получить 5 - надо сложить 2 и 3 и получить НОВЫЙ объект. А НЕ ИЗМЕНИТЬ состояние существующих.
На "ту же тему" - http://18delphi.blogspot.ru/2013/10/immutable.html
Ну и ещё...
Сейчас "много тем муссируется" насчёт Функциональных Языков.
В частности "на тему" ДЕТЕРМИНИРОВАННОСТИ состояний.
Так вот - "константность" или ДЕТЕРМИНИРОВАННОСТЬ - ДАВНО придумана Барбарой Лисков... Без всяких "функциональных языков", да и "ООП кстати". Ну если я "правильно читал"..
Так:
MyObj := TMyObj.Create(aParam1, aParam2, aParam3);
Или так:
MyObj := TMyObj.Create; MyObj.Param1 := aParam1; MyObj.Param2 := aParam2; MyObj.Param3 := aParam3;
Для меня лично - "ответ очевиден", а для вас?
К "чему вопрос"? А к тому, что "лучшие производители" делают "часто" не так, как я 2считаю правильным".
И кстати "это всё" тянет за собой "долгое и сложное" обсуждение на тему Mutable и Immutable объектов.
Читаем Барбару Лисков. А именно книгу "Применение абстракций и спецификаций при разработке ПО" (http://padabum.com/d.php?id=34996).
Так очень много внимания уделяется константности и эквивалентности объектов.
Над этим (ИМХО) стоит задуматься... Хотя "людям воспитанным на Delphi" многое может "показаться странным"...
Особенно константность.. И "сопоставление объектов с числами".. Есть атомарное значение - 2 и есть атомарное значение 3. Для того чтобы получить 5 - надо сложить 2 и 3 и получить НОВЫЙ объект. А НЕ ИЗМЕНИТЬ состояние существующих.
На "ту же тему" - http://18delphi.blogspot.ru/2013/10/immutable.html
Ну и ещё...
Сейчас "много тем муссируется" насчёт Функциональных Языков.
В частности "на тему" ДЕТЕРМИНИРОВАННОСТИ состояний.
Так вот - "константность" или ДЕТЕРМИНИРОВАННОСТЬ - ДАВНО придумана Барбарой Лисков... Без всяких "функциональных языков", да и "ООП кстати". Ну если я "правильно читал"..
четверг, 13 марта 2014 г.
Кратко. Метод Assign в TPersistent (особенно как виртуальный) - НАФИГ не нужен
По мотивам - http://programmingmindstream.blogspot.ru/2014/03/blog-post_12.html?showComment=1394668252836#c4599232239970773885
Метод Assign в TPersistent (особенно как виртуальный) - НАФИГ не нужен.
Почему?
До потому, что ВИРТУАЛЬНОСТЬ - НИГДЕ практически НЕ ИСПОЛЬЗУЕТСЯ.
Проще было сделать TFont.Assign(aFont: TFont), TBitmap.Assign(aBitmap: TBitmap) etc.
Доказательства?
Почитайте исходники VCL.
Метод Assign в TPersistent (особенно как виртуальный) - НАФИГ не нужен.
Почему?
До потому, что ВИРТУАЛЬНОСТЬ - НИГДЕ практически НЕ ИСПОЛЬЗУЕТСЯ.
Проще было сделать TFont.Assign(aFont: TFont), TBitmap.Assign(aBitmap: TBitmap) etc.
Доказательства?
Почитайте исходники VCL.
Ну и про IStream.CopyTo
По мотивам - http://programmingmindstream.blogspot.ru/2014/03/blog-post_9768.html
Понятно, что CopyTo ВЫВОДИТСЯ из ОСТАЛЬНЫХ методов IStream. (хотя он у меня и написан в контексте "неймспейса" IStream, но понимающие люди увидят, что его легко можно "вынести за скобки")
Ссылка на код - https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3BaseStream.pas
Сам код:
Понятно, что CopyTo ВЫВОДИТСЯ из ОСТАЛЬНЫХ методов IStream. (хотя он у меня и написан в контексте "неймспейса" IStream, но понимающие люди увидят, что его легко можно "вынести за скобки")
Ссылка на код - https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3BaseStream.pas
Сам код:
function Tl3Stream.IStreamCopyTo(stm: IStream; cb: Large; out cbRead: Large;
out cbWritten: Large): HResult;
const
MaxBufSize = 1024 * 1024; // 1mb
var
Buffer : Pointer;
BufSize : Integer;
l_IntPartSize : Long;
l_NeedToRead : Long;
l_ReadedPart : Long;
BytesRead,
BytesWritten,
W : Large;
begin
{$IfDef nsTest}
Assert(g_IStreamCopyTo_Guard <= 0);
{$EndIf nsTest}
Result := S_OK;
BytesRead := 0;
BytesWritten := 0;
try
if (cb > MaxBufSize) then
BufSize := MaxBufSize
else
BufSize := Integer(cb);
l3System.GetLocalMem(Buffer, BufSize);
try
while cb > 0 do
begin
if cb > MaxInt then
l_IntPartSize := MaxInt
else
l_IntPartSize := cb;
while (l_IntPartSize > 0) do begin
if (l_IntPartSize > BufSize) then l_NeedToRead := BufSize else l_NeedToRead := l_IntPartSize;
l_ReadedPart := Self.Read(Buffer^, l_NeedToRead);
if (l_ReadedPart = 0) then Exit;
Inc(BytesRead, l_ReadedPart);
W := 0;
Result := stm.Write(Buffer, l_ReadedPart, @W);
Inc(BytesWritten, W);
if (Result = S_OK) and (Integer(W) <> l_ReadedPart) then Result := E_FAIL;
if Result <> S_OK then Exit;
Dec(l_IntPartSize, l_ReadedPart);
end;
Dec(cb, l_IntPartSize);
end;
finally
l3System.FreeLocalMem(Buffer);
if (@cbWritten <> nil) then cbWritten := BytesWritten;
if (@cbRead <> nil) then cbRead := BytesRead;
end;//try..finally
except
Result := E_UNEXPECTED;
end;//try..finally
end;
Языки "где так или иначе" возможны примеси
Продолжая тему - http://programmingmindstream.blogspot.ru/2014/03/blog-post_12.html
Итак..
Просто список:
1. C++ (множественное наследование).
2. Python (множественное наследование и Duck-typing).
3. Objective-C (Duck-typing и "селекторы" и "перехват селекторов").
4. Objective-C++ (см. выше ну и как надмножество над C++).
5. Smalltalk ("сообщения", а не методы и возможность обработки "необъявленных явно сообщений").
6. Delphi ("криво", через "хак" и include - http://18delphi.blogspot.ru/2013/03/blog-post_29.html (ну иок ещё)).
7. "Птичий язык" от Макса (http://18delphi.blogspot.ru/2013/10/blog-post_4433.html) (множественное наследование и Duck-typing).
8. Java (рефлексия и возможность управления байт-кодом (если я не ошибаюсь)). (http://ru.wikipedia.org/wiki/%D0%90%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
9. FORTH (да и любые другие Конкатенативные языки - http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D0%BA%D0%B0%D1%82%D0%B5%D0%BD%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F). А также LISP и Scheme ("Конктенативные языки можно рассматривать как семейство языков, вроде Лисп-языков. Так между всеми диалектами Лиспа (включая Scheme), есть сильное «семейное сходство». Однако есть большая разница в дизайне, реализации и назначении этих языков. Языки программируемых микрокалькуляторов и многие из версий Форта предназначены для встраивания в небольшие микропроцессорные системы; PostScript также является встраиваемым языком, только микропроцессорные системы, интерпретирующие его называютсяпринтерами. Однако другие конкатенативные языки, такие как Joy или Cat разработаны как языки программирования общего назначения или в исследовательских целях." там же)
И ещё...
В СЕТИ - была ХОРОШАЯ статья - "почему отдельностоящие методы ЛУЧШЕ методов классов".
Я никак не могу найти ссылку на неё. (Если найдёте - ПРИСЫЛАЙТЕ - с меня пиво или коньяк, ну или что вы там хотите.. в разумных пределах...).
Так вот.
В статье ПОКАЗЫВАЛОСЬ - почему "отдельностоящие методы" ЛУЧШЕ методов классов. И как это ПОНИЖАЕТ "связность" и УЛУЧШАЕТ архитектуру. Тут не премину вспомнить IStream (О УЖАС) (http://msdn.microsoft.com/en-us/library/windows/desktop/aa380034(v=vs.85).aspx) и IDataObject (О УЖАС УЖАС) (http://msdn.microsoft.com/en-us/library/windows/desktop/ms688421(v=vs.85).aspx).
Это вещь "ортогональная" примесям, но "на ту же тему"...
Про IDataObject хочу сказать - GetData и GetDataHere. Одно выводится ЧЕРЕЗ другое. И должно было быть сделано "хелперами" или "отдельностоящими методами". Но! MS предпочёл ОБЯЗАТЬ ВСЕХ реализовывать ОБА метода.. Причём каждый из них является "спорным" сам по-себе. Чего только "развесистость" FORMATETC (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682177(v=vs.85).aspx) и STGMEDIUM (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683812(v=vs.85).aspx) стоят.
Это - УЖАС, а не "интерфейс".
Я его РЕАЛИЗОВАЛ и НЕ РАЗ и НЕ ДВА. И в итоге сделал "базовый класс". От которого наследуются все остальные. И наследники СИЛЬНО ПРОЩЕ исходного интерфейса. Они переопределяют один/два метода.
Я об этом позже напишу.. Если хватит сил.
Пока вот вам ссылки:
1. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3DataObject.pas
2. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3BitmapDataObject.pas
3. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3DataObjectEnum.pas
4. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3InterfacedDataObject.imp.pas
5. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3StorableDataObject.pas
6. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3TreeDataObject.imp.pas
Итак..
Просто список:
1. C++ (множественное наследование).
2. Python (множественное наследование и Duck-typing).
3. Objective-C (Duck-typing и "селекторы" и "перехват селекторов").
4. Objective-C++ (см. выше ну и как надмножество над C++).
5. Smalltalk ("сообщения", а не методы и возможность обработки "необъявленных явно сообщений").
6. Delphi ("криво", через "хак" и include - http://18delphi.blogspot.ru/2013/03/blog-post_29.html (ну иок ещё)).
7. "Птичий язык" от Макса (http://18delphi.blogspot.ru/2013/10/blog-post_4433.html) (множественное наследование и Duck-typing).
8. Java (рефлексия и возможность управления байт-кодом (если я не ошибаюсь)). (http://ru.wikipedia.org/wiki/%D0%90%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%BD%D0%BE-%D0%BE%D1%80%D0%B8%D0%B5%D0%BD%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%BD%D0%BE%D0%B5_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5)
9. FORTH (да и любые другие Конкатенативные языки - http://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%BD%D0%BA%D0%B0%D1%82%D0%B5%D0%BD%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D1%8B%D0%B9_%D1%8F%D0%B7%D1%8B%D0%BA_%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D1%8F). А также LISP и Scheme ("Конктенативные языки можно рассматривать как семейство языков, вроде Лисп-языков. Так между всеми диалектами Лиспа (включая Scheme), есть сильное «семейное сходство». Однако есть большая разница в дизайне, реализации и назначении этих языков. Языки программируемых микрокалькуляторов и многие из версий Форта предназначены для встраивания в небольшие микропроцессорные системы; PostScript также является встраиваемым языком, только микропроцессорные системы, интерпретирующие его называютсяпринтерами. Однако другие конкатенативные языки, такие как Joy или Cat разработаны как языки программирования общего назначения или в исследовательских целях." там же)
И ещё...
В СЕТИ - была ХОРОШАЯ статья - "почему отдельностоящие методы ЛУЧШЕ методов классов".
Я никак не могу найти ссылку на неё. (Если найдёте - ПРИСЫЛАЙТЕ - с меня пиво или коньяк, ну или что вы там хотите.. в разумных пределах...).
Так вот.
В статье ПОКАЗЫВАЛОСЬ - почему "отдельностоящие методы" ЛУЧШЕ методов классов. И как это ПОНИЖАЕТ "связность" и УЛУЧШАЕТ архитектуру. Тут не премину вспомнить IStream (О УЖАС) (http://msdn.microsoft.com/en-us/library/windows/desktop/aa380034(v=vs.85).aspx) и IDataObject (О УЖАС УЖАС) (http://msdn.microsoft.com/en-us/library/windows/desktop/ms688421(v=vs.85).aspx).
Это вещь "ортогональная" примесям, но "на ту же тему"...
Про IDataObject хочу сказать - GetData и GetDataHere. Одно выводится ЧЕРЕЗ другое. И должно было быть сделано "хелперами" или "отдельностоящими методами". Но! MS предпочёл ОБЯЗАТЬ ВСЕХ реализовывать ОБА метода.. Причём каждый из них является "спорным" сам по-себе. Чего только "развесистость" FORMATETC (http://msdn.microsoft.com/en-us/library/windows/desktop/ms682177(v=vs.85).aspx) и STGMEDIUM (http://msdn.microsoft.com/en-us/library/windows/desktop/ms683812(v=vs.85).aspx) стоят.
Это - УЖАС, а не "интерфейс".
Я его РЕАЛИЗОВАЛ и НЕ РАЗ и НЕ ДВА. И в итоге сделал "базовый класс". От которого наследуются все остальные. И наследники СИЛЬНО ПРОЩЕ исходного интерфейса. Они переопределяют один/два метода.
Я об этом позже напишу.. Если хватит сил.
Пока вот вам ссылки:
1. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3DataObject.pas
2. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3BitmapDataObject.pas
3. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3DataObjectEnum.pas
4. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3InterfacedDataObject.imp.pas
5. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3StorableDataObject.pas
6. https://sourceforge.net/p/rumtmarc/code-0/HEAD/tree/trunk/Blogger/RealWork/L3/l3TreeDataObject.imp.pas
Ссылка. Опубликовано ГОД НАЗАД.. И не потеряло актуальности...
http://18delphi.blogspot.ru/2013/03/blog-post.html
И вообще - это мой ЛУЧШИЙ пост... Более лучшего я пока так ничего и не написал...
Хотя и пытался.. И не раз...
И вообще - это мой ЛУЧШИЙ пост... Более лучшего я пока так ничего и не написал...
Хотя и пытался.. И не раз...
среда, 12 марта 2014 г.
Наследование... Полиморфизм..
http://blogs.embarcadero.com/vsevolodleonov/2013/02/07/alex_reply_friendship/
Знаете что.. Вот не согласен я с Леоновым...
Скорее согласен с Алексеевым...
Особенно про "интерфейсы"...
Особенно если "вспомнить" про "примеси и АОП.
НЕТУ "чистого" дерева наследования. В СЛОЖНЫХ системах.
Я вот СЕЙЧАС одну такую "СЛОЖНУЮ" систему перебираю по винтикам и болтикам.
И там - чем дальше - тем больше возникают "боковые" ветки наследования.
Читай - "примеси" и АОП.
Я бы привёл пример. Но боюсь, что для "читающей публики" он слишком сложен.
А уж у "сокрытия" - ЕСТЬ ГЛУБОКИЕ КОРНИ.
Ещё про "аспекты"...
Задам несколько вопросов...
Автомобиль ИНКАПСУЛИРЕТ (агрегирует) колёса или наследуется от телеги?
Велосипед с автомобилем в КАКИХ отношениях?
А самолёт? Он агрегирует шасси или наследуется от телеги? Или от автомобиля? Или от велосипеда?
А винт? Самолёт наследует? Или агрегирует? Если наследует, то от кого?
А вот скажет корабль? Он агрегирует винт или наследует? От кого? От самолёта?
А вот реактивный самолёт? Он НАСЛЕДУЕТСЯ от самолёта "с винтом"?
А как же корабль?
А или реактивный самолёт? Он наследуется от ракеты? Или ракета наследуется от него?
А вот корабль-"ракета" он в каких отношениях с самолётом и ракетой?
А вот колёсный пароход? Он наследуется от корабля? Или корабль от него наследуется? Или колёсный пароход наследуется от телеги? Или от велосипеда? Или от автомобиля?
А реактивный автомобиль (такие тоже бывают) он от кого наследуется? От ракеты? Или от реактивного самолёта? Или от телеги? Или от корабля-"ракеты"?
Не устали ещё от вопросов?
Они ведь ТРИВИАЛЬНЫЕ :-)
И ТАКИХ вопросов - у МЕНЯ ещё МИЛЛИОН...
Скажу одно... ПРИМЕСИ.
Ещё РАЗ - ПРИМЕСИ и АОП.
Колёса, мотор, и т.д. и т.п. это НЕ НАСЛЕДОВАНИЕ и не "прямая" агрегация.. Это - АСПЕКТЫ. Это - АОП.
А насчёт "сокрытия".... Напишу ещё ВОТ ЧТО...
Есть РАЗНЫЕ категории ПОЛЬЗОВАТЕЛЕЙ Классов (механизмов)... Есть ТУПОЙ ПОЛЬЗОВАТЕЛЬ.. Есть профессиональный водитель.. Есть механик.. Есть ремонтник.. Есть человек, который ПРОИЗВОДИТ механизм... Или ещё работник на мойке.. Или заправщик на заправке...
Кому-то нужен доступ к колёсам.. Кому-то к мотору.. Кому-то к багажнику.. Кому-то к бачку омывателя.. Кому-то к бензобаку.. Кому-то ко всему из вышеперечисленного.. Кому-то к какому-то подмножеству...
Так что вопрос - вроде "простой", но СОВСЕМ НЕ ОЧЕВИДНЫЙ...
Friend скажете вы.. Отчасти.. Отвечу я... К Friend - есть МНОЖЕСТВО вопросов..
ПЕРВЫЙ - это то, что Friend указывается в БАЗОВОМ классе, а не во Friend'е... Если эту зависимость нарисовать на UML, То СРАЗУ ВИДНО, что "направление зависимости" - НЕПРАВИЛЬНОЕ... Friend НАДО указывать в САМОМ Friend'е, а не в базовом классе...
И это - ТОЛЬКО ОДИН ВОПРОС...
А их - МАССА...
Тема тут явно НЕДОРАБОТАНА...
Правда Вирт пытается её развивать в Модуле и Обероне... Если я правильно понимаю...
И вот тут "в вопросе сокрытия" - возникает "мостик" к ИНТЕРФЕЙСАМ (о чём и говорит Алексеев (если я его правильно понял)).
Есть TSomeComlexMechanism - собственно "механизм".. И "НАД НИМ" есть НЕСКОЛЬКО РАЗЛИЧНЫХ "интерфейсов", регламентирующих "уровни доступа" - ISomeSimpleMechanism, ISomeComplexMechanisn, IWheels, IEngine, IDoor, IDoorAndWheels, IGasolineTank, IMetrics, IDevices etc.
(Кстати эта тема "отчасти развита" в FM с их "сервисами")
Мысль понятна? (Я правда САМ делаю - ПО-ДРУГОМУ).
Если у "пользователя" нашим механизмом "хватило мозгов" получить соответствующий интерфейс например IEngine - то это ЗНАЧИТ (допускаю что так), что он ЗНАЕТ, что с ним ДЕЛАТЬ и КАК это ДЕЛАТЬ.
Примитивно - если у человека "хватил ума" снять крышку двигателя, то это значит, что он ЗНАЕТ, что с НИМ ДЕЛАТЬ.. Ну или он ПОЛНЫЙ ИДИОТ.. Такого - НЕ ИСКЛЮЧАЮ...
Посему - ещё раз... НЕТУ "общего дерева наследования" и "строгой иерархии" машин и механизмов.
ЕСТЬ "множество аспектов применения и реализации".
Знаете что.. Вот не согласен я с Леоновым...
Скорее согласен с Алексеевым...
Особенно про "интерфейсы"...
Особенно если "вспомнить" про "примеси и АОП.
НЕТУ "чистого" дерева наследования. В СЛОЖНЫХ системах.
Я вот СЕЙЧАС одну такую "СЛОЖНУЮ" систему перебираю по винтикам и болтикам.
И там - чем дальше - тем больше возникают "боковые" ветки наследования.
Читай - "примеси" и АОП.
Я бы привёл пример. Но боюсь, что для "читающей публики" он слишком сложен.
А уж у "сокрытия" - ЕСТЬ ГЛУБОКИЕ КОРНИ.
Ещё про "аспекты"...
Задам несколько вопросов...
Автомобиль ИНКАПСУЛИРЕТ (агрегирует) колёса или наследуется от телеги?
Велосипед с автомобилем в КАКИХ отношениях?
А самолёт? Он агрегирует шасси или наследуется от телеги? Или от автомобиля? Или от велосипеда?
А винт? Самолёт наследует? Или агрегирует? Если наследует, то от кого?
А вот скажет корабль? Он агрегирует винт или наследует? От кого? От самолёта?
А вот реактивный самолёт? Он НАСЛЕДУЕТСЯ от самолёта "с винтом"?
А как же корабль?
А или реактивный самолёт? Он наследуется от ракеты? Или ракета наследуется от него?
А вот корабль-"ракета" он в каких отношениях с самолётом и ракетой?
А вот колёсный пароход? Он наследуется от корабля? Или корабль от него наследуется? Или колёсный пароход наследуется от телеги? Или от велосипеда? Или от автомобиля?
А реактивный автомобиль (такие тоже бывают) он от кого наследуется? От ракеты? Или от реактивного самолёта? Или от телеги? Или от корабля-"ракеты"?
Не устали ещё от вопросов?
Они ведь ТРИВИАЛЬНЫЕ :-)
И ТАКИХ вопросов - у МЕНЯ ещё МИЛЛИОН...
Скажу одно... ПРИМЕСИ.
Ещё РАЗ - ПРИМЕСИ и АОП.
Колёса, мотор, и т.д. и т.п. это НЕ НАСЛЕДОВАНИЕ и не "прямая" агрегация.. Это - АСПЕКТЫ. Это - АОП.
А насчёт "сокрытия".... Напишу ещё ВОТ ЧТО...
Есть РАЗНЫЕ категории ПОЛЬЗОВАТЕЛЕЙ Классов (механизмов)... Есть ТУПОЙ ПОЛЬЗОВАТЕЛЬ.. Есть профессиональный водитель.. Есть механик.. Есть ремонтник.. Есть человек, который ПРОИЗВОДИТ механизм... Или ещё работник на мойке.. Или заправщик на заправке...
Кому-то нужен доступ к колёсам.. Кому-то к мотору.. Кому-то к багажнику.. Кому-то к бачку омывателя.. Кому-то к бензобаку.. Кому-то ко всему из вышеперечисленного.. Кому-то к какому-то подмножеству...
Так что вопрос - вроде "простой", но СОВСЕМ НЕ ОЧЕВИДНЫЙ...
Friend скажете вы.. Отчасти.. Отвечу я... К Friend - есть МНОЖЕСТВО вопросов..
ПЕРВЫЙ - это то, что Friend указывается в БАЗОВОМ классе, а не во Friend'е... Если эту зависимость нарисовать на UML, То СРАЗУ ВИДНО, что "направление зависимости" - НЕПРАВИЛЬНОЕ... Friend НАДО указывать в САМОМ Friend'е, а не в базовом классе...
И это - ТОЛЬКО ОДИН ВОПРОС...
А их - МАССА...
Тема тут явно НЕДОРАБОТАНА...
Правда Вирт пытается её развивать в Модуле и Обероне... Если я правильно понимаю...
И вот тут "в вопросе сокрытия" - возникает "мостик" к ИНТЕРФЕЙСАМ (о чём и говорит Алексеев (если я его правильно понял)).
Есть TSomeComlexMechanism - собственно "механизм".. И "НАД НИМ" есть НЕСКОЛЬКО РАЗЛИЧНЫХ "интерфейсов", регламентирующих "уровни доступа" - ISomeSimpleMechanism, ISomeComplexMechanisn, IWheels, IEngine, IDoor, IDoorAndWheels, IGasolineTank, IMetrics, IDevices etc.
(Кстати эта тема "отчасти развита" в FM с их "сервисами")
Мысль понятна? (Я правда САМ делаю - ПО-ДРУГОМУ).
Если у "пользователя" нашим механизмом "хватило мозгов" получить соответствующий интерфейс например IEngine - то это ЗНАЧИТ (допускаю что так), что он ЗНАЕТ, что с ним ДЕЛАТЬ и КАК это ДЕЛАТЬ.
Примитивно - если у человека "хватил ума" снять крышку двигателя, то это значит, что он ЗНАЕТ, что с НИМ ДЕЛАТЬ.. Ну или он ПОЛНЫЙ ИДИОТ.. Такого - НЕ ИСКЛЮЧАЮ...
Посему - ещё раз... НЕТУ "общего дерева наследования" и "строгой иерархии" машин и механизмов.
ЕСТЬ "множество аспектов применения и реализации".
суббота, 8 марта 2014 г.
пятница, 7 марта 2014 г.
Offtopic. Про Украину, Крым и всё остальное...
Я ЗА ПОМОЩЬ.. Я ЗА ВЛИЯНИЕ.. Я ЗА ЗАЩИТУ.. Я ПРОТИВ ФАШИСТОВ... Я ЗА "ПРАЗДНИК ПОБЕДЫ".. Я ЗА русский язык... Я ДАЖЕ ЗА нелегальные поставки оружия... И ЗА обучение лояльных...
Но!
Никто не задавался вопросом - "а что если ВДРУГ Якутия объявит референдум и решит присоединиться (например) к Монголии"?
И да.. Не устаю повторять, что фашизм, коррупция, война и сепаратизм это вещи - ортогональные.
Но!
Никто не задавался вопросом - "а что если ВДРУГ Якутия объявит референдум и решит присоединиться (например) к Монголии"?
И да.. Не устаю повторять, что фашизм, коррупция, война и сепаратизм это вещи - ортогональные.
Ещё о тестах
bq. Концепция запуска автотестов подразумевает, что они будут запущены
на чистых настройках.
Вот совсем нет.
Тесты это не только инструмент проверки и валидации. Это ещё и инструмент разработки.
Если тест от запуска к запуску показывает разные результаты - это как минимум странно.
А как максимум - неудобно. Для разработчика.
Вот разработчик правит ошибку. Запустил тест. Он как-то прошёл. Разработчик что-то поправил у себя в коде. Запускает тест по новой. Он опять как-то прошёл. С другими результатами.
У разработчика возникает вопрос - эти результаты другие потому, что код поменялся или потому, что тест нестабильный.
если тест требует ДЕТЕРМИНИРОВАННЫХ условий, то это - ИНВАРИАНТ - ПРЕДУСЛОВИЕ
а потом только делать всё остальное
Вот совсем нет.
Тесты это не только инструмент проверки и валидации. Это ещё и инструмент разработки.
Если тест от запуска к запуску показывает разные результаты - это как минимум странно.
А как максимум - неудобно. Для разработчика.
Вот разработчик правит ошибку. Запустил тест. Он как-то прошёл. Разработчик что-то поправил у себя в коде. Запускает тест по новой. Он опять как-то прошёл. С другими результатами.
У разработчика возникает вопрос - эти результаты другие потому, что код поменялся или потому, что тест нестабильный.
если тест требует ДЕТЕРМИНИРОВАННЫХ условий, то это - ИНВАРИАНТ - ПРЕДУСЛОВИЕ
и тест ПЕРВЫМ делом должен ПОСТУЛИРОВАТЬ этот ИНВАРИАНТ
а потом только делать всё остальное
среда, 5 марта 2014 г.
План будущих статей
Знаете...
Ужасно удручён и расстроен я событиями и ситуацией на Украине.
Расстроен и за "наших", и за "не наших".
Посему - депрессия. Что-то плохо всё пишется.
Но планы на самом деле - большие. Если это кому-то нужно в этом УЖАСНОМ мире.
Вот что в планах:
1. Тестируем калькулятор №5. Тесты через "новую архитектуру".
2. Тестируем калькулятор №6. Использование эталонов. Рандомные тесты.
3. Тестируем калькулятор №7. Как правильно сравнивать double. Мак-Конел, и Мак-Кракен и Дорн.
4. Тестируем калькулятор №8. Параметризованные тесты.
5. Почему IStream и IDataObject это ужасно с "архитектурной точки зрения" и как с этим бороться.
6. Автоматические ночные сборки.
7. О практике использования Mutable и Immutable строк. Да и прочих объектов. И почему в Delphi не хватает модификатора const НА МЕТОДАХ объектов.
8. О разнице в интерфейсной и поведенческой эквивалентности в классах, примесях и интерфейсах. И за что я люблю ТИПИЗИРОВАННЫЙ Duck-Typing.
9. Абстрактные классы и как не давать их создавать.
10. Assert'ы и ТЗ.
11. Почему "отдельностоящие методы" ЛУЧШЕ методов КЛАССОВ/интерфейсов и как ЭТО ПОНИЖАЕТ "связность". Повод для данной статьи вот - http://programmingmindstream.blogspot.ru/2014/03/blog-post_12.html
12. Тестируем калькулятор №9. Готовимся к расширению функциональности. Через Dependency Injection. Выделяем класс "TCalculatorOperation".
13. Тестируем калькулятор №10. Расширяем функциональность. От класса TCalculator переходим ко МНОЖЕСТВУ классов TCalculatorOperation.
14. Тестируем калькулятор №11. Размножаем тесты относительно какого-то заданного "итератора". Например по операциям калькулятора.
15. Тестируем калькулятор №12. Тесты и примеси. Скажем так опять.
16. Тестируем калькулятор №13. От класса TCalculatorOperation переходим к "аксиоматике", скриптовой машине и скриптам.
17. Тестируем калькулятор №14. На основе Dependency Injection и "аксиоматике" делаем ДВЕ "морды" калькулятора - на VCL и на FM. Опционально - можно ещё и строковый интерфейс забабахать.
18. Про "инструменты" (тегов) или паттерн Strategy (или Template Method, или Observer). Как они позволяют "внедрять функциональность "сбоку"".
19. По мотивам предыдущей темы - паттерн Context и как не привязываться к "состояниям" "инструментов". Как делать инструменты объектами БЕЗ СОСТОЯНИЙ (Immutable).
20. По мотивам предыдущей темы - как делать "инструменты" не только объектами и/или интерфейсами, но и class of или Event или даже reference to. И как это позволяет "экономить на спичках", да и не только на них.
21. Ну и ещё по мотивам предыдущих тем привести пример, про TextPara, ParaList, Owner'ов и "декорации" для "баллонов". Почему лучше подавать Owner'а "сверху" (в частности для Painter'ов и HotSpot'ов), а не пытаться получить его "изнутри".
Ужасно удручён и расстроен я событиями и ситуацией на Украине.
Расстроен и за "наших", и за "не наших".
Посему - депрессия. Что-то плохо всё пишется.
Но планы на самом деле - большие. Если это кому-то нужно в этом УЖАСНОМ мире.
Вот что в планах:
1. Тестируем калькулятор №5. Тесты через "новую архитектуру".
2. Тестируем калькулятор №6. Использование эталонов. Рандомные тесты.
3. Тестируем калькулятор №7. Как правильно сравнивать double. Мак-Конел, и Мак-Кракен и Дорн.
4. Тестируем калькулятор №8. Параметризованные тесты.
5. Почему IStream и IDataObject это ужасно с "архитектурной точки зрения" и как с этим бороться.
6. Автоматические ночные сборки.
7. О практике использования Mutable и Immutable строк. Да и прочих объектов. И почему в Delphi не хватает модификатора const НА МЕТОДАХ объектов.
8. О разнице в интерфейсной и поведенческой эквивалентности в классах, примесях и интерфейсах. И за что я люблю ТИПИЗИРОВАННЫЙ Duck-Typing.
9. Абстрактные классы и как не давать их создавать.
10. Assert'ы и ТЗ.
11. Почему "отдельностоящие методы" ЛУЧШЕ методов КЛАССОВ/интерфейсов и как ЭТО ПОНИЖАЕТ "связность". Повод для данной статьи вот - http://programmingmindstream.blogspot.ru/2014/03/blog-post_12.html
12. Тестируем калькулятор №9. Готовимся к расширению функциональности. Через Dependency Injection. Выделяем класс "TCalculatorOperation".
13. Тестируем калькулятор №10. Расширяем функциональность. От класса TCalculator переходим ко МНОЖЕСТВУ классов TCalculatorOperation.
14. Тестируем калькулятор №11. Размножаем тесты относительно какого-то заданного "итератора". Например по операциям калькулятора.
15. Тестируем калькулятор №12. Тесты и примеси. Скажем так опять.
16. Тестируем калькулятор №13. От класса TCalculatorOperation переходим к "аксиоматике", скриптовой машине и скриптам.
17. Тестируем калькулятор №14. На основе Dependency Injection и "аксиоматике" делаем ДВЕ "морды" калькулятора - на VCL и на FM. Опционально - можно ещё и строковый интерфейс забабахать.
18. Про "инструменты" (тегов) или паттерн Strategy (или Template Method, или Observer). Как они позволяют "внедрять функциональность "сбоку"".
19. По мотивам предыдущей темы - паттерн Context и как не привязываться к "состояниям" "инструментов". Как делать инструменты объектами БЕЗ СОСТОЯНИЙ (Immutable).
20. По мотивам предыдущей темы - как делать "инструменты" не только объектами и/или интерфейсами, но и class of или Event или даже reference to. И как это позволяет "экономить на спичках", да и не только на них.
21. Ну и ещё по мотивам предыдущих тем привести пример, про TextPara, ParaList, Owner'ов и "декорации" для "баллонов". Почему лучше подавать Owner'а "сверху" (в частности для Painter'ов и HotSpot'ов), а не пытаться получить его "изнутри".
суббота, 1 марта 2014 г.
Злой пост "про программистов"
Вот нам рассказывают, что "русские программисты САМЫЕ ЛУЧШИЕ".
Что "в Америке востребованы".
А что есть программист?
Это "гений"?
По-моему - нет.
"Программист" - это "РЕМЕСЛЕННИК", который лет "20-ть отработал на своём месте".
Который ИЗУЧИЛ GoF. Но не "просто прочитал книжку", а "научился жопой чуять".
Который ПОНЯЛ необходимость ТЕСТИРОВАНИЯ.
Который понял НЕОБХОДИМОСТЬ совпадения ТЕСТОВ и ТЗ.
Который понял НЕОБХОДИМОСТЬ написания ТЗ.
Который "научился работать в команде".
Который "не бежит вперёд", а слушает "что ему говорят".
Который понимает "что так заведено".
Который "пишет понятный и самодокументируемый код".
Программирование это "не озарение свыше". А РЕМЕСЛО.
ДОЛГО и НУДНО ВЫРАБАТЫВАЕМОЕ.
Ещё раз - РЕМЕСЛО.
Творчество - это "МАТЕМАТИКА", а ПРОГРАММИРОВАНИЕ это - РЕМЕСЛО.
Нудное, сложное, ВАЖНОЕ, но! РЕМЕСЛО.
Где тут место "гениям"?
Гении - Кнут, Вирт, Срауструп, Керниган и Ричи.
Но разве они "программисты"? По-моему - нет... Они - ГЕНИИ, но не программисты.
"Программист" это Я и "мой сосед". Который не делает "что-то гениальное", а что-то "вполне конкретное".
"Согласующееся с ТЗ".
Я хотел написать "что-то умное", а получился "крик души"... Ну что есть, то есть...
Что "в Америке востребованы".
А что есть программист?
Это "гений"?
По-моему - нет.
"Программист" - это "РЕМЕСЛЕННИК", который лет "20-ть отработал на своём месте".
Который ИЗУЧИЛ GoF. Но не "просто прочитал книжку", а "научился жопой чуять".
Который ПОНЯЛ необходимость ТЕСТИРОВАНИЯ.
Который понял НЕОБХОДИМОСТЬ совпадения ТЕСТОВ и ТЗ.
Который понял НЕОБХОДИМОСТЬ написания ТЗ.
Который "научился работать в команде".
Который "не бежит вперёд", а слушает "что ему говорят".
Который понимает "что так заведено".
Который "пишет понятный и самодокументируемый код".
Программирование это "не озарение свыше". А РЕМЕСЛО.
ДОЛГО и НУДНО ВЫРАБАТЫВАЕМОЕ.
Ещё раз - РЕМЕСЛО.
Творчество - это "МАТЕМАТИКА", а ПРОГРАММИРОВАНИЕ это - РЕМЕСЛО.
Нудное, сложное, ВАЖНОЕ, но! РЕМЕСЛО.
Где тут место "гениям"?
Гении - Кнут, Вирт, Срауструп, Керниган и Ричи.
Но разве они "программисты"? По-моему - нет... Они - ГЕНИИ, но не программисты.
"Программист" это Я и "мой сосед". Который не делает "что-то гениальное", а что-то "вполне конкретное".
"Согласующееся с ТЗ".
Я хотел написать "что-то умное", а получился "крик души"... Ну что есть, то есть...