Здравствуйте, MTD, Вы писали:
L>>Ну вот надо классу одновременно быть и обсервером и посетителем. Выбирай имя. Только чтобы удачно.
MTD>Зачем? Я инженер, опиши проблему, попробую помочь.
Есть класс, который должен следить за обновлениями кеша. Для этого он подписывается на соответствующее событие, т.е. является обсервером.
Задача класса — когда скажут, обновить значения в некоей таблице, где он посетит каждую ячейку.
Придумывай название.
L>>Когда же уже сделают кнопочку "фейспалм"?
MTD>Конструктивно.
Здравствуйте, landerhigh, Вы писали:
L>Есть класс, который должен следить за обновлениями кеша. Для этого он подписывается на соответствующее событие, т.е. является обсервером. L>Задача класса — когда скажут, обновить значения в некоей таблице, где он посетит каждую ячейку.
L>Придумывай название.
Зачем дополнительная сущность, зачем нарушение инкапсуляции? Почему бы не подписать таблицу на событие и она сама об этом не сообщит своим ячейкам в простом цикле?
L>>Придумывай название.
MTD>Зачем дополнительная сущность, зачем нарушение инкапсуляции? Почему бы не подписать таблицу на событие и она сама об этом не сообщит своим ячейкам в простом цикле?
Считай, что так нужно. Может, в целях оптимизации производительности, может, потому что сама таблица не может обработать это событие. т.к. требуются еще другие данные.
Здравствуйте, landerhigh, Вы писали:
L>Считай, что так нужно.
Увы, не аргумент.
L>Может, в целях оптимизации производительности
Не вижу в приведенном примере простора для оптимизации, если только этот класс не производит фильтрацию лишних событий об обновлении, тогда название становиться очевидным и да, в этом случаее ему все равно не нужно знание внутреннего устройства таблицы.
L>может, потому что сама таблица не может обработать это событие. т.к. требуются еще другие данные.
Аргумент. Фантазия-то присутствет вообще? Например, класс таблицы неизменяем и не может сам подписаться. Живет в отдельном ActiveX. Или требуется недетская фильтрация, как ты уже догадался. Или требуется собирать данные из нескольких источников. Да мало ли что еще.
L>>Может, в целях оптимизации производительности
MTD>Не вижу в приведенном примере простора для оптимизации, если только этот класс не производит фильтрацию лишних событий об обновлении, тогда название становиться очевидным и да, в этом случаее ему все равно не нужно знание внутреннего устройства таблицы.
L>>может, потому что сама таблица не может обработать это событие. т.к. требуются еще другие данные.
MTD>Значит надо передавать данные вместе с событием.
Здравствуйте, landerhigh, Вы писали:
L>Аргумент. Фантазия-то присутствет вообще?
Я не фантазер, оперирую строго фактами.
L>Например, класс таблицы неизменяем и не может сам подписаться. Живет в отдельном ActiveX.
Adapter
L>Или требуется недетская фильтрация, как ты уже догадался.
Filter
L>Или требуется собирать данные из нескольких источников.
Agregator
L>Да мало ли что еще.
Это разные классы с разной ответственностью. Немного отвлекись от документирования сферических коней и порефактори, в результате у тебя получится несколько классов с названиями отражающими то, чем они занимаются и ты сможешь из них выстроить цепочку, код станет понятней, более удобным в поддержке и менее подверженным багам. ProactorVisitorObserverStateCacheManipulator — это просто ужас, не надо так делать.
MTD>>Значит надо передавать данные вместе с событием.
L>Это не всегда возможно/оправдано.
Надо смотреть, но ProactorVisitorObserverStateCacheManipulator однозначно ни в какие ворота.
L>Название-то придумал?
Здравствуйте, Basil2, Вы писали:
B>Обычно именно сишники выдают такой С++ код. Или драйверисты.
Это не сишник.
Судя по коду, его автор долго писал числодробилки на Фортране.
Думаю, что если бы обсуждаемый код был написан на Фортране 77 или даже Фортране 4, вопросов было бы гораздо меньше.
ХГД>> Я, например, всегда комментирую "проваливающиеся" (без break) ветки в switch, или места, где важен порядок объявления членов класса.
bnk>Ага, классный принцип — закладывать мины и обставлять их флажками
Ну а какие варианты, если в классе вдруг нужны 3-5 зависимых друг от друга членов? Двухстадийная инициализация еще хуже, запихивать их в unique_ptr — ваще отстой. Так что это не мины, а вполне легитимные фичи языка.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, MTD, Вы писали:
MTD>Это разные классы с разной ответственностью. Немного отвлекись от документирования сферических коней и порефактори, в результате у тебя получится несколько классов с названиями отражающими то, чем они занимаются и ты сможешь из них выстроить цепочку, код станет понятней, более удобным в поддержке и менее подверженным багам. ProactorVisitorObserverStateCacheManipulator — это просто ужас, не надо так делать.
Теоретег. А что, если этот класс, котороый одновременно и визитор, и обсервер и еще кое-что, и есть результат рефакторинга? Просто потому, что так оказалось удобнее и логичнее?
L>>Название-то придумал?
MTD>Зачем? Мой вердикт — рефакторить.
То есть не смог придумать нормальное название — рефакторить?
Здравствуйте, MTD, Вы писали:
ХГД>>Есть куча ситуаций, где недостаточно внимательный разработчик может нарваться на неприятности. Я, например, всегда комментирую "проваливающиеся" (без break) ветки в switch, или места, где важен порядок объявления членов класса.
MTD>Перепиши код проще, чтобы недостаточно внимательный разработчик не нарвался — гарантии, что он прочтет твой комментарий нет.
Эээ, ты правда считаешь, что код, полагающийся на гарантированный стандартом языка порядок инициализации членов класса, обязательно сложный?
ХГД>>Со сторонними библиотеками тоже всяких приколов хватает. Вообще, нарвался на неожиданность — прокомментируй.
MTD>Бывает, но мы же о хорошем коде фантазируем.
О хорошем, а не о нереально совершенном. Вот, например, библиотека boost::asio, по-твоему, достаточно хороша? Да и что нам asio, как на счет стандартных стримов? Заслуживают ли комментария их мелкие отличия на различных платформах?
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
Здравствуйте, Хон Гиль Дон, Вы писали:
MTD>>Перепиши код проще, чтобы недостаточно внимательный разработчик не нарвался — гарантии, что он прочтет твой комментарий нет.
ХГД>Эээ, ты правда считаешь, что код, полагающийся на гарантированный стандартом языка порядок инициализации членов класса, обязательно сложный?
Если инициализация зависит от порядка членов в классе — это плохо, сломать это может кто угодно, да даже ты сам, через некоторое время. Явное всегда лучше неявного, используй фабрику.
ХГД>О хорошем, а не о нереально совершенном. Вот, например, библиотека boost::asio, по-твоему, достаточно хороша?
Не знаю, не сталкивался.
ХГД>Да и что нам asio, как на счет стандартных стримов? Заслуживают ли комментария их мелкие отличия на различных платформах?
Как бы и сами разработчики не скрывают, что дизайн стримов неудачный.
Ребята, поймите — быть практиком, не значит писать говнокод. Быть практиком — это решать проблему приемлемые сроки минимизируя затраты с адекватным качеством. В этом очень помогают проверенные практики, часть из которых я затронул — проверка контрактов, осмысленное именование, один класс — одна ответственность, инкапсуляция.
L>А что, если
Слишком много если, для практика, ну видно же что пытаешься изобрести проблему.
L>этот класс, котороый одновременно и визитор, и обсервер и еще кое-что, и есть результат рефакторинга?
Рефактори дальше — результат неудовлетворительный.
MTD>>Зачем? Мой вердикт — рефакторить.
L>То есть не смог придумать нормальное название — рефакторить?
Как профессионал я не могу маскировать проблему, я ее решаю.
Здравствуйте, MTD, Вы писали:
AWW>>мало коментариев.
MTD>В хорошем коде комментариев быть не должно.
Вот это срачь то развели на пустом месте. Ога!
Коментарии это не только коментарии, это —
— советы наследнику например
— себе самому типа "что-то тут иногда не то пролетает"
— или заметки что надо поправить если будет медленно работать.
Да триллион ситуаций.
Коментарии которые коментируют очевидное, никому не нужны, а вот коментарии которые рассказывают почему выделяется память кусками не по размеру элемента а по какие-то магические 1024 байта. То есть отсуствие комментариев говорит, об отношении работника к своей работе. То есть попросу — ему насрать. ))
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, landerhigh, Вы писали:
L>>Теоретег.
MTD>Ребята, поймите — быть практиком, не значит писать говнокод. Быть практиком — это решать проблему приемлемые сроки минимизируя затраты с адекватным качеством. В этом очень помогают проверенные практики, часть из которых я затронул — проверка контрактов, осмысленное именование, один класс — одна ответственность, инкапсуляция.
Очень хорошие фразы.
L>>А что, если
MTD>Слишком много если, для практика, ну видно же что пытаешься изобрести проблему.
L>>этот класс, котороый одновременно и визитор, и обсервер и еще кое-что, и есть результат рефакторинга?
MTD>Рефактори дальше — результат неудовлетворительный.
Сказал кто? Ты видел код?
А вообще, я слегка покривил душой тут. Было время С++03, где не было ни лямбд, ни прочих вкусностей, а пользоваться std::bind_1st можно было только после пол-литры. И тогда, если твой класс хотел быть обсервером, самым простым способом было унаследовать интерфейс IObserver. Весело было, когда требовалось реализовывать два подобных интерфейса.
Вот тогда, бывало, смотришь на объявление класса и видишь, что он — кавалер ордена Визиторов дважды Обсервер Состояний. Даже если его имя этого не отражает.
Сейчас всю эту непубличную подноготную гораздо проще прятать под капот.
Здравствуйте, aik, Вы писали:
aik>struct super_struct *xxx = malloc(sizeof(*xxx) * MAX_SUPER_OBJECTS_NUM);
aik>и никаких комментариев. И почему именно malloc — надо писать если это c++ или glibc (а лучше заменять на new/g_malloc), а если голый си + libc — то зачем это комментировать?
Здравствуйте, landerhigh, Вы писали:
L>А подумать, что означает "потеря истории изменений", как она происходит и как и когда обнаруживается, и каким боком тут бекапы, подумать не пробовали, прежде чем написать?
Я представляю, какой срач поднимут некоторые увидев что-то такое :
#if 0
.... куча кода )))
#endif
Так обычно закрываются куски кода, которые выкинуты но пока еще нет 100% уверенности что это сделано правильно! ))
