- mingw
- Постоялец
tac
> я хочу писать нормально Name = "test", а не бред вида setName("test")
Это называется "не знаешь до чего докопаться - докопайся до синтаксиса - так ты сведёшь весь спор к субъективщине".
Я могу объективно с аргументами показать, в чём реальное отличие свойств от функций, и почему свойства в C# задизайнены плохо (как и многие другие фичи этого языка). После свифта это особенно хорошо заметно. Но ТС попросил поменьше флудить, так что если хочешь - создай отдельную тему - там похоливарим.
Проблема в терминологии. Многие говорят, что энкапсуляция это сокрытие - это определение верно, но оно не совсем точно отображает его суть. Можно подойти с другой стороны... энкапсуляция это способ убрать данные от прямого доступа к ним, что бы была некая прослойка в виде функции, которая обеспечивает безопасную работу с энкапсулированными данными. То есть энкапсуляция это больше про защиту и безопасность нежели про сокрытие - собственно с английского дословно оно так и переводится "взять под козырек".
mingw
> что энкапсуляция это сокрытие
> ИНкапсуляция, ввод (IN/OUT)
так и было, только теперь вики пишет что инкапсуляция это панель управления на которой снаружи торчат, кнопочки, переключатели, лампочки, а вся логика тебе не видна за счёт того что ты общаешься и видишь только интерфейс и что именно это и есть инкапсуляция. Любой класс может служить интерфейсом или быть абстрактной прослойкой видимой снаружи, API, WEB API (REST API), абстрактный класс, интерфейс.
Но Джава гибче благодаря рефлексии, мы сами можем добавить эту прослойку для любого класса.
tac
игры то не увидим? за двумя зайцами погонишься..
Alastor-X
Большинство из нас тут программисты, Java живут на других форумах, тебе к ним. Они в основном в Minecraft на моддинге и ещё половина на вебе, игры на джемах. Тут никто не станет рисковать.
Я так скажу, если ты сам не можешь сделать игру в одиночку, то и в команде это не получится, потому что программист ты будешь 1 и помочь тебе будет некому. Единственное, в команде учишься быстрее. Но надо иметь рабочую игру для начала, которая уже работает и которую можно улучшать (как моддинг).
Возьмите Irrlicht или libGDX и сделайте что нить (их ещё надо заставить работать, очень у них непривычная настройка чтобы всё заработало как надо ведь надо найти правильную версию Java, плюс там ещё разборки с gradle который тоже определенной версии работает лишь с определенной версией Java). А может даже кто то работает через Maven, который совсем другой. Плюс изучить Ant который будет необходим для автоматизации и сборки пакетов в 1 или несколько JAR или просто ZIP.
tac
> Вам бы подучить мат. часть (методы вместе с данными это класс называется ;)
открываю первую попавшуюся ссылку в гугле
In general, encapsulation is a process of wrapping similar code in one place. In C++, we can bundle data members and functions that operate together inside a single class.
https://www.programiz.com/cpp-programming/encapsulation
вторую ссылку
Encapsulation in C++ is defined as the wrapping up of data and information in a single unit. In Object Oriented Programming, Encapsulation is defined as binding together the data and the functions that manipulate them.
https://www.geeksforgeeks.org/encapsulation-in-cpp/
тут даже не про с++, а про ООП в целом
#!
Это какой то бред, но понятно, теперь откуда вы его набрались. У меня пока нет времени вам разжевывать основы, почитайте просто Г. Буч ... там доступно. Читайте первоисточники тогда вам не прейдется садится в лужу, когда вы читаете х..ню на заборе.
tac
> Это какой то бред
тоже Grady Booch
In his book on object-oriented design, Grady Booch defined encapsulation as "the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation."
https://en.wikipedia.org/wiki/Information_hiding#Encapsulation
и это в статье посвящённой сокрытию, что бы это могло значить, наверное это всё же разные вещи раз для них придуманы разные названия
ну и там в основной статье
In software systems, encapsulation refers to the bundling of data with the mechanisms or methods that operate on the data. It may also refer to the limiting of direct access to some of that data, such as an object's components.
Encapsulation (computer programming)
это примерно как национальность и гражданство которые многими используются взаимозаменяемо
#!
> что бы это могло значить
Это может значить лишь бред напичканный Википедией. Никаких двух понятий нет, есть одно.
Вот русский аналог
Инкапсуляция — это процесс отделения друг от друга элементов объекта, определяющих
его устройство и поведение; инкапсуляция служит для того, чтобы изолировать контрактные
обязательства абстракции от их реализации.
он никак не связан с тем бредом, который вы приводили ранее. Вы можете попробовать сами разобраться в этом вопросе? Вам нужно взять книгу Г. Буча, и т.к. вы ни слова не поняли в определении, которое только что привели. И прочитать, то что идет прямо следующей строкой за ним.
Примеры инкапсуляции. Вернемся к примеру гидропонного тепличного хозяйства. Еще
одной из ключевых абстракций данной предметной области является нагреватель,
поддерживающий заданную температуру в помещении. Нагреватель является абстракцией низкого
уровня, поэтому можно ограничиться всего тремя действиями с этим объектом: включение,
выключение и запрос состояния. Нагреватель не должен отвечать за поддержание температуры,
это будет поведением более высокого уровня, совместно реализуемым нагревателем, датчиком
температуры и еще одним объектом. Мы говорим о поведении более высокого уровня, потому что
оно основывается на простом поведении нагревателя и датчика, добавляя к ним кое-что еще, а
именно гистерезис (или запаздывание), благодаря которому можно обойтись без частых
включений и выключении нагревателя в состояниях, близких к граничным. Приняв такое решение
о разделении ответственности, мы делаем каждую абстракцию более цельной.
[далее идет конкретный пример, инкапсуляции поведения]
То что вы или такие дурочки, которые писали Википедию, это не понимание следующих слов Буча (и только, термина как такового не существует)
В идеальном случае попытки обращения к данным, закрытым для доступа, должны
выявляться во время компиляции программы. Вопрос реализации этих условий для конкретных
языков программирования является предметом постоянных обсуждений. Так, Smalltalk
обеспечивает защиту от прямого доступа к экземплярам другого класса, обнаруживая такие
попытки во время компиляции. В тоже время Object Pascal не инкапсулирует представление
класса, так что ничто в этом языке не предохраняет клиента от прямых ссылок на внутренние поля
другого объекта. Язык CLOS занимает в этом вопросе промежуточную позицию, возлагая все
обязанности по ограничению доступа на программиста. В этом языке все слоты могут сопровождаться атрибутами :reader, :writer и : accessor, разрешающими соответственно чтение,
запись или полный доступ к данным (то есть и чтение, и запись). При отсутствии атрибутов слот
полностью инкапсулирован. По соглашению, признание того, что некоторая величина хранится в
слоте, рассматривается как нарушение абстракции, так что хороший стиль программирования на
CLOS требует, чтобы при публикации интерфейса класса, документировались бы только имена
его функций, а тот факт, что слот имеет функции полного доступа, должен скрываться [55]. В
языке C++ управление доступом и видимостью более гибко. Члены класса могут быть отнесены к
открытой, закрытой или защищенной частям. Открытая часть доступна для всех объектов;
закрытая часть полностью закрыта для других объектов; защищенная часть видна только
экземплярам данного класса и его подклассов. Кроме того, в C++ существует понятие «друзей»
(friends), для которых открыта закрытая часть.
Скрытие информации — понятие относительное: то, что спрятано на одном уровне
абстракции, обнаруживается на другом уровне. Забраться внутрь объектов можно; правда, обычно
требуется, чтобы разработчик класса-сервера об этом специально позаботился, а разработчики
классов-клиентов не поленились в этом разобраться. Инкапсуляция не спасает от глупости; она,
как отметил Страуструп, «защищает от ошибок, но не от жульничества»
Здесь он говорит о модификаторах доступа, как инструменте для инкапсуляции, и в проброс называет это "скрытием информации", как о синониме инкапсуляции, только на разговорном языке.
Впрочем, я понял откуда эта хрень идет, кто-то составлял словарь терминов в книге Буча, и там он приведено следующие
инкапсуляция, encapsulation. Процесс разделения элементов абстракции,
которые образуют ее структуру и поведение. Служит для отделения внешних
обязательств объекта от его реализации.
скрытие информации, information hiding. Процесс скрытия всех секретов
объекта, которые ничего не добавляют к его существенным характеристикам; обычно
скрывают структуру объекта и реализацию его методов.
Не знаю, зачем он запутал людей, но это ровно одно и то же. Если у него (в первоисточнике это хотя бы ясно - что это суть одно и тоже), то дурачки из Википедии и т.п. ютуберы пытаются понять разницу, которой нет :)
tac
> дурачки из Википедии и т.п. ютуберы пытаются понять разницу, которой нет
разницы нет в том смысле, что инкапсуляция частный случай сокрытия применительно к классам, которые разделены на переменные и методы
в отличие, скажем от библиотек, которые предоставляют API к своей реализации
просто для сишников оно звучало странно, там и так переменные отдельно, функции отдельно, поэтому они обратили внимание на то, что эти функции находятся там же где и переменные, в одной структуре, для них это было диковинкой
отсюда разносторонние трактовки одного и того же явления
#!
> просто для сишников оно звучало странно, там и так переменные отдельно, функции отдельно, поэтому они обратили внимание на то, что эти функции находятся там же где и переменные, в одной структуре, для них это было диковинкой
еще раз повторю, что вы тут что-то напутали ... это определение класса, а не инкапсуляции
#!
> в отличие, скажем от библиотек, которые предоставляют API к своей реализации
нет тут никакого "в отличии" ... это такая же инкапсуляция
#!
> инкапсуляция частный случай сокрытия применительно к классам
давайте тогда так инкапсуляция - это термин ООП, и конечно же он не является ни каким частным случаем. В структурном программировании никто это не называл ни каким отдельным термином. Инкапсуляция - это было одним из признаков ООП, в отличии от структурного.
и как вы ещё и на игры время находите?!
ivashko
> и как вы ещё и на игры время находите?!
в терминологии полезно разбираться, а то я например заучил, что ООП это инкапсуляция, наследование, полиморфизм
теперь смотрю, что ECS лучше, там ноль из перечисленных ингредиентов, и всё работает
но это да, оффтоп, к тому же где-то была ветка где tac и kipar вроде как разбирали оба подхода
https://gamedev.ru/code/forum/?id=269938
#!
> ООП
такие вещи надо не учить, а использовать ИМХО. И тут как раз игрострой очень кстати для практики...
Чем терминами бодаться, лучше подскажи:
Сделал я туман постпроцессом. Накрыл им полупрозрачную воду и ландшафт. А факел частиц на фоне этого накрытого ландшафта не светится... Получается, что постпроцесс, который должен по нодам закрашиваеть всё что далеко, заодно закрашивает и полупрозрачные частицы перед камерой.
Я покликал галочки в свойствах материала и оказалось, что
SSR или before translucent выключают закрашивание факела, а заодно и выключают закрашивание воды, которая далеко и для закрашивания которой был сделан этот туман.
Я пробовал даже регулировать это замеряя глубину пикселя и расстояние до него, но всё с тем же результатом.
Как такое исправляют?
нашёл где спросить
в анриле из-за какой-нибудь сраной галочки может всё работать наперекосяк
поэтому там только обезьяний метод тыка
