Я потрясён количеством троллей, готовых до хрипоты спорить с тем что 2+2=4.
Допустим, я шеф-повар, я хочу обучить новых поваров, говорю: на бутерброды надо класть масло, на него колбасу, рыбу, икру или сыр. Крем для обуви и цемент на бутерброды не кладут.
Кто-то1: — Кладут. Если бутерброд это тип сэндвич панелей для строительства жилых домов!!!
Кто-то2: — Если вы не делаете бутерброды с кремом для обуви это ваши проблемы!
Кто-то3: — Внезапно, сыр это не еда. Сыр — это доменная сущность.
Да идите… Как я перейду к обсчёту крыла для самолётов если мы спорим о том что дважды два не пять?
Моя карма уже стала -6, карма того кто доказывает что сыр доменная сущность стала +27.
И что???? На нём поэтому должны учиться 200 000 Гарри Поттеров??? Помимо того что в подобную игру никто не станет играть она не имеет отношение к канону игромира.
Внезапно, это глобальная переменная. То есть переменная, существующая в рамках одного сеанса работы одного пользователя, до того как он закрыл программу. Не заставляйте всех общаться на языке конкретно вашей экзотической среды разработки.
Другой пример глобальной переменной — игровое время суток, игровой сезон года. Это простые переменные. Хогвартс и Букля — сложные, их структура читается из файлов конфигурации.
Тем, что существует в единственном экземпляре. Эту сову, принадлежащую Поттеру, зовут Букля. Вы не можете создать сцену, в которой их будет две. Если Букля сегодня поцарапала лапку, то завтра она будет прихрамывать.
Другие животные игрового мира, кроме некоторых таких же как она, существуют только внутри сцены с ними. Их может в сцене быть любое количество. Они не сохраняют состояние за пределами сцены, выстрелив зайцу в лапку вы не встретите после этого одноногого зайца на следующей неделе. Состояние рандомного зайчика не сохранится после того как он ушёл за пределы сюжета одного дня (сцены).
В этом разница между Буклей и прочим животным миром.
Вы в своих идеях про ООП похожи на теоретика коммунизма, который приехал в постреволюционный СССР. А под красивыми названиями совершенно другое делают (см. выше).
Объе́ктно-ориенти́рованное программи́рование (ООП) — методология программирования, основанная на представлении программы в виде совокупности объектов, каждый из которых является экземпляром определённого класса, а классы образуют иерархию наследования. Википедия
Вы программист? Тогда вы помните, что при рисовании на экране (средствами WinAPI) ширина это вправо, а высота это вверх. То же самое при изменении свойств windows-окон.
Давайте всё-таки не слишком убегать от реального мира.
Электроплита греет сковородку, потому что на контакты плиты подано 220 вольт?
Или на входе электроплиты образуется 220 вольт потому, что она греет сковородку?
Вообще-то причина и следствие в этом вопросе довольно просто определяется.
знаем количество выстреленных патронов (1 или 2), знаем расстояние (сравнивая Игрок.Position и Монстр_1.Position), и внутри метода класса Шотган, рассчитываем ущерб.
Нет, шотган не знает о типе монстров. Только о количестве патронов (1 или 2) и о расстоянии до мишени. Только исходя из этого. Компьютерные игры обычно имеют нереалистично малый радиус, за которым ущерба не наносится вообще.
В случае Суворова, взявшего Измаил, действие по взятию крепости было целенаправленным.
В случае земных или космических ДТП, очевидно, целенаправленных действий нет. Могу предложить у каждого из участников ДТП вызвать метод его инвентаризации, в каком состоянии он теперь. + Можно создать объект столкновения, с методами типа Список_виновников и т.п.
«Сложность системы», о которой они там говорят, пропорциональна числу строк кода и не зависит от языка и стилей. При переходе от ассемблера к коду на языке высокого уровня, число строк сокращается на порядок. При переходе на глубокое ООП, вырастает на порядок.
И систему надо бить на изолированные блоки. Тогда сложность приводящая к ошибкам будет сложностью блока, а не системы в целом. Я имею ввиду блоки трудоёмкостью разработки от 0.5 до 10 человекомесяцев.
========================================
Говоря о задачах, не решаемых без помощи ООП, обычно имеют ввиду следующее: вот вы подошли к работающему ноутбуку, за котором сидела Маша. Известно, что Маша любит Петю. Напишите функцию, которая возвратит максимально много информации о действии при нажатии на кнопку F7.
На что принято отвечать, что ноутбук это ООП объект, который должен пройти все стадии с момента включения, загрузки и т.п., и только тогда возможен ответ. Чтобы объект Ноутбук хранил корректное состояние.
Я же показываю, что этой цели можно достичь и функцией, передав в неё указатель на структуру состояний объекта. Лучше ли это — другой вопрос.
Пусть есть фирма продающая ноутбуки, в ней есть информационная система, в ней объект TNotebook, в котором есть метод Увеличить ОЗУ. У нотбука увеличивается на требуемую величину ОЗУ и вырастает его цена.
Допустим теперь, что на склад поступили ноутбуки где ОЗУ увеличить нельзя. Значит, на ноутбуках этой марки, вызов метода начнёт выдавать ошибку, с осмысленным сообщением: выбранная марка ноутбука не позволяет увеличить ОЗУ.
Допустим, для них создан подкласс, по названию их фирмы производителя, скажем, TNotebookAdidas.
Следуя вашей логике, такие ноутбуки не являются ноутбуками?
Вот смотрите. У номера кредитной карты должно быть не менее 16 цифр. У квадрата должна быть ширина равна высоте.
Допустим есть диалоговое окно ввода номера карты. Человек ввёл 15 цифр. Ему выдают ошибку.
Допустим есть диалоговое окно ввода размера прямоугольников, но при этом конкретно сейчас с его помощью вводят размер квадрата. Человек ввёл 3х4 метра. Ему выдают ошибку. При этом не важно как выглядит окно, ошибка придёт из серверной стороны при попытке сохранить.
То есть сначала мы пишем в поля, потом делаем Save. На этом этапе серверная часть распознаёт есть ли в данных расхождения. Так же как с номером карты — выбирается тип платежа (банковская карта, а не Яндекс кошелёк или что-то ещё) и номер. До ввода всех полей и вызова сохранения, данные не обязаны быть согласованными.
Почему наличие ограничений по сравнению с классом предка делает квадрат не прямоугольником?
Допустим, я шеф-повар, я хочу обучить новых поваров, говорю: на бутерброды надо класть масло, на него колбасу, рыбу, икру или сыр. Крем для обуви и цемент на бутерброды не кладут.
Кто-то1: — Кладут. Если бутерброд это тип сэндвич панелей для строительства жилых домов!!!
Кто-то2: — Если вы не делаете бутерброды с кремом для обуви это ваши проблемы!
Кто-то3: — Внезапно, сыр это не еда. Сыр — это доменная сущность.
Да идите… Как я перейду к обсчёту крыла для самолётов если мы спорим о том что дважды два не пять?
Моя карма уже стала -6, карма того кто доказывает что сыр доменная сущность стала +27.
Другой пример глобальной переменной — игровое время суток, игровой сезон года. Это простые переменные. Хогвартс и Букля — сложные, их структура читается из файлов конфигурации.
habr.com/ru/post/511572/#comment_21863620
Другие животные игрового мира, кроме некоторых таких же как она, существуют только внутри сцены с ними. Их может в сцене быть любое количество. Они не сохраняют состояние за пределами сцены, выстрелив зайцу в лапку вы не встретите после этого одноногого зайца на следующей неделе. Состояние рандомного зайчика не сохранится после того как он ушёл за пределы сюжета одного дня (сцены).
В этом разница между Буклей и прочим животным миром.
Вы испытываете необходимость в том чтобы спорить?
Я не могу вам помочь, я не психолог и не врач.
Программисты Delphi меня поймут.
Вы в своих идеях про ООП похожи на теоретика коммунизма, который приехал в постреволюционный СССР. А под красивыми названиями совершенно другое делают (см. выше).
Википедия
Давайте всё-таки не слишком убегать от реального мира.
не ООП — классы не создаются
Классы (в Delphi) — это type ...=class(...)
Кроме классов визуальных форм, которые делает сама среда.
Простите, что приземлил вашу высокую философию.
Кормушка1.Isoverflow:boolean
и не ООП:
Кормушка_Isoverflow(@Кормушка1):boolean
(Здесь, "@" — означает что передаётся указатель, а не структура).
Или на входе электроплиты образуется 220 вольт потому, что она греет сковородку?
Вообще-то причина и следствие в этом вопросе довольно просто определяется.
Нет, шотган не знает о типе монстров. Только о количестве патронов (1 или 2) и о расстоянии до мишени. Только исходя из этого. Компьютерные игры обычно имеют нереалистично малый радиус, за которым ущерба не наносится вообще.
В случае Суворова, взявшего Измаил, действие по взятию крепости было целенаправленным.
В случае земных или космических ДТП, очевидно, целенаправленных действий нет. Могу предложить у каждого из участников ДТП вызвать метод его инвентаризации, в каком состоянии он теперь. + Можно создать объект столкновения, с методами типа Список_виновников и т.п.
И систему надо бить на изолированные блоки. Тогда сложность приводящая к ошибкам будет сложностью блока, а не системы в целом. Я имею ввиду блоки трудоёмкостью разработки от 0.5 до 10 человекомесяцев.
========================================
Говоря о задачах, не решаемых без помощи ООП, обычно имеют ввиду следующее: вот вы подошли к работающему ноутбуку, за котором сидела Маша. Известно, что Маша любит Петю. Напишите функцию, которая возвратит максимально много информации о действии при нажатии на кнопку F7.
На что принято отвечать, что ноутбук это ООП объект, который должен пройти все стадии с момента включения, загрузки и т.п., и только тогда возможен ответ. Чтобы объект Ноутбук хранил корректное состояние.
Я же показываю, что этой цели можно достичь и функцией, передав в неё указатель на структуру состояний объекта. Лучше ли это — другой вопрос.
Допустим теперь, что на склад поступили ноутбуки где ОЗУ увеличить нельзя. Значит, на ноутбуках этой марки, вызов метода начнёт выдавать ошибку, с осмысленным сообщением: выбранная марка ноутбука не позволяет увеличить ОЗУ.
Допустим, для них создан подкласс, по названию их фирмы производителя, скажем, TNotebookAdidas.
Следуя вашей логике, такие ноутбуки не являются ноутбуками?
Вот смотрите. У номера кредитной карты должно быть не менее 16 цифр. У квадрата должна быть ширина равна высоте.
Допустим есть диалоговое окно ввода номера карты. Человек ввёл 15 цифр. Ему выдают ошибку.
Допустим есть диалоговое окно ввода размера прямоугольников, но при этом конкретно сейчас с его помощью вводят размер квадрата. Человек ввёл 3х4 метра. Ему выдают ошибку. При этом не важно как выглядит окно, ошибка придёт из серверной стороны при попытке сохранить.
То есть сначала мы пишем в поля, потом делаем Save. На этом этапе серверная часть распознаёт есть ли в данных расхождения. Так же как с номером карты — выбирается тип платежа (банковская карта, а не Яндекс кошелёк или что-то ещё) и номер. До ввода всех полей и вызова сохранения, данные не обязаны быть согласованными.
Почему наличие ограничений по сравнению с классом предка делает квадрат не прямоугольником?