Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Albatros, Вы писали:
A>>Здравствуйте, gandjustas, Вы писали:
G>>>1)Все что написано очень мало относится к типам данных. Скорее получилось введение в делфи с кучей непонятных слов. G>>>2)Старшеклассники не знают множеств (это уже вышка, которую дают в универе), как объяснить типы не через множества — G>>>3)Классическая ошибка для пейсателей статей по программированию: попытка объяснить ООП "на пальцах" с примерами типа наследования четырехугольника от многоугольника. В реальной разработке применение ООП на порядок сложнее, а вы пытаетесь учить неправильному.
A>>>>В частности в полной 3-й главе предлагается ввести еще один вид сущностей, призванный закрыть один недостаток в ООП (либо использовать как архитектурный шаблон). G>>>Не думаю что сферические старшеклассники осилят.
A>>>>С формочек начинал чтобы учились сразу работать с РАД системами.Там форма — только средство написания оконной программы, акцентирование идет на математике. G>>>На это уходит немалая часть объема. С консолькой, а лучше с каким-нить repl, можно было бы упростить себе жизнь.
A>>1. Это предмет обсуждения фиксируется. Невозможно типы данных описать без того, где они используются. Я же писал, что это неполный вариант. Полную 3-ю главу буду оформлять как статью. Пишу 4-ю главу про БД. A>>2. Можно и так, если сложно написано: тип данных "целые числа" включает в себя, например, значения ...,-3, -2, -1, 0, 1,... Усё A>>3. ООП я знакю что такое, разработал библиотеку визуальных компонентов Delphi(порядка 70 модулей по 1..30 классов в каждом)
G>1)Обсуждения как такового нет. Про типы сказано мало и не по теме. Вообще слабовата система типов в делфи, чтобы о типах в этом контексте говорить. G>2)Компьютерная арифметика нереально сложна для того чтобы описывать типы, например сколько будет 2000000000+2000000000? Если говорить о целочесленных типах как о диапазонах, то тоже плохо получается. Например int-2^31..2^31), (+): (int,int) -> ? какой тип на выходе? По логике (-2^32..2^32), но почему то делфи и другие языки с этим несогласны. G>Вообще у Кнута немалая часть книги посвящена компьютерной арифметике.
A>>Хорошо, если ООП описано неправильно, то что там неверно более конкретно? G>Примеры неадекватны.
Адекватность примеров — мое решение. Это сугубо личный вопрос автора работы. Замечание не принято в виду не меньшей неадекватности, по-моему конечно мнению
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, batu, Вы писали:
B>Здравствуйте, Albatros, Вы писали:
B>>>И вообще, я не понял о чем тут речь. И причем тут типы?
A>>1. Значения, как и объекты, равные себе только одни. Город Москва — он один, число 7 — тоже одно. Это значения, как и объекты. B>Имеем объект "Служащий". Меняем ему зарплату. Объект остался тот же. Имеем Дату. Меняем месяц. Значение изменилось. Кроме того таких же дат (равных) может хранится в памяти сколько угодно. Однако объект "Служащий" может быть только один и равен только самому себе. A>>2. Это практически определение из ГОСТ. B>Хреновое определение. A>>3. Не понял замечания. Для неформальной фиксации предмета обсуждения считаю моего определения достаточно. B>Увы, что я могу еще сказать.. A>>4. А для ООП, там нет переменных-указателейна объекты?? Бертрана Мейера не читали случаем, разработчика Эйфеля? B>И его читал.. А еще и функциональные языки (хаскель и лисп) и логические (пролог). Займись. Там не совсем так с переменными..
1. Не путайте пожалуйста значение с состоянием объекта
2. ГОСТ — Государственный Общепризнанный СТандарт. Там хреново не может быть
3. Увы не можете
4. Данные парадигмы не являются целью работы. Рассматриваются востребованные бизнесом задачи. Все в одно не возможно засунуть, особенно ООП в логическое и функциональное программирование
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>>>Хорошо, если ООП описано неправильно, то что там неверно более конкретно? G>>Примеры неадекватны. A>Адекватность примеров — мое решение. Это сугубо личный вопрос автора работы.
Ну если сам не понимаешь, тогда давай по порядку:
1)Наследование многоугольников — классический пример нарушения LSP
2)При проектировании классов всегда надо начинать с задач, которые ими решаются.
Здравствуйте, gandjustas, Вы писали:
G>Ну если сам не понимаешь, тогда давай по порядку: G>1)Наследование многоугольников — классический пример нарушения LSP G>2)При проектировании классов всегда надо начинать с задач, которые ими решаются.
G>ЗЫ. Про определения уже сказали.
Определения в работе — это не формальный язык. Формальные кто написал именно, у кого содрать?
1. Если не трудно, что такое LSP?
2. Это не учебник по ООП. Хотя там написано, что такое АТД и шаблоны проектирования, архитектурные классы и классы прикладной области. Замечание некорректно, еще раз повторяю.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
1. Значения бывают и вне переменных.
2. Класс — это шаблон объекта, набор метаданных.
3. Букварный случай нарушения LSP в ООП.
Спасибо за развернутый ответ. 2 допишу, как альтернативное определение, мне понравилось. 1 тоже допишу. По 3 не понятно, что такое LSP. C остальным я не согласен, объяснение ниже.
1. Несерьезно, особенно о минимизации трудозатрат.
Некачественное ПО ведет к увеличению трудозатрат. Работа расчитана на тех, кто планирует в бизнесе работать, поэтому в ней товлько востребованные бизнесом рассматриваются методологии и советы.
2. Где композиция?
Агрегация и композицият для мпеня синонимы в языках дельфи, экшен скрипт 3.0 и с#.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
G>>Ну если сам не понимаешь, тогда давай по порядку: G>>1)Наследование многоугольников — классический пример нарушения LSP G>>2)При проектировании классов всегда надо начинать с задач, которые ими решаются.
G>>ЗЫ. Про определения уже сказали.
A>Определения в работе — это не формальный язык. Формальные кто написал именно, у кого содрать? A>1. Если не трудно, что такое LSP?
Liskpv Substitution Principle, гугл поможет.
Вкратце так: наследник должен полностью реализовывать контракт предка.
Во попробуй придумать такой контракт для многоугольника, чтобы четырехугольник его не нарушил.
Даже если придумаешь, то вряд ли он встретится в реальной задаче. А уж тем более в автоматизации бизнеса.
A>2. Это не учебник по ООП.
Неважно. Если ты пишешь определения и примеры, то они должны быть адекватны, а не просто такие как тебе нравится.
A>Хотя там написано, что такое АТД и шаблоны проектирования, архитектурные классы и классы прикладной области.
Угу, а называется творение "типы данных в программировании".
A>Замечание некорректно, еще раз повторяю.
Не надо повторять, надо обосновывать.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, samius, Вы писали:
A>Спасибо за развернутый ответ. 2 допишу, как альтернативное определение, мне понравилось. 1 тоже допишу. По 3 не понятно, что такое LSP. C остальным я не согласен, объяснение ниже. http://en.wikipedia.org/wiki/Liskov_substitution_principle
A>1. Несерьезно, особенно о минимизации трудозатрат. A>Некачественное ПО ведет к увеличению трудозатрат. Работа расчитана на тех, кто планирует в бизнесе работать, поэтому в ней товлько востребованные бизнесом рассматриваются методологии и советы.
Качество ПО это степень соответствия требованиям. Это формальное определение. Отсюда вытекает что неважно кто его делал и сколько убил ресурсов.
A>2. Где композиция? A>Агрегация и композицият для мпеня синонимы в языках дельфи, экшен скрипт 3.0 и с#.
Агрегация — это композиция без владения. Надо их отличать.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, batu, Вы писали:
B>>Здравствуйте, Albatros, Вы писали:
B>>>>И вообще, я не понял о чем тут речь. И причем тут типы?
A>>>1. Значения, как и объекты, равные себе только одни. Город Москва — он один, число 7 — тоже одно. Это значения, как и объекты. B>>Имеем объект "Служащий". Меняем ему зарплату. Объект остался тот же. Имеем Дату. Меняем месяц. Значение изменилось. Кроме того таких же дат (равных) может хранится в памяти сколько угодно. Однако объект "Служащий" может быть только один и равен только самому себе. A>>>2. Это практически определение из ГОСТ. B>>Хреновое определение. A>>>3. Не понял замечания. Для неформальной фиксации предмета обсуждения считаю моего определения достаточно. B>>Увы, что я могу еще сказать.. A>>>4. А для ООП, там нет переменных-указателейна объекты?? Бертрана Мейера не читали случаем, разработчика Эйфеля? B>>И его читал.. А еще и функциональные языки (хаскель и лисп) и логические (пролог). Займись. Там не совсем так с переменными.. A>1. Не путайте пожалуйста значение с состоянием объекта A>2. ГОСТ — Государственный Общепризнанный СТандарт. Там хреново не может быть A>3. Увы не можете A>4. Данные парадигмы не являются целью работы. Рассматриваются востребованные бизнесом задачи. Все в одно не возможно засунуть, особенно ООП в логическое и функциональное программирование
Та все без разницы.. Типа личные заблуждения.. Но, вот за цель работы я спрашивал.. Так и не понял.
1. Вкратце так: наследник должен полностью реализовывать контракт предка.
Во попробуй придумать такой контракт для многоугольника, чтобы четырехугольник его не нарушил.
Даже если придумаешь, то вряд ли он встретится в реальной задаче. А уж тем более в автоматизации бизнеса.
2. Не надо повторять, надо обосновывать.
По первому пункту Кодд(с элипсами и окружностями( 800 страница) с вами не согласен . В моей же работе написано: уточнение ограничений, специализация, выделение подмножества из множества путем наложения дополнительных ограничений — все это декларативная часть наследования, специализирующая. Все просто: наследование — древовидная иерархия. Одной из особенностей древовидной иерархии является то, что листов больше, чем корней. Это достигается разбиением на подмножества дополнительными ограничениями. Т.е. контракт в нашем случае простой: многоугольник — геометрическая замкнутая фигура, обладающая, к примеру, числом вершин и периметром. Что из этого невозможно гарантировать в четырехугольнике? В треугольнике? Или с ними, может, нельзя работать как с такими многоугольниками?
2. Обосновал в предыдущем посте. Математикой это не обосновать. Удачи!
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
1. Качество ПО это степень соответствия требованиям. Это формальное определение. Отсюда вытекает что неважно кто его делал и сколько убил ресурсов.
2. Агрегация — это композиция без владения. Надо их отличать.
1. Формализовано кем? Это противоречивое определение. А качество качества требований кто формализовал? Требования только часть качества ПО, но не все, далеко не все. Это проектирование по контракту тут расписываете, ОДНОГО ИЗ способов достижения качества. Качество не есть мера оценки соответствия требованиям. Обънективно говоря да, для ГОСТ. Для Agile подходов — нет.
2. Это не понятие ООП, это понятие UML. Да, языка для описания задач в терминах ООП, но он обладает избыточностью над ООП. Например такие сущности как n-aрные ассоциации в ООП отсутствуют, или варианты использования. Некорректное замечание.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Та все без разницы.. Типа личные заблуждения.. Но, вот за цель работы я спрашивал.. Так и не понял.
Все просто: цель указана на первой странице работы — систематизировать свои знания. Только и всего. Может быть полезна другим читателям. Писалась неформальным языком, т.к. где формальное определение я найти не могу. Одного автора, который был бы признан всеми я найти так и не смог. Стандартов море. Писал с ориентиром на племянника, точнее на его будущую учебу в старших классах, т.е. старался не подниматься выше уровня знаний старшеклассника, интересующегося программированием. Хотел дать советы и показать важность акцентирования внимания на типах данных, т.к. по роду работы постоянно сталкиваюсь с тем, что многие прогеры не могут толком ск4азать, что это такое и с чем едят. Собственно все по целям.
Есть другая версия 3-й главы, спорная. Поэтому планирую сюда статью написать. В дальнейшем планирую развить работу на книгу, в которой красной нитью пройдет понятие типа данных через все главы(9 штук планируется). Будут предложены после анализа доработки призванные некоторые моменты улучшить по моему мнению.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали:
A>1. Вкратце так: наследник должен полностью реализовывать контракт предка. A>Во попробуй придумать такой контракт для многоугольника, чтобы четырехугольник его не нарушил. A>Даже если придумаешь, то вряд ли он встретится в реальной задаче. А уж тем более в автоматизации бизнеса.
A>2. Не надо повторять, надо обосновывать.
A>По первому пункту Кодд(с элипсами и окружностями( 800 страница) с вами не согласен . В моей же работе написано: уточнение ограничений, специализация, выделение подмножества из множества путем наложения дополнительных ограничений — все это декларативная часть наследования, специализирующая.
Выделенное — нарушение LSP.
Нельзя делать предусловия в наследниках более сильными, чем в предке.
Например есть метод A.X(int x), предусловие на этот метод x>0, наследник B переопределяет метод X, и усиливает предусловие до x>1.
Любой код, который пользуется объектом типа A, может получить инстанс B и не будет выполнять контракт в случае вызова X(1).
A>Все просто: наследование — древовидная иерархия. Одной из особенностей древовидной иерархии является то, что листов больше, чем корней. Это достигается разбиением на подмножества дополнительными ограничениями.
Как уже показал выше — далеко не все "дополнительные ограничения" будут корректными.
A>Т.е. контракт в нашем случае простой: многоугольник — геометрическая замкнутая фигура, обладающая, к примеру, числом вершин и периметром. Что из этого невозможно гарантировать в четырехугольнике? В треугольнике? Или с ними, может, нельзя работать как с такими многоугольниками?
То есть ты хочешь сказать что все "поведение" будет заключаться в том что "фигура" будет отдавать свои "вершины".
А зачем тогда сами классы фигур? Можно же оперировать наборами вершин и все, совершенно нет необходимости создавать иерархии. В худшем случае будет интерфейс фигуры, но не базовый класс.
Причем такое гораздо правильнее в плане реализации. Представим что мы сделали класс "фигура" для начала с одним методом "посчитать периметр", от него унаследовали множество конкретных фигур, каждой определив периметр.
Потом нам понадобилось считать площадь фигур, значит добавили в каждый класс по методу.
Потом захотели искать центр фигуры, а его можно найти не для каждой фигуры, но тем не менее надо реализовать метод для всех наследников...
итд.
A>2. Обосновал в предыдущем посте. Математикой это не обосновать. Удачи!
"Потому что я так хочу" обоснованием не является.
Как я показал выше в реальном случае ООП получается сложнее чем в детских примерах, поэтому лучше не заниматься такой писаниной и выдумывать другие примеры, особенно если уж о типах заговорил.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, samius, Вы писали:
A>1. Качество ПО это степень соответствия требованиям. Это формальное определение. Отсюда вытекает что неважно кто его делал и сколько убил ресурсов.
A>2. Агрегация — это композиция без владения. Надо их отличать.
A>1. Формализовано кем?
например, ISO A>Это противоречивое определение. А качество качества требований кто формализовал? Требования только часть качества ПО, но не все, далеко не все. Это проектирование по контракту тут расписываете, ОДНОГО ИЗ способов достижения качества. Качество не есть мера оценки соответствия требованиям. Обънективно говоря да, для ГОСТ. Для Agile подходов — нет.
Откуда ваше определение? У меня есть основания полагать что это самодеятельность.
A>2. Это не понятие ООП, это понятие UML. Да, языка для описания задач в терминах ООП, но он обладает избыточностью над ООП. Например такие сущности как n-aрные ассоциации в ООП отсутствуют, или варианты использования. Некорректное замечание.
Я думаю что такие утвреждения нуждаются в доказательствах.
Вообще говоря UML появился в 90-х. А к этому моменту композиция существовала во многих языках, в том числе и в ООЯ.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, batu, Вы писали:
A>Та все без разницы.. Типа личные заблуждения.. Но, вот за цель работы я спрашивал.. Так и не понял.
A>Все просто: цель указана на первой странице работы — систематизировать свои знания. Только и всего. Может быть полезна другим читателям. Писалась неформальным языком, т.к. где формальное определение я найти не могу. Одного автора, который был бы признан всеми я найти так и не смог. Стандартов море. Писал с ориентиром на племянника, точнее на его будущую учебу в старших классах, т.е. старался не подниматься выше уровня знаний старшеклассника, интересующегося программированием. Хотел дать советы и показать важность акцентирования внимания на типах данных, т.к. по роду работы постоянно сталкиваюсь с тем, что многие прогеры не могут толком ск4азать, что это такое и с чем едят. Собственно все по целям. A>Есть другая версия 3-й главы, спорная. Поэтому планирую сюда статью написать. В дальнейшем планирую развить работу на книгу, в которой красной нитью пройдет понятие типа данных через все главы(9 штук планируется). Будут предложены после анализа доработки призванные некоторые моменты улучшить по моему мнению.
Достойная цель. Только для этого надо самому четко представлять предмет. Не уверен что надо было с типов начинать... Но и машина тьюринга сложновато.. А, действительно! Систематизировать свои знания это хорошая идея..Надо много читать.
1. Нельзя делать предусловия в наследниках более сильными, чем в предке.
2. Например есть метод A.X(int x), предусловие на этот метод x>0, наследник B переопределяет метод X, и усиливает предусловие до x>1.
Любой код, который пользуется объектом типа A, может получить инстанс B и не будет выполнять контракт в случае вызова X(1).
3. Как уже показал выше — далеко не все "дополнительные ограничения" будут корректными.
4. То есть ты хочешь сказать что все "поведение" будет заключаться в том что "фигура" будет отдавать свои "вершины".
А зачем тогда сами классы фигур? Можно же оперировать наборами вершин и все, совершенно нет необходимости создавать иерархии. В худшем случае будет интерфейс фигуры, но не базовый класс.
5. Причем такое гораздо правильнее в плане реализации. Представим что мы сделали класс "фигура" для начала с одним методом "посчитать периметр", от него унаследовали множество конкретных фигур, каждой определив периметр. G>Потом нам понадобилось считать площадь фигур, значит добавили в каждый класс по методу. G>Потом захотели искать центр фигуры, а его можно найти не для каждой фигуры, но тем не менее надо реализовать метод для всех наследников... G>итд.
6. G>"Потому что я так хочу" обоснованием не является.
7. G>Как я показал выше в реальном случае ООП получается сложнее чем в детских примерах, поэтому лучше не заниматься такой писаниной и выдумывать другие примеры, особенно если уж о типах заговорил.
Начну с конца.
7. Я уже говорил, что написал РАБОЧУЮ библиотеку на дельфях, состоящую из 1050 классов. Без понимания ООП она бы не заработала. Она работает, это не детский пример. Там собственный SQL парсер, правка исходников при проектировании, контейнера других компонентов, мастер дельфи, шаблоны визуальных компонентов, стандартные формы фильтрациЙ(разные варианты для отношений "много ко многим"(соединения))и поиска через правки запросов и т.д. и т.п. Пример в книге — очень хороший пример из практики.
Поясню, почему я считаю его хорошим. Мы наверное говорим об одном и том же, только вот в " более строгие" ограничения вкладываем разные понятия. Есть множество геометрических фигур. Есть подмножества четырехугольников и квадратов. Тогда наследование(как иерархический мех-м повторного использования и построения таксономии) будет: многоугольник(имеет углы, замкнутая фигура(т.е. имеет площадь) и периметр). У четырехугольника 4 угла, остальное все тоже. У квадрата прямые углы и стороны равны. Расчет площади может быть у многоугольника абстрактным методом. Тогда четырехугольник может уже вносить реализацию. Квадрат выделять подмножество путем наложения ограничения, что углы прямые. При этом, контракты на наличие вообще углов у многоугольника и 4-х углов у четырехугольника не нарушаются. Вообще хорошая таксономия классов та, у которой суперкласс(самый верхний в иерархии)является абстрактным(работа "Паттерны проектирования" банды четырех. У них вообще лучшее проектирование — это проектирование в терминах интерфейсов).
6. Не является, так же, как и говорить что "не обоснованно" — не является правом до бесконечности задавать один и тот же вопрос.
1-5. Суммарный ответ в ответе на 7.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>Начну с конца. A>7. Я уже говорил, что написал РАБОЧУЮ библиотеку на дельфях, состоящую из 1050 классов.
А почему не 100500 (стопиццот). Не удержался.
A>Без понимания ООП она бы не заработала. Она работает, это не детский пример. Там собственный SQL парсер, правка исходников при проектировании, контейнера других компонентов, мастер дельфи, шаблоны визуальных компонентов, стандартные формы фильтрациЙ(разные варианты для отношений "много ко многим"(соединения))и поиска через правки запросов и т.д. и т.п. Пример в книге — очень хороший пример из практики.
Да я не сомневаюсь в библиотеке. Я сомневаюсь в том что написано в статье. Это наивное объяснение ООП скорее пойдет во вред, чем на пользу. Особенно старшеклассникам. При этом довольно далеко от заявленной темы.
A>Поясню, почему я считаю его хорошим. Мы наверное говорим об одном и том же, только вот в " более строгие" ограничения вкладываем разные понятия. Есть множество геометрических фигур. Есть подмножества четырехугольников и квадратов. Тогда наследование(как иерархический мех-м повторного использования и построения таксономии) будет: многоугольник(имеет углы, замкнутая фигура(т.е. имеет площадь) и периметр). У четырехугольника 4 угла, остальное все тоже. У квадрата прямые углы и стороны равны. Расчет площади может быть у многоугольника абстрактным методом. Тогда четырехугольник может уже вносить реализацию. Квадрат выделять подмножество путем наложения ограничения, что углы прямые. При этом, контракты на наличие вообще углов у многоугольника и 4-х углов у четырехугольника не нарушаются.
Здравствуйте, gandjustas, Вы писали: G>Это слова. В коде как оно будет выражаться?
TFigure = class abstract
private
function GetChisloUglov(): integer; abstract;
function GetPerimetr(): real; abstract;
public
property ChisloUglov: integer read GetChisloUglov;
property Perimetr: real read GetPerimetr;
ploshad
end;
TPriamougolnik = class(TFigure)
private
FStoronaA: real;
FStoronaB: real;
function GetChisloUglov(): integer; override;
function GetPerimetr(): real; override;
public
property StoronaA: real read GetStoronaA;
property StoronaB: real read GetStoronaB;
end;
function TPriamougolnik.GetChisloUglov(): integer;
begin
Result := 4;
end;
function TPriamougolnik.GetPerimetr(): real;
begin
Result := (StoronaA + StoronaB) * 2;
end;
function TestPerimetrOnFigure();
var
Figure: TFigure;
begin
Figure := TPriamougolnik.Create();
Result := Figure.Perimetr;
end;
Собственно так.
Являясь Вечным Двигателем, Они приветствуют нашу наивность в попытках Его изобрести.
Здравствуйте, Albatros, Вы писали:
A>Здравствуйте, gandjustas, Вы писали: G>>Это слова. В коде как оно будет выражаться?
A>
A>TFigure = class abstract
A>private
A> function GetChisloUglov(): integer; abstract;
A> function GetPerimetr(): real; abstract;
A>public
A> property ChisloUglov: integer read GetChisloUglov;
A> property Perimetr: real read GetPerimetr;
A>ploshad
A>end;
A>TPriamougolnik = class(TFigure)
A>private
A> FStoronaA: real;
A> FStoronaB: real;
A> function GetChisloUglov(): integer; override;
A> function GetPerimetr(): real; override;
A>public
A> property StoronaA: real read GetStoronaA;
A> property StoronaB: real read GetStoronaB;
A>end;
A>function TPriamougolnik.GetChisloUglov(): integer;
A>begin
A> Result := 4;
A>end;
A>function TPriamougolnik.GetPerimetr(): real;
A>begin
A> Result := (StoronaA + StoronaB) * 2;
A>end;
A>function TestPerimetrOnFigure();
A>var
A> Figure: TFigure;
A>begin
A> Figure := TPriamougolnik.Create();
A> Result := Figure.Perimetr;
A>end;
A>
-2^31..2^31), (+): (int,int) -> ? какой тип на выходе? По логике (-2^32..2^32), но почему то делфи и другие языки с этим несогласны.
