Насколько я знаю, рецепта на процессор в minecraft нет.
Ну во-первых, это не относится к системе крафта и экипировки, об уровнях которых я говорил. В статье я упоминал, что в разных частях проекта может быть предусмотрен разный уровень абстракции.
А во-вторых, не соглашусь, что процессор — это пятый уровень. Скорее второй:
1 уровень — это блоки.
2 уровень — это прочность блоков и NBT-тэги.
3 уровень (которого нет без модов) — возможность в блоки вставлять модификаторы.
4 уровень (тоже отсутствует) — возможность создавать новые блоки с новыми названиями и свойствами.
Процессор работает полностью на блоках и их состояниях, именно поэтому он такой огромный и не масштабируемый, то бишь не гибкий. Вот если бы этот процессор можно было бы создать в виде нового блока и дать ему название «процессор», то да, это был бы четвертый уровень.
В статье 1 абзац, неужели так трудно его прочитать «какие блокировщики рекламы вы используете в ежедневной работе в браузере Vivaldi» в заголовке про Vivaldi ничего нет.
Поэтому я и уточнил:
В заголовке опроса
Ну или я тогда еще предлагаю добавить пункты:
— я не пользуюсь компьютером
— я не использую интернет
— у меня FreeBSD
— Я дельфин
Я думаю это сделать совсем несложно, зато штука очень полезная. Раньше я юзал разные браузеры под разные цели, и поэтому были разные значки. Но теперь вивальдий всех их победил и стал монополистом в моем сердце :3
Значки к профилям прикрутили, а как сделать, чтоб на панели задач этот же значок был? А то у меня 4 инстанса браузера запущено, и все с одинаковыми значками, очень неудобно.
Велосипед — это изобретение чего-то уже изобретенного. Я тоже сначала хотел UML, но уперся в то, что не нашел, как изобразить с помощью него некоторые моменты, описанные в данном комментарии
Понимаете, это как цифры и числа. Нельзя преподавать человеку числа, если он не знает цифр. UML — это числа, а мои схемы — это цифры. UML помогает описывать архитектуру с помощью известных всем механизмов. А мои картинки описывают, как работают эти самые механизмы. Это разные уровни.
Это второй уровень по нашей вымышленной классификации. Там список рецептов, который игрок поменять не в силах. Получающиеся продукты никак не улучшаются. Но если для каких-то вещей есть зачарование, то тогда третий уровень.
Ну если навскидку, то есть несколько «критериев», которые по той или иной причине могут указывать на «полезность» ООП:
Хочется сразу уточнить. Под полезностью ООП вы имеете в виду пользу наличия/отсутствия ООП или пользу сравнительно с какой-то другой парадигмой? Если второе, то с какой именно?
Потому что, чтобы определить, какая парадигма подойдет для данного проекта лучше, нужно реализовать этот проект в разных парадигмах и сравнить стоимость разработки/поддержки в каждой из них. При этом требуются опытные команды разработчиков для каждой парадигмы. Иначе получится, что ООП-шники начнут пробовать реализовывать проект на ФП, у них получится плохо, и они решат, что ФП отстой, ООП — сила. (Я привел две популярные парадигмы, но их на самом деле много, это тоже учитывайте)
А поскольку никто такие дорогостоящие эксперименты не ставит, нам приходится сравнивать похожие проекты в разных парадигмах, не имея на руках данных о стоимости поддержки/разработки, оценивая разницу на глазок. Это и есть «свой и чужой опыт», на который мы можем опираться, об этом я и сказал выше.
Мне кажется, вы неправильно поняли примеры с уровнями абстракции. Эти 4 уровня придуманы для данной статьи для сферической игры в вакууме. Это не какая-то устоявшаяся в индустрии классификация уровней, поэтому рассматривать все возможные уровни и реализации, не имея на руках ТЗ — бессмысленно.
По поводу 4-го уровня. Не понятно, тут разве не о крафте в играх говорится?)
Похоже вы не видите разницу между уровнями, придуманными мной для данной статьи. Система крафта в играх — это обычно второй или третий уровень.
Второй: есть рецепты крафта, которые позволяют из приведенных в рецепте деталей крафтить продукт. Игрок не может добавлять новые рецепты или улучшать существующие.
Третий: поверх рецептов есть система улучшений или модулей, но рецепты все равно жестко прописаны в игре. Например, добавив редкие материалы, вы можете получить продукт с более высокими характеристиками. Либо можете улучшать продукт дополнительными модулями, добавляя тем самым новый функционал.
Четвертый: есть набор деталек, и никаких рецептов. Комбинируя эти детальки, игрок может получать продукты, ранее в игре не существующие. Функционал продукта при этом полностью формируется из свойств деталек и их комбинаций. Поэтому у таких продуктов не может быть названия, игрок должен его придумать сам. И вот такого уровня абстракции в играх я не встречал по указанным в статье причинам, хотя может он и есть.
Не хватает раздела: «а зачем?». Ну серьезно, очень многие так увлекаются, что KISS, YAGNI итд для них не существует, есть только сферический ООП в вакууме.
Если вы внимательно прочитаете статью, заметите, что в ней весь упор делается на то, что нельзя ничем увлекаться и злоупотреблять, и что каждый механизм нужно применять там, где в этом появляется необходимость.
Ну вот холивара ради(ну все равно почти под каждой статьей про ооп такой есть): допустим ваши трансфомеры начали сражаться друг с другом, соответственно нам понадобиться расчитать опыт/здоровье/щиты/прочие штуки, а потом обработать собственно убийство. Тут сразу возникнет вопрос: а где и как? И на этом этапе многие скажут, что нужен класс CombatManager, которому нужно передать трансормеров, вместо optimus->attack(megatron).
Это не относится к ООП, это относится к проектированию. А само ООП — просто один из возможных инструментов реализации вашей архитектуры.
Я привык к стилю программированию на чистом Си (в основном всякой математики), без ++, и соответственно возникает вопрос — а зачем мне использовать ООП, если можно и без него.
Действительно, зачем?
Цитата из статьи:
Любые описанные механизмы, принципы и паттерны, как и ООП в целом не стоит применять там, где это бессмысленно или может навредить.
Зачем натягивать сову на глобус, если у вас и без ООП все прекрасно получается. Возможно ООП вам только навредит.
Никто и не говорил, что это объективное обоснование. Там так и написано — это мое субъективное мнение.
А вот, что объяснение слабое, давайте обсудим. Можете нарисовать с помощью UML так чтобы было понятно, что класс отличается от объекта, что код метода содержится в классе, а состояние в объекте, что в интерфейсе только сигнатура метода, а в классе — имплементация, что метод fire после перегрузки будет вызываться из имплементации класса десептикона, а не трансформера? Если сможете, то вы правы, это объяснение слабое.
Я убежден, что на ранних этапах знакомства, нужно отсечь лишние элементы из диаграмм, которые создают информационный шум, и выделить важное (что для новичка не очевидно) визуальными приёмами: цвет, заполнение, форма. А уже после того, как понимание пришло, можно перейти на профессиональный инструмент.
Если бы у меня была цель вместо букваря детям дать чертежи, я бы назвал статью «ООП в UML-диаграммах», а не в картинках. И тогда да, дети после первого класса могут сразу идти на собеседование, владея чертежами.
Ну во-первых, это не относится к системе крафта и экипировки, об уровнях которых я говорил. В статье я упоминал, что в разных частях проекта может быть предусмотрен разный уровень абстракции.
А во-вторых, не соглашусь, что процессор — это пятый уровень. Скорее второй:
1 уровень — это блоки.
2 уровень — это прочность блоков и NBT-тэги.
3 уровень (которого нет без модов) — возможность в блоки вставлять модификаторы.
4 уровень (тоже отсутствует) — возможность создавать новые блоки с новыми названиями и свойствами.
Процессор работает полностью на блоках и их состояниях, именно поэтому он такой огромный и не масштабируемый, то бишь не гибкий. Вот если бы этот процессор можно было бы создать в виде нового блока и дать ему название «процессор», то да, это был бы четвертый уровень.
Поэтому я и уточнил:
Ну или я тогда еще предлагаю добавить пункты:
— я не пользуюсь компьютером
— я не использую интернет
— у меня FreeBSD
— Я дельфин
В заголовке опроса спрашивается, каким блокировщиком вы пользуетесь, неважно в каком браузере.
Велосипед — это изобретение чего-то уже изобретенного. Я тоже сначала хотел UML, но уперся в то, что не нашел, как изобразить с помощью него некоторые моменты, описанные в данном комментарии
Понимаете, это как цифры и числа. Нельзя преподавать человеку числа, если он не знает цифр. UML — это числа, а мои схемы — это цифры. UML помогает описывать архитектуру с помощью известных всем механизмов. А мои картинки описывают, как работают эти самые механизмы. Это разные уровни.
Согласен. Но это уже будет не статья, а книга про конкретный проект.
Это второй уровень по нашей вымышленной классификации. Там список рецептов, который игрок поменять не в силах. Получающиеся продукты никак не улучшаются. Но если для каких-то вещей есть зачарование, то тогда третий уровень.
Хочется сразу уточнить. Под полезностью ООП вы имеете в виду пользу наличия/отсутствия ООП или пользу сравнительно с какой-то другой парадигмой? Если второе, то с какой именно?
Потому что, чтобы определить, какая парадигма подойдет для данного проекта лучше, нужно реализовать этот проект в разных парадигмах и сравнить стоимость разработки/поддержки в каждой из них. При этом требуются опытные команды разработчиков для каждой парадигмы. Иначе получится, что ООП-шники начнут пробовать реализовывать проект на ФП, у них получится плохо, и они решат, что ФП отстой, ООП — сила. (Я привел две популярные парадигмы, но их на самом деле много, это тоже учитывайте)
А поскольку никто такие дорогостоящие эксперименты не ставит, нам приходится сравнивать похожие проекты в разных парадигмах, не имея на руках данных о стоимости поддержки/разработки, оценивая разницу на глазок. Это и есть «свой и чужой опыт», на который мы можем опираться, об этом я и сказал выше.
Потому что тут нет идеальной инструкции. В этом и заключается проблема, которую каждый решает, опираясь на свой и чужой опыт в похожих проектах.
Похоже вы не видите разницу между уровнями, придуманными мной для данной статьи. Система крафта в играх — это обычно второй или третий уровень.
Второй: есть рецепты крафта, которые позволяют из приведенных в рецепте деталей крафтить продукт. Игрок не может добавлять новые рецепты или улучшать существующие.
Третий: поверх рецептов есть система улучшений или модулей, но рецепты все равно жестко прописаны в игре. Например, добавив редкие материалы, вы можете получить продукт с более высокими характеристиками. Либо можете улучшать продукт дополнительными модулями, добавляя тем самым новый функционал.
Четвертый: есть набор деталек, и никаких рецептов. Комбинируя эти детальки, игрок может получать продукты, ранее в игре не существующие. Функционал продукта при этом полностью формируется из свойств деталек и их комбинаций. Поэтому у таких продуктов не может быть названия, игрок должен его придумать сам. И вот такого уровня абстракции в играх я не встречал по указанным в статье причинам, хотя может он и есть.
Если вы внимательно прочитаете статью, заметите, что в ней весь упор делается на то, что нельзя ничем увлекаться и злоупотреблять, и что каждый механизм нужно применять там, где в этом появляется необходимость.
Это не относится к ООП, это относится к проектированию. А само ООП — просто один из возможных инструментов реализации вашей архитектуры.
Действительно, зачем?
Цитата из статьи:
Зачем натягивать сову на глобус, если у вас и без ООП все прекрасно получается. Возможно ООП вам только навредит.
Никто и не говорил, что это объективное обоснование. Там так и написано — это мое субъективное мнение.
А вот, что объяснение слабое, давайте обсудим. Можете нарисовать с помощью UML так чтобы было понятно, что класс отличается от объекта, что код метода содержится в классе, а состояние в объекте, что в интерфейсе только сигнатура метода, а в классе — имплементация, что метод fire после перегрузки будет вызываться из имплементации класса десептикона, а не трансформера? Если сможете, то вы правы, это объяснение слабое.
Я убежден, что на ранних этапах знакомства, нужно отсечь лишние элементы из диаграмм, которые создают информационный шум, и выделить важное (что для новичка не очевидно) визуальными приёмами: цвет, заполнение, форма. А уже после того, как понимание пришло, можно перейти на профессиональный инструмент.
Если бы у меня была цель вместо букваря детям дать чертежи, я бы назвал статью «ООП в UML-диаграммах», а не в картинках. И тогда да, дети после первого класса могут сразу идти на собеседование, владея чертежами.
Что думаете по поводу этой мысли?
Про интерфейсы хотелось бы услышать мнение господина lair
В статье написано, почему. Или я не понял вопрос.
Я описал и инкапсуляцию, и сокрытие, но мне не стоило их смешивать. Спасибо. Вечером поправлю.