Не сущестсвует задач которые не решаются процедурно.
Допустим, есть гирлянда типа BuBuBu, у неё есть кнопка, переключающая состояние, всего у неё есть 25 состояний: гореть красным, гореть зелёным и т.д…
Можно написать так:
type TGirliandaBuBuBu=class(...
var МояЛюбимаяГирляндочка:TGirliandaBuBuBu;
procedure TGirliandaBuBuBu.DoNextState;
begin
StateNum:=(StateNum+1)%25;
end;
А можно так:
type TGirliandaBuBuBu=record StateNum:byte; ... end;
PGirliandaBuBuBu=^TGirliandaBuBuBu;
var МояЛюбимаяГирляндочка:TGirliandaBuBuBu;
procedure GirliandaBuBuBu_DoNextState(p:PGirliandaBuBuBu);
begin
p.StateNum:=(p.StateNum+1)%25;
end;
И вот мы в рамках процедурного программирования вызываем метод, который меняет внутреннее состояние объекта.
Я уж не говорю про хранение в Record переменных процедурного типа…
Да бога ради, сохраните исходную сигнатуру, кто вам мешает?
ЗадатьРазмеры(Ширина, Высота); override;
…
ЗадатьРазмеры(Ширина, Высота);
begin
if Ширина <> Высота raise(Exception.Create('Это не квадрат.'));
inherited ЗадатьРазмеры(Ширина, Высота);
end;
Один пользователь на одном компьютере/телефоне в одном приложении может одновременно играть в две игры? Или вы считаете что делать игру, в которой каждый играет за Гарри Поттера лично, сетевой — это хорошая идея?
ПОЖАЛУЙСТА НАПИШИТЕ ПРОГРАММНЫЙ КОД ТОГО ЧТО ВЫ ГОВОРИТЕ.
type TKvadrat=Class(TPriamougolnik)
...
var v:TKvadrat;
begin
v:=TKvadrat.Create;
v.SetSize(123);
if v is TPriamougolnik then ShowMessage('да') else ShowMessage('нет')
Любой другой язык программирования, насколько я знаю, скажет тоже «да».
Да и свойство для чтения Площадь, наследуемое от прямоугольника, работает.
Допустим, есть класс Прямоугольник.
У него есть метод ЗадатьРазмеры(Ширина, Высота);
И у него есть свойство Площадь.
Теперь создаю дочерний класс Квадрат.
Переопределяю метод ЗадатьРазмеры(Ширина); с ключевым словом Reintroduce.
Реализация:
ЗадатьРазмеры(Ширина);
begin
inherited ЗадатьРазмеры(Ширина, Ширина);
end;
И всё, имеем квадрат. Можно смело читать из свойства Площадь дочернего класса.
Очевидно, сова не глобальна, она сейчас, скажем, летает вдоль перрона 9¾, в центре перрона, движется к последнему вагону со скоростью 4 метра в секунду. Не понял ваш аргумент. Сова должна быть описана как локальная переменная класса «железнодорожный перрон»? Зачем?
Наверное мы по-разному понимаем термин глобальная переменная.
Напишите код, возвращающий какой угодно параметр конкретной совы.
Реальный код в любом языке.
1. Определяет, потому, что закон физики это не только формула, но и смысл.
2. В сражении по какому поводу? Может быть, всё таки по поводу завоевания крепости Измаил? То есть основная процедура — это получить Измаил, а сражение — основное действие для её реализации.
3. И я о том же.
4. И я о том же. Ок, не выстрел, а обобщённое Атаковать. Для ножа, действие по изменению состояния объекта в игре станет «измазан свежей кровью». Как я и писал, изменение состояния объекта программируется на уровне дочернего класса (нож и шотган — дочерние классы от TWeapon).
5. Набирая сейчас это сообщение, я трогаю ноутбук. Чтобы полноценно описать это, нам потребуется использовать интерфейс, характерный для ноутбука.
Если потребуется затем описать как я трогаю глину во время лепки, то это будет другой интерфейс, и другая терминология.
Так было написано в цитате, но я тоже понял задачу как предоставить еду в миску. Мы программисты. В нашу работу входить додумывать ТЗ опираясь на здравый смысл.
Кстати, вы тоже поняли задачу как предоставить еду, при чем тут часы.
Никто не собирается именно «кормить» кошку.
Нет. Из текста очевидно что речь о миске, я решал конкретную задачу.
Другие условия — это другая задача, имеющая другое решение.
Та кормушка о которой вы говорите не требует участия человека для одного действия кормления кошки. С тем же успехом можно рассмотреть в качестве животного робота от Boston Dynamics. Другие условия — другие решения.
иметь дело с глобальными переменными я вам не рекомендую
Представьте, что вы пишете игру-бродилку — симулятор Гарри Поттера от первого лица, напоминаю что Гарри Поттер имел питомца — сову. Ваша игра не позволяет играть за класс в целом, только за Поттера. Очевидно, что его сова — это глобальная переменная.
кормушек может быть множество все-таки
Глобальные переменные могут быть массивом.
Я имел ввиду, что изменение объёма пищи в миске не стоит выделять в отдельный функционал.
Вот именно с такого подхода и начинается переусложнение систем, из-за которого потом программисты восстают против ООП в целом.
Кормушка — это пластмассовая мисочка. Кормушка не имеет собственных методов, это глобальная переменная, либо запись в базе данных (смотря, что и как пишем). Это не объект.
1) Ну, это же не действие, а регистрация изменения состояния. Ок, я готов признать, что у объекта Крепость имеется метод СменаСобственника — выполняющий изменение всех гербов и флагов, которые в ней представлены, правил приёма путешественников, должностных инструкций для гарнизона и сторожей, используемой валюты, рациона питания (при захвате крепости мусульманами, из меню столовой исчазают блюда, включающие свинину).
2) Нет. Если бы нанесение повреждений ракетой было в момент выстрела, создавать объект Ракета бы не потребовалось. Смысл именно в том, что создан объект Ракета, он обрабатывает Tick (перемещение за 1 тик игрового времени — если ракета не самонаводящаяся, то эта обработка выполнится стандартным методом родительского объекта), и Explosion — взорваться. И только в момент взрыва будет нанесено повреждение тем существам (включая и монстров и игроков), которые были рядом.
Задача была — сделать вариант записи единственным.
Если через резистор R пропускать ток силой I, то падение напряжения на резисторе будет равно U.
Если вы умеете через резистор R пропускать ток силой I, не прикладывая напряжение, то да, в результате этого оно возникнет конечно… Наверно, так можно описать динамо-машину.
Допустим, есть гирлянда типа BuBuBu, у неё есть кнопка, переключающая состояние, всего у неё есть 25 состояний: гореть красным, гореть зелёным и т.д…
Можно написать так:
А можно так:
И вот мы в рамках процедурного программирования вызываем метод, который меняет внутреннее состояние объекта.
Я уж не говорю про хранение в Record переменных процедурного типа…
Тогда надо рандомизировать персонажей и это будет другой проект.
ЗадатьРазмеры(Ширина, Высота); override;
…
ЗадатьРазмеры(Ширина, Высота);
begin
if Ширина <> Высота raise(Exception.Create('Это не квадрат.'));
inherited ЗадатьРазмеры(Ширина, Высота);
end;
Годится вам?
ПОЖАЛУЙСТА НАПИШИТЕ ПРОГРАММНЫЙ КОД ТОГО ЧТО ВЫ ГОВОРИТЕ.
Любой другой язык программирования, насколько я знаю, скажет тоже «да».
Да и свойство для чтения Площадь, наследуемое от прямоугольника, работает.
Список входных параметров метода ЗадатьРазмеры при наследовании был изменён. Поэтому Reintroduce, а не Override.
Допустим, есть класс Прямоугольник.
У него есть метод ЗадатьРазмеры(Ширина, Высота);
И у него есть свойство Площадь.
Теперь создаю дочерний класс Квадрат.
Переопределяю метод ЗадатьРазмеры(Ширина); с ключевым словом Reintroduce.
Реализация:
ЗадатьРазмеры(Ширина);
begin
inherited ЗадатьРазмеры(Ширина, Ширина);
end;
И всё, имеем квадрат. Можно смело читать из свойства Площадь дочернего класса.
Наверное мы по-разному понимаем термин глобальная переменная.
Напишите код, возвращающий какой угодно параметр конкретной совы.
Реальный код в любом языке.
И как обратиться к ней из кода программы?
Это Public на чтение и Private на запись? Я хочу такое в Delphi.
2. В сражении по какому поводу? Может быть, всё таки по поводу завоевания крепости Измаил? То есть основная процедура — это получить Измаил, а сражение — основное действие для её реализации.
3. И я о том же.
4. И я о том же. Ок, не выстрел, а обобщённое Атаковать. Для ножа, действие по изменению состояния объекта в игре станет «измазан свежей кровью». Как я и писал, изменение состояния объекта программируется на уровне дочернего класса (нож и шотган — дочерние классы от TWeapon).
5. Набирая сейчас это сообщение, я трогаю ноутбук. Чтобы полноценно описать это, нам потребуется использовать интерфейс, характерный для ноутбука.
Если потребуется затем описать как я трогаю глину во время лепки, то это будет другой интерфейс, и другая терминология.
Кстати, вы тоже поняли задачу как предоставить еду, при чем тут часы.
Никто не собирается именно «кормить» кошку.
Другие условия — это другая задача, имеющая другое решение.
Та кормушка о которой вы говорите не требует участия человека для одного действия кормления кошки. С тем же успехом можно рассмотреть в качестве животного робота от Boston Dynamics. Другие условия — другие решения.
Глобальные переменные могут быть массивом.
Я имел ввиду, что изменение объёма пищи в миске не стоит выделять в отдельный функционал.
Вот именно с такого подхода и начинается переусложнение систем, из-за которого потом программисты восстают против ООП в целом.
Кормушка — это пластмассовая мисочка. Кормушка не имеет собственных методов, это глобальная переменная, либо запись в базе данных (смотря, что и как пишем). Это не объект.
2) Нет. Если бы нанесение повреждений ракетой было в момент выстрела, создавать объект Ракета бы не потребовалось. Смысл именно в том, что создан объект Ракета, он обрабатывает Tick (перемещение за 1 тик игрового времени — если ракета не самонаводящаяся, то эта обработка выполнится стандартным методом родительского объекта), и Explosion — взорваться. И только в момент взрыва будет нанесено повреждение тем существам (включая и монстров и игроков), которые были рядом.
Задача была — сделать вариант записи единственным.
Если вы умеете через резистор R пропускать ток силой I, не прикладывая напряжение, то да, в результате этого оно возникнет конечно… Наверно, так можно описать динамо-машину.
Ну, я так, собственно, и делаю…
3. перенос части наиболее типового функционала в БД
Это делают, но медленно. Я не архитектор системы.