Большая часть рекламного времени отведено на показ женского тела. Таким образом, визуальный ряд не связан с рекламируемым продуктом.
Если в рекламном ролике обыгрывается сценка как девушка гладит рубашку перед выходом на улицу, то что должно показываться большую часть рекламного времени? Утюг? Но тогда
Большая часть рекламного времени отведено на показ утюга. Таким образом, визуальный ряд не связан с рекламируемым продуктом.
Имхо, в Бюро рекламных стандартов руководствовались не логикой, а чем то иным.
Большинство законов — это некие упрощения, работающие в строго определённых условиях и с определенной погрешностью. Хороший пример этого — сила притяжения к Земле F=mg, эта формула может быть СОЗДАНА на основании закона всемирного тяготения F=mMG/(R*R). Точно также закон Бойля-Мариотта является частным случаем более «подробного» закона и может быть создан на его основе. Напомню, что соударение частиц газа носит случайный характер и поведение газа в целом носит вероятностный характер. Таким образом законы можно не только открывать опытным путём, но и создавать теоретически.
Думаю, доход от налогов с продажи спиртных напитков очень приличный. Своё мнение по поводу того, имеет ли это связь с общественным мнением по поводу запрета некоторых веществ, которые не вызывают физического привыкания и действие которых похоже на алкоголь, но производство которых тяжелее контролировать — высказывать не буду. Да и есть ли такие вещества — тоже не знаю.
P.S. Всё вышесказанное является моим личным мнением. Да я ничего по сути и не говорил. Sapienti sat.
Жертвовать простотой\читабельностью\архитектурой можно в любом языке, необязательно используя С++ и необязательно нарушая ООП (например, при выводе в поток данных гигантского объекта, можно запрашивать у объекта данные порциями, используя паттерн iterator). При этом быстродействие необязательно будет максимальным при использовании именно С++. В Java/C# используется JIT-компилятор, который «на лету» компилирует программу и оптимизирует её под конкретный процессор пользователя, в результате чего программа медленнее запускается но быстрее работает (что особенно полезно в серверных приложениях, которые запускаются раз в сутки и работают весь день), быстродействию тут может помешать разве что периодически запускаемый сборщик мусора.
Имхо, статья была про проектирование, а про проектирование не стоит говорить в контексте «а как быть, если нужно написать код для микроконтроллера?». В микроконтроллерах понятность кода как ценность находится на самом последнем месте. Не в микроконтроллерах не нужно оптимизировать всё подряд — нужно искать узкие места.
Это проблемы и особенности конкретного языка (С++).
По поводу std::ostream: в языках, которые изначально разрабатывались как объектно-ориентированные (Java/C#), в любом классе есть метод ToString(), так что преобразование в строку в ООП-языках находится внутри класса.
По поводу бинарных операторов: эта рекомендация связана с тем, что иначе C++ в некоторых случаях не сможет сделать преобразование типов и вызвать бинарный оператор. Это тоже особенность языка. Вообще, методы, нарушающие инкапсуляцию — как то не в духе ООП, вам не кажется?
По поводу вещественнозначного вектора: можно написать приведение вещественнозначного вектора к комплекснозначному, а умножение поместить в класс комплекснозначного вектора.
Сам объект про этот формат и его требования ничего не знает
Если так рассуждать, то получается, что математический объект сам не знает как умножиться на другой объект — об этом знает Операция умножения, он сам не знает как получить свой хэш — об этом знает Вычислитель хэша, и т.д. При таком подходе получаются классы без методов и классы без данных с одним публичным методом, что является по сути процедурным подходом (но не ООП). Согласен, конвертации не место в математическом объекте, но по несколько иной причине: конвертация в нужный формат не имеет ничего общего с предметной областью и не должна засорять классы предметной области.
Эммм… а кто-то говорил, что смекалка тут является обязательным требованием? Я же предложил и другой подход:
Зато есть механизм расчёта пересечения Square с любой фигурой, можно его посмотреть, раз не хватает смекалки… поискать и в круге, и в квадрате
хотя тут речь идёт не о смекалке, а скорее о понимании ООП. А как я говорил в статье, простой код и код, для написания которого требуется как можно меньше усилий и знаний — не одно и тоже.
В результате пересечения прямоугольника и круга может получится, в зависимости от размера фигур: прямоугольник, круг, скруглённый прямоугольник — посмотрите внимательнее код, там есть комментарий. Поэтому ваше предложение не подходит.
в Square просто нет метода расчета пересечения с кругом. Первая реакция — WTF?
Зато есть механизм расчёта пересечения Square с любой фигурой, можно его посмотреть, раз не хватает смекалки метод пересечения круга и квадрата поискать и в круге, и в квадрате. Если у вас есть идея как написать замечательный простой код, работать с которым сможет и codemonkey без зачатков логики, и в котором можно будет ещё проще найти нужный метод, то, может быть, поделитесь?
В каком классе находится метод, рассчитывающий пересечение круга и квадрата?
Как стороннему программисту, который первый раз видит код, это узнать, не перебирая все классы?
Там 3 примера кода. В первом примере — искать usages Круга или Квадрата, это сказано в статье. После первого рефакторинга, во втором и третьем примерах, поведение, специфичное для Круга и Квадрата, находится внутри классов Круг и Квадрат. Для того чтобы понять, что искать нужно именно там, нужно изучить ООП (хотя по usages тоже можно найти).
Не совсем понимаю, почему люди не согласны с тем, что straightforward («простой», «прямолинейный», «честный», «открытый», «откровенный») наиболее точно отражает суть принципа KISS в программировании. Потому что историческое название из авиастроения, откуда появился принцип, «Keep it simple stupid»? Или почему то ещё?
Невозможно и на данный момент не написана программа — разные высказывания, которые приводят к прямо противоположным ответам в вопросе существует ли вообще критерий простоты.
Если в рекламном ролике обыгрывается сценка как девушка гладит рубашку перед выходом на улицу, то что должно показываться большую часть рекламного времени? Утюг? Но тогда
Имхо, в Бюро рекламных стандартов руководствовались не логикой, а чем то иным.
P.S. Всё вышесказанное является моим личным мнением. Да я ничего по сути и не говорил. Sapienti sat.
Имхо, статья была про проектирование, а про проектирование не стоит говорить в контексте «а как быть, если нужно написать код для микроконтроллера?». В микроконтроллерах понятность кода как ценность находится на самом последнем месте. Не в микроконтроллерах не нужно оптимизировать всё подряд — нужно искать узкие места.
По поводу std::ostream: в языках, которые изначально разрабатывались как объектно-ориентированные (Java/C#), в любом классе есть метод ToString(), так что преобразование в строку в ООП-языках находится внутри класса.
По поводу бинарных операторов: эта рекомендация связана с тем, что иначе C++ в некоторых случаях не сможет сделать преобразование типов и вызвать бинарный оператор. Это тоже особенность языка. Вообще, методы, нарушающие инкапсуляцию — как то не в духе ООП, вам не кажется?
По поводу вещественнозначного вектора: можно написать приведение вещественнозначного вектора к комплекснозначному, а умножение поместить в класс комплекснозначного вектора.
Если так рассуждать, то получается, что математический объект сам не знает как умножиться на другой объект — об этом знает Операция умножения, он сам не знает как получить свой хэш — об этом знает Вычислитель хэша, и т.д. При таком подходе получаются классы без методов и классы без данных с одним публичным методом, что является по сути процедурным подходом (но не ООП). Согласен, конвертации не место в математическом объекте, но по несколько иной причине: конвертация в нужный формат не имеет ничего общего с предметной областью и не должна засорять классы предметной области.
хотя тут речь идёт не о смекалке, а скорее о понимании ООП. А как я говорил в статье, простой код и код, для написания которого требуется как можно меньше усилий и знаний — не одно и тоже.
В результате пересечения прямоугольника и круга может получится, в зависимости от размера фигур: прямоугольник, круг, скруглённый прямоугольник — посмотрите внимательнее код, там есть комментарий. Поэтому ваше предложение не подходит.
Зато есть механизм расчёта пересечения Square с любой фигурой, можно его посмотреть, раз не хватает смекалки метод пересечения круга и квадрата поискать и в круге, и в квадрате. Если у вас есть идея как написать замечательный простой код, работать с которым сможет и codemonkey без зачатков логики, и в котором можно будет ещё проще найти нужный метод, то, может быть, поделитесь?
Там 3 примера кода. В первом примере — искать usages Круга или Квадрата, это сказано в статье. После первого рефакторинга, во втором и третьем примерах, поведение, специфичное для Круга и Квадрата, находится внутри классов Круг и Квадрат. Для того чтобы понять, что искать нужно именно там, нужно изучить ООП (хотя по usages тоже можно найти).