Я не собираюсь вас убеждать в том, что в объектно-ориентированном программировании речь идёт прежде всего об объектах, содержащих методы — это слишком неочевидное утверждение.
Как и в том, что «в подавляющем большинстве задач» кроме ооп есть более простые решения — имея мысли только в пределах объектов, понять это невозможно, потому что и топор можно мысленно приспособить для прорубания шахты — стоит только вообразить взятие топоров в достаточном количестве, трату чуть большего количества времени, и убеждение остальных в том, что это единственная правильная картина мира.
Эти мысли об универсальной «серебрянной пуле под названием X» уходят только после внутреннего вопроса «А может здесь что-то не так?» и дальнейшей работе (не просто прочтения статей, а именно непосредственной работе) с другими подходами, либо не уходят никогда.
Да, в последнее время так и происходит, и это хорошее направление) Разговор, конечно, и о том что инженерный подход — выбирать инструмент в зависимости от специфики задачи, а не подминать решение под любимую парадигму / инструмент.
более сложное отображение в объектное представление.
В этом же и суть! Объектное представление, ооп. В зависимости от задачи, на выбор есть куча подходов и языков, позволяющих минимизировать концептуальную сложность решения. Объектные иерархии значительно усложняют решение, когда в большинстве случаев можно обойтись более простыми вещами в голове.
Громадную статью на английском по ссылке не осилил — к сожалению, у меня не такой уж беглый английский… Можете нам, дремучим работникам ООП, рассказать её смысл в двух словах?
Статья, проницательно копающая в суть проблемы. Одна из мыслей в следующем: есть вещи (nouns) и действия (verbs).
ООП-языки (Java) занимаются тем, что возводят вещи (объекты) на первое место, а действия — на второе (методы). Методы / преобразования должны принадлежать объектам, на вторых ролях. Объекты же образуют иерархии, наследуются друг от друга, инициируя и отвечая за все действия.
На другой стороне ортодоксально-функциональные языки, типо Haskell'а. Там действия это чистые функции, и они играют главную роль — многое сделано для того, чтобы их комбинировать, передавать как аргументы в другие функции, разными способами применять. Для данных (вещей) же есть неизменяемость, система типов, полиморифзм типов и т.д.
Есть же языки мультипарадигменные — JS (прототипное наследование / элементы функциональной парадигмы), Clojure (куча отличных идей из разных парадигм), Scala.
Возведение вещей в абсолютный приоритет губительно тем, что при этом приходится мыслить в терминах вещей. В терминах DistributedQueryAnalyzer'ов, NotificationSchemaManager'ов, PriorityMessageDispatcher'ов, проектировать их иерархию, принося в задачу дополнительную сложность, которая с самой задачей никак не связана — одним словом, возводить горы. После реализации они выглядят настолько внушительно и недвижимо, что заставляют чувствовать наслаждение (сам испытывал) и продолжать делать новые. Ещё более громадные и величественные.
Суть в том, что ооп — это всего лишь один из способов мышления над решениями задач. Концептуально это хорошая идея, но после ознакомления с другими подходами 90% времени вы не будете по ним скучать.
Ребят, я люблю возводить объектно-ориентированные горы. Коллеги спрашивают «Зачем?», но я не знаю что ответить. Объясните, какими доводами можно подкрепить это желание?
+2
Я тоже фанатею от проектирования этих гор, и часто страдаю. На самом деле, это имеет смысл только в потенциально сложных системах — там нужно проектировать иерархии объектов более тщательно и обильно, делая решение сложной задачи ещё сложнее.
> Master the JavaScript Interview: What’s the Difference Between Class & Prototypal Inheritance?
>
>Интервью с мастером JS: какая разница между наследованием класса и прототипным наследованием?
Прошу исправить перевод на «освойте интервью на должность js-разработчика» (или короче) — «master» здесь глагол :)
Это правда. Но в таких случаях можно воспользоваться библитекой Immutable.js от facebook, которая реализует неизменяемые структуры данных (множества, списки, хэши) с дешёвыми изменениями.
Ещё один пример проблемы отсутствия точного времени в получаемых значениях.
Это сделано в целях безопасности. Например, Philips проводили эксперимент с Ambient Light Events — в торговом центре установили источники освещения, варьирующие интенсивность света по определенённым паттернам (на частотах, не различаемых людьми) в разных залах. Для определения своего местоположения пользователи могли воспользоваться приложением, которое использовало точные значения датчика освещённости.
Если вам это очевидно, то это хорошо. Просто я часто встречаюсь с такими идеями, которые на первый взгляд кажутся настолько очевидными, насколько это возможно — а потом заставляют поразиться тому как, несмотря на это, совершаешь противоречащие этим идеям ошибки. Тривиальный, выдуманный пример — когда говорят, или говоришь себе «во время работы сохраняйся». Думаешь — очевидно же, как можно этого не делать. А потом материшь погасший монитор, из-за перебоя.
Или как принципы гештальтпсихологии — кажутся очевидными, в голове фраза «да так и есть, зачем это писать?». Но на самом деле, если попросить назвать какие-нибудь закономерности, по которым человек воспринимает информацию — вряд ли выйдет.
Как и в том, что «в подавляющем большинстве задач» кроме ооп есть более простые решения — имея мысли только в пределах объектов, понять это невозможно, потому что и топор можно мысленно приспособить для прорубания шахты — стоит только вообразить взятие топоров в достаточном количестве, трату чуть большего количества времени, и убеждение остальных в том, что это единственная правильная картина мира.
Эти мысли об универсальной «серебрянной пуле под названием X» уходят только после внутреннего вопроса «А может здесь что-то не так?» и дальнейшей работе (не просто прочтения статей, а именно непосредственной работе) с другими подходами, либо не уходят никогда.
В этом же и суть! Объектное представление, ооп. В зависимости от задачи, на выбор есть куча подходов и языков, позволяющих минимизировать концептуальную сложность решения. Объектные иерархии значительно усложняют решение, когда в большинстве случаев можно обойтись более простыми вещами в голове.
Статья, проницательно копающая в суть проблемы. Одна из мыслей в следующем: есть вещи (nouns) и действия (verbs).
ООП-языки (Java) занимаются тем, что возводят вещи (объекты) на первое место, а действия — на второе (методы). Методы / преобразования должны принадлежать объектам, на вторых ролях. Объекты же образуют иерархии, наследуются друг от друга, инициируя и отвечая за все действия.
На другой стороне ортодоксально-функциональные языки, типо Haskell'а. Там действия это чистые функции, и они играют главную роль — многое сделано для того, чтобы их комбинировать, передавать как аргументы в другие функции, разными способами применять. Для данных (вещей) же есть неизменяемость, система типов, полиморифзм типов и т.д.
Есть же языки мультипарадигменные — JS (прототипное наследование / элементы функциональной парадигмы), Clojure (куча отличных идей из разных парадигм), Scala.
Возведение вещей в абсолютный приоритет губительно тем, что при этом приходится мыслить в терминах вещей. В терминах DistributedQueryAnalyzer'ов, NotificationSchemaManager'ов, PriorityMessageDispatcher'ов, проектировать их иерархию, принося в задачу дополнительную сложность, которая с самой задачей никак не связана — одним словом, возводить горы. После реализации они выглядят настолько внушительно и недвижимо, что заставляют чувствовать наслаждение (сам испытывал) и продолжать делать новые. Ещё более громадные и величественные.
Суть в том, что ооп — это всего лишь один из способов мышления над решениями задач. Концептуально это хорошая идея, но после ознакомления с другими подходами 90% времени вы не будете по ним скучать.
+2
+2
-2
>
>Интервью с мастером JS: какая разница между наследованием класса и прототипным наследованием?
Прошу исправить перевод на «освойте интервью на должность js-разработчика» (или короче) — «master» здесь глагол :)
Спасибо за дайджест!
Это сделано в целях безопасности. Например, Philips проводили эксперимент с Ambient Light Events — в торговом центре установили источники освещения, варьирующие интенсивность света по определенённым паттернам (на частотах, не различаемых людьми) в разных залах. Для определения своего местоположения пользователи могли воспользоваться приложением, которое использовало точные значения датчика освещённости.
www.youtube.com/watch?v=zvG97aOfAJM — интересная лекция на тему сенсоров в целом.
Или как принципы гештальтпсихологии — кажутся очевидными, в голове фраза «да так и есть, зачем это писать?». Но на самом деле, если попросить назвать какие-нибудь закономерности, по которым человек воспринимает информацию — вряд ли выйдет.
Надеюсь, вы поняли мою мысль:)