• Нетрадиционная ориентация ООП
    –1
    Ваша мысль о том, что объекты реального мира не есть объекты ООП мне видится ключевой. Одной из. Ее уже высказывали несколько человек выше. И это одна из проблем — Object Oriented пришло к нам из англоязычных работ, где само слово object на тот момент не было, как у русскоговорящих, синонимом слова «предмет». Мы бездумно приняли это название (как и много других названий — чего стоит только «теория вероятностей», хотя по сути она изучает меры неопределенности; таких примеров много в самых разных сферах науки). Поэтому я и закончил фразой — давайте переименовывать.
  • Нетрадиционная ориентация ООП
    0
    Нет, не совсем. Я тоже вижу за этим сухую инженерную практику, заточенную под решение вполне определенного круга проблем. Наравне с этим я часто задумываюсь о том, могли бы наши инструменты подталкивать нас в сторону написания более «живого» кода? Я не вижу ничего дурного в том, чтобы пытаться копировать и воспроизводить процессы, протекающие в реальном мире. Наоборот, именно это даст нам неслыханную эффективность: яркий пример нашего времени — нейронные сети.

    Что же касается SOLID, то это поверхностное обманчивое впечатление. На самом деле проблема не в том, кто открывает дверь или откуда вызывается ее метод само-открывания. Проблема в том, что по ходу все это обрастает целой кучей абстракций, порожденных необходимостью заставить все это работать. И тут наверняка можно выявить вот такую СОСТАВЛЯЮЩУЮ: наши инструменты никак не предохраняют нас от смешивания поведения и состояния. Проект развивается, усложняется — и приходится прибегать вот к таким ужасам как паттерны. При всей их неоспоримой эффективности.
  • Нетрадиционная ориентация ООП
    –2
    Я вот медленно начинаю убеждаться, что в рамках современного ООП эта проблема неразрешима. Если говорить о моем чувстве ситуации, то мне ближе всего какой-нибудь делегат, который принимает дверь в закрытом состоянии, принимает ключ, которым вы пытаетесь открыть дверь — и либо открывает ее, либо вышвыривает эксепшин, мол, эти ключем дверь не открывается. Но кто будет поставщиком таких делегатов? Опять получается какой-нибудь Provider!
  • Нетрадиционная ориентация ООП
    –2
    Да. И об этом ключ должен знать, да? Ключ решает — я вставленный в замок, значит меня можно повернуть. Или решает котнекстВставленностиВДверь?
  • Нетрадиционная ориентация ООП
    –1
    Ваш ответ мне очень нравится и я в принципе с ним согласен. Наверно, я вынесу его в свой очерк. Но у меня есть одна поправка. Важная. Сейчас мир таки движется в сторону «взять самое лучше от функциональных языков» и скомбинировать с тем, что уже есть в ООП. И получить нечто гораздо более гибкое и выразительное. Именно такого ответа, как ваш, я и ждал.
  • Нетрадиционная ориентация ООП
    –1
    Если я завтра начну генерить такой код всерьез для своих проектов, то нам, товарищи, полная хана. Посмотрите сколько получилось ненужной ерунды. Особенно объект «RoundsNumber». Это ну просто замечательный объект, очень жизненно выглядит. И объект «InsertedKey» мне тоже нравится. В чем его принципиальное (т.е. с точки зрения набора свойств-полей) отличие?
  • Нетрадиционная ориентация ООП
    –2
    Ага. А сервисы это не классы, нет? Не объекты? Получается, объект ключ взаимодействует с объектом «СервисКлюча»? Вот тут начинается уже настоящее мракобесие, хотя я прекрасно понимаю, что это очень эффективные и доказавшие свою работоспособность подходы. Это чем-то похоже на то, как раньше бросали уголь в топку котла на пароходах.
  • Нетрадиционная ориентация ООП
    0
    Это все прекрасно. И я с этим согласен. В теории так и должно быть. И разноцеветные единороги должны быть тоже. И клеверные поля. Вот только в результате вы все равно приходите к контекстамКвартир. Просто потому что это быстрее — и с поддержкой тоже проблем не будет, если все это делать «по-человечески»: без абстрактного яПровайдерКотекстовКвартир, которые внутри себя зависит от еще трех интерфейсов и 4 его наследников праздника Release не будет.
  • Нетрадиционная ориентация ООП
    –6
    Вообще-то, это очень сильно зависит от типа задачи. Я вам приведу массу примеров, когда ваша дверь не будет описываться тем же набором свойств, что и обычная дверь. Следовательно, это будет ДРУГАЯ МОДЕЛЬ. С другим поведением. Это мой ответ по поводу трактовки моделей. Я понимаю как соблазнительно унаследоваться от абстрактной двери и дойти так аж до ГлактическойДевриДартаВейдера, но в реальном коде вы неизбежно испохабите ваши методы, особенно входящие параметру и логику их вызова. И в итоге придете к контекстам квартир и контекстам ключей, и фабрикам, которые будут делаться фабриками. Я вас уверяю.
  • Нетрадиционная ориентация ООП
    –3
    Так я вот у вас и спрашиваю — архитектура ООП как-то способствует вам в этом или мешает? Вот написанию функционального кода она в общем-то препятствует, как бы подталкивает в другую сторону. Писать функционально в ООП сложно, а писать в стиле недо- или пере-объектов — легко. А теперь я ставлю вопрос: каким должно быть ООП, чтобы в нем точно также сложно было смешивать свойства/состояние с поведением.
  • Нетрадиционная ориентация ООП
    –5
    ну и вас не смущает, что на самом деле дверь не открывается? ее открывают. я понимаю, что пример до смешного примитивный, но это к вашему вопросу о противоестественном поведении. в реальных проектах обычно идут дальше: дверь.ОткройсяКлючем(ФабрикаКлючей.Создать(typeof(БронированнаяДверь), возбуждатьСобытиеДверьОткрылась: true). Что-то в таком духе.
  • Нетрадиционная ориентация ООП
    –3
    Т.е. вы тоже считаете что должно быть ключ.Открыть(мояКварита.входнаяДверь.Замок)?
  • Нетрадиционная ориентация ООП
    –2
    Да я сейчас и не стремлюсь ничего раскрывать. Мне нужна живая дискуссия и мнение тех, кто занимается именно программированием не ради красоты, а у кого дедлайны, сроки, тысячи строк чужого кода и тд.
  • Нетрадиционная ориентация ООП
    –5
    Т.е. вы всерьез считаете, что при постоянном давлении в виде дедлайнов и бла-бла можно везде писать вот такой код? Лично по моему опыту — приходится либо в ущерб стройности выдавать контексты квартир, либо не работать там, где более-менее налаженный поток проектов.
  • Нетрадиционная ориентация ООП
    –5
    Ок, можете привести ту трактовку, при которой все становится на свои места?
  • Нетрадиционная ориентация ООП
    –9
    В чьем мозгу?
  • BindableConverter для WPF
    0
    В каком смысле — не проще? Не проще в смысле экономии времени? Да, в этом (и только в этом!) смысле — действительно проще. Но ИМХО это засоряет код, что уже само по себе смертный грех. И почему это конвертер не может быть объектом зависимости? Кто именно запрещает? По-моему, это очень логично: конвертору для нормальной работы в условиях реальных задач необходимы вспомогательные параметры; по сути, результат конвертации ЗАВИСИТ от этих параметров, что можно перевести в «конвертор (конкретный экземпляр соотв. класса) зависит от этих параметров». Что еще нужно?
  • BindableConverter для WPF
    0
    Ну да, не депендеси. Я по-моему про это и написал.

    Я все-таки не считаю это велосипедом. Не знаю, следите ли вы за интервью и выступлениями команды, которая занимается wpf, на 9channel, но и они признают, что wpf нужно развивать также в сторону все более и более легкого, удобного, интуитивно понятного использования конечным пользователем вроде нас с вами. Лично мне ужасно не нравится печатать многа букаф, поэтому вариант с
    <MultiBinding> <Bindint 1> <Binding 2> ...
    
    отпадает. Да и места занимает гораздо больше (как на мой вкус — одна из самых неприятных проблем с XAML'ом — количество текста).

    Кстати, если конвертор унаследовать напрямую от Freezable, то прокси не нужен. И тогда объявление конвертора — в точности такое же, как обычного — где-нибудь в ресурсах, только с использованием лаконичного markup-ex {Binding Name}. Собственно, для меня смысл в этом.
  • BindableConverter для WPF
    0
    ну вот прям чесслово! сами попробуйте прибиндить ConverterParameter куда-нить!
  • Нужен ли C#-у «state»?
    0
    ну мне вообще очень пригодилась эта штука, когда надо было сравнивать много объектов между собой по определенным правилам и производить селекцию.
  • Пилим простенький Binder…
    0
    при многопоточности этот код и так бабахнется.
    падает конечно. я специально опустил этот момент, чтобы не грузить новичков нипанятным. а вообще, там стандартная схема if(...InvokeRequired). ну и через делегат, который вызывает тот же самый метод. все летает прекрасно. вообще голова теперь не болит за обновление контролов
  • Пилим простенький Binder…
    0
    Это как? Если задействован set-аксессор поля Property, то пока не выработается его логика, никто ни от чего отписаться не может. Не уверен насчет кросс-поточности, но в любом случае этот код падает при попытке изменить контрол с НЕ-UI потока. Я уже писал выше.
  • Пилим простенький Binder…
    –1
    падает конечно. я специально опустил этот момент, чтобы не грузить новичков нипанятным. а вообще, там стандартная схема if(...InvokeRequired). ну и через делегат, который вызывает тот же самый метод. все летает прекрасно. вообще голова теперь не болит за обновление контролов.
  • Пилим простенький Binder…
    0
    Да наверно ничего сложного нет. Вопрос только в том, что обычно биндинги обеспечивают от контрола к источнику связь. Я знаю, что есть двухсторонний режим, но мне реально быстрее было один раз написать свое, чем лезть на msdn.com и вычитывать там как настроить двухстороннюю связь при многопоточности. У них серьезные проблемы с документацией по этому вопросу.