Re[30]: Тип данных в программировании. - Философия программирования

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, VladD2, Вы писали:

VD>>Здравствуйте, Albatros, Вы писали:

A>>>Для меня все просто: Композиция(агрегация) — механизм повторного использования типов, построения иерархии типов. Делегирование — механизм позднего связывания функционала. Это как наследование и виртуальные методы, только имеет большую гибкость, так как работает на этапе выполнения. Наследование же с вирт методами на этапе компиляции работает.

VD>>А вы в курсе, что наследование необязательно для полиморфизма подтипов?
VD>>В курсе, что есть структурные системы типов (большая часть языков семейства ML) в которых понятие подтипа определяется без наследования (по совпадению структуры типов)?
VD>>Вы хоть знаете какой системой типов обладает Делфьи?

A>Вы тут чушь полную написали.

Такие высказывания необходимо обосновывать. Голословные утверждения — известный всем признак необразованности. (c)

A>Особенно про образование, то была ирония. Чувство юмора смотрю не всем еще доступно.

Ирония — это когда смешно не только автору слов, но и окружающим. У вас какое-то уникальное чувство юмора.

A>Я, например, еще и в информационном центре МГУ успел поработать.

Тем печальнее для МГУ.
И вообще, как-то не к лицу человеку причисляющему себя к учителям мериться пиписьками. Здесь (на REDN) вас будут оценивать исключительно по тому, что вы говорите. И пока что с каждым словом вы себя дискредитируете.

A>Как вы думаете, где в стране есть MDA + RUP???

Кое-где видел, но не вижу связи между методологиями и типами данных в ЯП.
Видимо это еще одна неумелая попытка продемонстрировать длину своего пениса.

A>А там ведь delphi используется.

То есть вы на полном серьезе считаете, что эти методологии были разработаны для Дельфи?

A>Включи свой мозг и не хами учителю!

Да, что вы, уважаемый? Здесь пока что хамите только вы. Но в моих принципах разговаривать с людьми так как они этого заслуживают. Так что не взыщите за симметричность ответов.

A>Есть наследование когда наследник является подтипом, а есть когда нет.

Несомненно, уважаемый Капитан Очевидность! Как минимум существует private-наследование в C++. Вот только такое наследование не имеет никакого отношения к подтипам. Подтипы определяются исключительно наследованием интерфейса (публичной части классов и интерфейсов в тех языках где они поддерживаются явно).

Так же как несомненно, что можно иметь подтипы вообще без наследования. Но похоже вы об этом раньше не догадывались.

A>При этом есть языки, которые это(наследник является еще и подтипом) гарантируют, а есть — нет.

Правильно ли я понял эту фразу, что есть языки поддерживающие наследование, но при этом не предоставляющие идеологии подтипов? Можно привести примеры таких языков?

Или тут речь идет о том, что есть языки с private-наследование вроде C++?

A> То, что вы привели — это подтипы с гарантией.

Я привел? Это вы про ссылку на структурные системы типов? Если да, то вынужден вас огорчить. Такие системы типов вообще не нуждаются в наследовании. Вы знакомы с таким языком как Go (гуглевый)? Там нет наследования, но есть подтипы.

A>Вопрос в реализации.

Еще раз вынужден вас огорчить. Этот вопрос никак не связан с реализацией. Их может быть множество.

A>Класс хранит указатель — это наследование в вашем понятии, всерка классов по совпадению — это тогда что? Есть проверка равенства по указателям, а есть по значениям.

У вас каша в голове. Видимо она вызвана тем, что вы видели только одну реализацию. На самом деле реализаций может быть много. А следовательно важно выделять абстракции.

Поймите, как раз подтипы — это наиболее важная абстракция при разговоре о системах типов. А наследование — это всего лишь средство. Есть языки вообще без наследования и они даже в чем-то удобнее чем языки с жестким наследованием. Возьмите к примеру JavaScript, Go или Haskell. Последний даже не поддерживает ООП, но тем не менее обладает системой типов которой может позавидовать (с точки зрения мощности) любой ООЯ.

A>Не наводит не накие мысли???

Наводит. На на печальные. Вы не просто решили заняться разделом науки о котором имеете однобокое представление, но вы еще и отстаиваете свои заблуждения. В народе таких называют воинствующих ламер.

A>То, что где-то что-то заменили не является обоснованием правильности терминологии.

Неплохая мысль. Задумайтесь над этим.

A>С вашим подходом(на каждое определение у меня свой язык программирования)далеко не уедите.

Полноте. Подходов у меня нет. Я просто, в отличии от вас, удосужился ознакомиться с современной теорией и немного позанимался компиляторостроением на практике, т.е. имеют реальный практический опыт.

Тезиса "на каждое определение у меня свой язык программирования" я не выдвигал. Так то не стоит развивать эту тему.

A>Это невежество и пустозвонство.

Да, согласен. Это именно те слова которые приходят на ум многих читающих ваши слова. Только ваше непонимание предмета разговора не позволяет вам понять как сильно вы дискредитируете себя своими неосторожно разбрасываемыми высказываниями.

A>Для справки, многие учителя на INTUIT признают эйфель лучшим ООП языком.

Спасибо, но мне эта справка не требуется. Даже если ваше голословное утверждение и верно, оно никак не связано с обсуждаемым вопросом — типами данных в программировании.

A>Автор же вывел 11! СПОСОБОВ НАСЛЕДОВАИЯ. Автор первый лауреат премии консорциума ООП.

Под автором вы имеете в виду Бертрана Мейера?

Простите, но его заслуги на вас не распространяются. Скажу больше, заслуги вообще не являются аргументом в споре.

A>Из этой работы растут ноги у С#.

У него ноги много откуда растут. Главным образом, правда из Явы. Но какое это отношение к вопросу?

A>Для тех кто в теме C# кажется плагиатом, не более.

Те кто в теме знают, что в ЯП редко появляются совсем уж новые концепции. Языки в которых появлялись новые концепции можно пересчитать по пальцам. В том же Eiffel с точки зрения системы типов не появилось ровным счетом ничего нового. Единственная заслуга автора языка — это введение идеологии контрактного программирования.

A>Там все повторяется(на момент версии 3.5).

Конечно же не все, так же как не все в Эфиле является повторением того что было до него (Simula, С++). Но конечно же концепции заложенные в Simula в том или ином виде присутствуют в любом языке который можно называть объектно-ориентированным.

A>Для меня дельфа и сишарп — фавориты на рынке бизнес-приложений, поэтому то, что принято в них используется в качестве примеров и название я сменю только на "Тип данных и программирование", не более...

Ну, Дельфи на сегодня уже не фаворит. А кроме шарпа есть и более распространенные языки (Ява), но я не против примеров на Делфьи. Это не лучший выбор, но и не худший.

Проблема в вашей статье не в том, что там используется Дельфи для объяснения тех или иных концепций, а в том, что вы не верно понимаете некоторые концепции которые пытаетесь объяснять (например, интерфейсы), а о некоторых вообще не имеете никакого представления (например, о системах типов отличных от номинальной). Ваша статья на сегодня это не статья о типах данных в программировании. А статья о типах данных в Дельфи. Причем качество материала мягко говоря не очень высокое.

Посему я вам и говорю, что или разберитесь в теме (как следует), или добавьте в название слово Delphi.

Здравствуйте, deniok, Вы писали:

d> H>Наследование интерфейса произойдет, если класс будет унаследован от предка реализующего интерфейс. Реализация интерфейса может быть нескольких видов, когда класс сам реализует контракт, когда наследует реализацию (реализация наследованием), когда использует механизмы агрегации и делегирования. Очевидно по моему

d> Мне не очевидно. Я не вижу, чем понятие интерфейса отличается от понятия базового класса (с некоторыми требованиями к его уровню абстрактности) + разрешения делать множественное наследование от таких базовых классов. Собственно оно (понятие интерфейса) оттуда и возникло.

Я уже писал об этом:

Абстрактный класс и интерфейс это далеко не одно и то же. Абстрактный класс может являться одним из ранних предков в иерархии, а интерфейс это просто контракт, который можно исполнить. То есть, реализация интерфейса вообще ни как не связана с наследованием, в отличии от абстрактного класса.

Если уж совсем просто, то от абстрактного класса можно наследоваться, а от интерфейса нельзя. Тот факт, что в C++ интерфейс и абстрактный класс есть одно и тоже — сути не меняет. Это особенности реализации.

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, Albatros, Вы писали:

A>Полиморфизм — полиповедение, разное поведение, т.е. разная реализация одного и того же метода.

Наверное стоит начать отсюда

Или отсюда

Здравствуйте, Sinclair, Вы писали:

S>Простите, но ваш вот этот пост — просто поток сознания.
S>Для начала переключите просмотр форумов в древовидный режим.
S>Затем всё же прислушайтесь к тому, что вам тут пишут. Вы многое понимаете правильно, пусть и на интуитивном уровне. Но изобретение собственной терминологии мешает вам двигаться дальше, т.к. вы перестаёте воспринимать накопленный ранее опыт.
S>Критика дельфи, которая вас так задевает, в основном звучит от людей, которые на этом дельфи отработали в полный рост. Они право критиковать ранних детей Хейльсберга заслужили.

Разработав САПР на дельфи и переделав сервер форм IfoPath в SharePoint я пришел к простому выводу: ООП лидирующая методология на рынке, то знание ее, которое у меня есть, позволяет мне решать сложнейшие задачи. Например библиотека компонентов, которую я написал, представляет собой во многом набор компонентов-контейнеров других компонентов. А эта задача, по мнению Марко Кэнту, сложнейшая при написании кода и в его книгах даже не рассматривалась, как собственно и у Пачеку. Мой опыт — мое признание, как ни крути.

Здравствуйте, samius, Вы писали:

S>http://stackoverflow.com/questions/1334451/history-of-public-private-protected
Ещё раз: концепция публичности/приватности появилась в Паскале в незапамятные времена. Тогда это называлось Модульное программирование, и было сильно лучше, чем голый C с его глобальной видимостью процедур.
Границей видимости был модуль, с его interface/implementation секциями.
Всё, что внутри implementation, видело друг друга.
Поэтому отражение той же реальности в ООП, привнесённом в готовый язык, было полностью логичным. Тем более, что стояла задача сделать OOP максимально простым — без пяти уровней доступа, модификаторов friend и прочего стуффа. Это же учебный язык.

И вообще, не существует какого-то единого "православного" способа готовить access modifiers. Их существование определяется необходимостью и возможностью. Возможность — это вычислимость предиката доступности в момент биндинга. В модели С++ не так уж много способов вычислить, в каких отношениях находится текущий компилируемый кусок кода к использованным им компонентам класса. К примеру, нет поддержки "модулей" с несколькими классами — а с ней и возможностей провести по ним границу доступа.
Необходимость — это практический смысл. Даже самый базовый public/private позволяет предотвратить ненамеренную ошибку потребителя кода завязаться на то, что ты считаешь деталью реализации, или случайно сломать тебе инвариант.
protected позволяет публиковать разный уровень подробностей для потребителей и для наследников — если наследники предполагаются. Поэтому в COM, где нет наследования, нет никакого protected.

Здравствуйте, Albatros, Вы писали:

A>Термины — это фиксация предмета обсуждения.

Термины они нужны для чего-то, а ради самих себя. Вы же суете их без малейшей системы и следовательно смысла.
Нельзя излагать что-то от печки (т.е. рассчитывая на полное отсутствие знаний по предмету). Иначе вы начнете вводить "термины" для повседневных, общепринятых понятий и ваша работа превратится в некому не нужны сборник терминов.

A>Работа не полностью написана,

Мне кажется совершенно не важно дописана они или нет. Важно то, что она не отвечает задачам которые озвучены в ее названии.

A>есть 3-я глава где идет попытка достучаться, что необходимо вводить изменения в ООП.

Что само по себе весьма спорно. К тому же ООП это очень общий термин. В конце концов Смолток или ЖабаСкрип — это тоже ООП.

A>Пишется 4-я,

Я бы для начала разобрался с первой. Определился бы с целями работы и выкинул из нее все лишнее. В первую очередь формочки и не относящиеся к делу термины. Все термины давно описаны в инциклопедиях. Например, в Википедии, откуда вы, как я понимаю, и черпали определения. Ну, так не давайте ссылки на эти определения, если считаете, что читатель может быть с ними не знаком.

A>как взгляд на базы данных через типы данных.

Лет за 30 до вас это сделал Кодд. Вы хотите изложить его мысли в более доступной форме или у вас есть новая теория?

A>В примерах же идет акцентирование на типах данных.

В примерах ваших идут кнопки формы и простейшие мысли. Причем за кнопками уже этих простейших мыслей не разглядеть.

A> Работа — это не ввод в дельфи, эта работа задумывалась больше для старшеклассников,

"Работа не по Дельфи, а для старшеклассников" — это само по себе пример демонстрации алогичного мышления. Какая связь между тем о чем материал и на кого он рассчитан? Будь ваша работа рассчитана на докторов наук, она не перестала бы быть посвящена введению в дельфи.

A> сам я работал 3 года преподавателем программирования в МГТУ "СТАНКИН", поэтому могу что-то написать на эту тему.

На какую тему то? У вас получился рассказ на тему как сложить два числа с использованием формы Дельфи. К теории типов и типам это имеет очень отдаленное отношение.

Вам выше привели ссылку на классическую работу по теории типов. Единственная ее проблема — это сильная заформализованность. Очень советую прочесть ее и подумать как изложить тоже самое до менее формально (в расчете на тех самых старшеклассников, хотя им вряд ли это нужно... не тот уровень базовых знаний).

A> В частности в полной 3-й главе предлагается ввести еще один вид сущностей, призванный закрыть один недостаток в ООП (либо использовать как архитектурный шаблон). Как узнаю как можно права защитить, так сразу выложу.

Пока что это все выглядит как клоунада. Наивно полагать, что при столь поверхностном рассмотрении вопросов вы смогли сказать новое слово в науке.

Права ваши же защищаются законами нашей и других стран. По нашим законам авторское право всегда принадлежит автору. И уже на основании этого права автор может давать права на публикацию своих работ. Права на алгоритмы защитить нельзя. Права на изобретения регулируются патентами (но как я уже сказал запатентовать алгоритм невозможно).

Так что вам надо определиться с тем, что вы хотите добиться. Если первенства идей, то вам достаточно опубликовать эти идеи под своим именем первым. В принципе для этого достаточно публикации в Интернет. Если есть желание получить более официальный статус публикации, то нужно опубликоваться в одном из научных журналов (если конечно публикацию не зарежут), одним из которых является RSDN Magazine (т.е. журнал этого сайта).

A>Полную третью главу планирую оформить как статью, по вашим правилам.
A>С формочек начинал чтобы учились сразу работать с РАД системами.

Зачем? Те кто начинают с РАДостей часто ими и заканчивают. Для ваших задач нужен банальный консольный вывод. Если работа посвящена типам, то о них и надо в основном говорить. А все остальное должно быть не более чем неизбежным антуражем.

A>Там форма — только средство написания оконной программы, акцентирование идет на математике. Первый пример — раскрытие понятия тип данных. Второй — важность граммотного применения типов данных и заодно модульность в архитектуре ПО.

Ваш первый пример — арифметическое выражение находится на четвертой странице и при этом до него нет ничего связанного с типами. До этого едет попытка изложить все что нужно человеку для понимания компьютера. Только вот работа не называется "введение в информатику". А уж определения вроде "Прикладная область" вообще ни в какие ворота не лезут.

Если вы позиционируете работу на новичков, то вместо того чтобы пудрить им мозг терминами лучше сосредоточьтесь на толковом и доходчивом объяснении сути типов. При этом рассчитайте на то, что человек уже имеет хоть какие-то знания в информатике.

Но, на мой взгляд, серьезное рассмотрение типов для начинающих просто не имеет смысла. У них другие проблемы. Им бы понять смысл программирования и т.п. А типы они, как не странно, проглотят без проблем даже если их отдельно не объяснять. Я учился программировать на С. В С типы везде. Но это не привело к кому-то не пониманию.

A>Название "Тип данных в прикладном программировании" — это отражение того, что работа имеет более широкий вопрос рассмотрения, нежели чисто понятие типа данных. В работе даются советы при программировании задач, востребованных бизнесом. Работа не привязана к дельфям, на них только примеры.

Вы уж определитесь, или вы дате советы начинающим о том что им потребуется в бизнесе, или о типах данных при разработке программ. Для последнего нет никакой разницы пишется ли программа эмуляции физических процессов или бухгалтерия.

Ну, и хочется заметить, что бизнесу Дельфи уже вряд ли когда-то понадобится. Дельфи окончательно слила свои позиции. Сейчас ее место занял C# и VB, которые имеют ту же систему типов, что и Дельфи. В прочем, с точки зрения теории типов совершенно по барабану на чем излагать. В большинстве классических работ просто придумывается свой язык программирования, правда, обычно, он до боли похож на ML

. Но это понятно почему происходит. Эти работы исходят из типизированных лямбда-исчислений, а все что не вписывается в него прибивают сбоку гвоздями.

ЗЫ

В общем, очень советую вам отложить ваш материал на пару недель. Потом сесть, описать на листочке список целей излоежения и попробовать критически прочесть свой материал еще раз.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, samius, Вы писали:

S>>Здравствуйте, Albatros, Вы писали:

S>>З.Ы. Оверквотинг не приветствуется

A>В квоту будет помещаться только полная 3-я глава. Её оформлю как заявку на статью.
Я про избыточное цитирование других постов.

A>Эта работа — возможная будущая книга на тему типизации.
Без обид! уровень этой работы — реферат на вольную тему. Тема типизации не раскрыта.

Здравствуйте, Albatros, Вы писали:

A>Мне кажется, что все это бессмысленно, так как в каждом ООП языке свое ООП. Общая методолгия для меня совсем иное, нежели все сразу, что есть во всех языках. Скорее наборот — только то, что есть у большинства общепризнанных ООП языков. Общие черты, а не все в одном. Литературы море, в каждой свое ООП, стандарта нет. UML вообще иногда мозг взрывает, особенно как у Рембо с Блахой. Давайте прекратим бессмысленный спор. Для меня что-то между интерфейсом и классом имеющим реализацию методов называется классом. Наследование реализации == наследование классов, наследование декларации == наследованию интерфейсов. Как-то так.

Так может не стОит заморачиваться на ООП? Это ж не священная корова какая. Выкиньте Вы это ООП из статьи и сконцентрируйтесь на главном.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, samius, Вы писали:

s>> H>Не правильно. Не вопреки. Модуль это более крупная единица инкапсуляции нежели класс. Тебя же не смущает, что в C# вложенные классы имеют доступ к закрытым членам класса-владельца? Аналогично и с модулем, только свободы еще больше.

s>> Правильно, вопреки. В паскаль тащили ООП гораздо позже, чем устоялись термины.

s>> в C# такая свобода существует и называется internal, в java — package. А в делфи она называется тем словом, которым принято обозначать другой уровень видимости.

H>Это слово трактуется весьма широко.
Так широко оно трактуется только в делфи.

H>Еще раз напомню тебе, что в C# nested types имеют доступ к private членам класса владельца. У тебя диссонанса не случается от этого?
Нет.

s>> И логики в этом походу не больше, чем в том что List-ом в дотнет называют динамический массив.

H>List это абстракция. Детали реализации (list as dynamic array) это детали реализации. У нас ОПП или где?
Если чо, то ты назвал абстракцией класс, где нет ни одного виртуального метода.

Здравствуйте, VladD2, Вы писали:

VD> H>Сборки это не модули.

VD> С чего бы это?

По определению. Модуль относится к исходному коду, сборка к бинарному.

VD> H>С практической точки зрения связанность кода в рамках модуля допустима т.к. модуль укрупняет инкапсуляцию, а все что под капотом есть детали реализации. Публичные-то контракты от этого не страдают

VD> Укрупнение инкапсуляции — это очень смешно. Хорошее, полит-корректное название для нарушения инкапсуляции. Я не знаю как там обстоят дела с вашей "практической точки зрения", но если даже забыть про ООП и т.п., на практике есть такая штука как АТД. И возможность залезть в кишки АТД — это недостаток, а не преимущество.

А причем тут АТД?

VD> В языках где модули действительно используются по назначению (например, OCaml) АТД представляются именно модулями. В них модуль — это первоклассниц сущность.

Я очень рад за них. А кто тебе сказал, что концепция модулей может существовать только в твоем идеализированном осознании оной?

VD> В общем-то понятно зачем в Дельфи дали возможность залезать в кишки типов. Периодически бывает ситуация когда несколько типов должны быть очень тесно связаны (например, по соображениям производительности). Пакеты позволяет инкапсулировать такое залезание. Однако это никак не оправдывает столь странного имени модификатора доступа. А strict privat звучит просто смешно. "- Ворона, ворона сколько у тебя ножек? — Две! Особенно левая!!!".

Очень правильно звучит. Private допускает вольное трактование, Strict указывает на буквальное трактование

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, samius, Вы писали:

Надоело спорить.

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, Sinclair, Вы писали:

S>>Я лишь пытаюсь показать что обычно у этого модификатора другой смысл. Использовать private в делфи без оговорок в статьях, имеющих отношение к ООП — плохая идея.
S>(Вздыхает). То, что вы называете "oбычно" — продукт совсем другой эпохи. В 1989 никаких "обычно" ещё не было. В том же году в С++ добавили access modifier protected. В Simula никаких private не было.
S>А в наши дни, конечно же, использовать Delphi для примеров в статьях не про Delphi — неожиданно. Тем более при рассуждении о типизации — дельфийская система типов изобилует причудливыми странностями ничуть не меньше, чем древнеэльфийский у JRRT.

Мне дельфи нравится, очень, больше, чес C#. Я его знаю наизусть, у меня компоненты правили исходники во время проектирования программы. Поэтому примеры на дельфях. На .NET и C# легче писать проги, но он чисто ООП язык. А дельфи гибридный язык, сохраняет императивный синтаксис и процедурный подход в программировании. Не всЁ в жизни является объектами. Число 7 мне трудно представить как объект. Пример: сложить объект Семи с Объектом трех получим объект десяти!!! Что за чушь! Для инженерных прикладных задач ООП не годится. В полной 3 главе будет обоснование этого.

Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов. Наследования интерфейсов нет. Не путайте твердое с мягким.

Здравствуйте, Albatros, Вы писали:

S>>Интересно. С нетерпением жду узнать, что же годится для инженерных и прикладных задач.

A>В статье будет это разжевано. Уже есть текст. Как выложить с заявкой на публикацию не знаете?

Не обижайтесь, но вам явно рано писать статьи на тему типов данных. Добавьтве в название слово Delphi и многие претензии к вам предъявляться не будут.

Тема типов данных — это очень не простая научная тема. Описать ее просто и при этом правильно очень не просто.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Albatros, Вы писали:

A>>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов.
G>Это полная чушь. Берешь интерфейс IA с методом X и реализуешь его в 20 разных классах. Потом обращаешься к ссылке с типом IA — вот тебе полиморфизм.

A>>Наследования интерфейсов нет.

G>

G>intarface IA {}
G>intarface IB:IA {}
G>

A>>Не путайте твердое с мягким.
G>Ты полную чушь говоришь.

Вы смешали как раз твердое с мягким. Взяли и в наследовании класса указали, что он реализует интерфейс. Это стандартное ИСПОЛЬЗОВАНИЕ интерфейсов, НО НЕ НАСЛЕДОВАНИЕ ИНТЕРФЕЙСОВ ИНТЕРФЕЙСАМИ! У интерфейсов нет наследования, есть композиция. Если угодно, если мех-м хотим называть наследованием, то наследование у интерфейсов совсем другое, нежели у классов. Есть наследование деклараций(это интерфейсы), а есть наследование деклараций + реализаций(это уже у классов). Переопределение реализаций — это обеспечение полиморфизма, ИМЕННО РАЗНОЕ ПОВЕДЕНИЕ, за счет изменения существующих уже реализаций виртуальных методов. У интерфесов нет реализаций, поэтому сами по себе они полиморфизма в понятиях, как у классов, не поддерживают. Есть только использование интерфейса как типа данных, это можно назвать НЕОБЕСПЕЧЕННЫМ ПОЛИМОРФИЗМОМ. Неужели это трудно понять, имея столько приблудов сертификационных? Я, бывший препод программирования в МГТУ, и то могу это понять, без сертификатов. Мой опыт — вот единственная гарантия знаний, очередной раз убеждаюсь, что бумажки ничего не означают.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Albatros, Вы писали:

A>Вы смешали как раз твердое с мягким. Взяли и в наследовании класса указали, что он реализует интерфейс. Это стандартное ИСПОЛЬЗОВАНИЕ интерфейсов, НО НЕ НАСЛЕДОВАНИЕ ИНТЕРФЕЙСОВ ИНТЕРФЕЙСАМИ! У интерфейсов нет наследования, есть композиция.
http://en.wikipedia.org/wiki/Interface_inheritance

A>Если угодно, если мех-м хотим называть наследованием, то наследование у интерфейсов совсем другое, нежели у классов. Есть наследование деклараций(это интерфейсы), а есть наследование деклараций + реализаций(это уже у классов). Переопределение реализаций — это обеспечение полиморфизма, ИМЕННО РАЗНОЕ ПОВЕДЕНИЕ, за счет изменения существующих уже реализаций виртуальных методов. У интерфесов нет реализаций, поэтому сами по себе они полиморфизма в понятиях, как у классов, не поддерживают. Есть только использование интерфейса как типа данных, это можно назвать НЕОБЕСПЕЧЕННЫМ ПОЛИМОРФИЗМОМ.
По ссылке выше можно узнать и о полиморфизме интерфейса. Совершенно ни к чему выдумывать определения для давно названных вещей.

A>Неужели это трудно понять, имея столько приблудов сертификационных? Я, бывший препод программирования в МГТУ, и то могу это понять, без сертификатов. Мой опыт — вот единственная гарантия знаний, очередной раз убеждаюсь, что бумажки ничего не означают.
К сожалению лычка "бывшего препода программирования" не добавляет знаний и не свидетельствует о них.
Попытайтесь как-то свой опыт скореллировать с опытом более опытных коллег. Пока не было поводов считать что ваш опыт ценнее и лучше других вместе взятых.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Выше код показывает наследование интерфейсов. В спецификации языка C# можешь посмотреть, оно именно наследованием называется. Для COM тоже есть наследование интерфейсов, для java есть, опять-таки судя по спецификации.

G>>Композиция это вообще не то. Композиция это когда один код пользуется другим кодом для реализации своей функциональности.

A>Ну так это другое наследование, мы про разные вещи говорим! Обеспечением полиморфизма всегда были есть и будут виртуальные методы. Это тоже другой полиморфизм. Назвали и ладно, все равно
A>это разные вещи.
Поразительное упорство в невежестве после стольких ссылок

A>Это не композиция, это делигирование ты написал. А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код).
Еще одно выдуманное определение

A>Википедию почитай, подучись.
http://en.wikipedia.org/wiki/Object_composition
Советую обратить внимание на примеры, особенно на паскалевский.

Есть таки композиция кода — http://en.wikipedia.org/wiki/Function_composition_%28computer_science%29. Но речь явно не о ней.

Здравствуйте, Albatros, Вы писали:

A>Я, бывший препод программирования в МГТУ, и то могу это понять, без сертификатов.

Звучит как "преподы МГТУ слабоумные". Вообще, очень печатльно за наше образование. 20 лет назад мы были впереди планеты всех, а теперь преподаватели несут откровенную ересь.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Albatros, Вы писали:

A>>Для меня все просто: Композиция(агрегация) — механизм повторного использования типов, построения иерархии типов. Делегирование — механизм позднего связывания функционала. Это как наследование и виртуальные методы, только имеет большую гибкость, так как работает на этапе выполнения. Наследование же с вирт методами на этапе компиляции работает.

VD>А вы в курсе, что наследование необязательно для полиморфизма подтипов?
VD>В курсе, что есть структурные системы типов (большая часть языков семейства ML) в которых понятие подтипа определяется без наследования (по совпадению структуры типов)?
VD>Вы хоть знаете какой системой типов обладает Делфьи?

Вы тут чушь полную написали. Особенно про образование, то была ирония. Чувство юмора смотрю не всем еще доступно. Я, например, еще и в информационном центре МГУ успел поработать. Как вы думаете, где в стране есть MDA + RUP??? А там ведь delphi используется. Включи свой мозг и не хами учителю!

Есть наследование когда наследник является подтипом, а есть когда нет. При этом есть языки, которые это(наследник является еще и подтипом) гарантируют, а есть — нет. То, что вы привели — это подтипы с гарантией. Вопрос в реализации. Класс хранит указатель — это наследование в вашем понятии, всерка классов по совпадению — это тогда что? Есть проверка равенства по указателям, а есть по значениям. Не наводит не накие мысли??? То, что где-то что-то заменили не является обоснованием правильности терминологии. С вашим подходом(на каждое определение у меня свой язык программирования)далеко не уедите. Это невежество и пустозвонство. Для справки, многие учителя на INTUIT признают эйфель лучшим ООП языком. Автор же вывел 11! СПОСОБОВ НАСЛЕДОВАИЯ. Автор первый лауреат премии консорциума ООП. Из этой работы растут ноги у С#. Для тех кто в теме C# кажется плагиатом, не более. Там все повторяется(на момент версии 3.5). Для меня дельфа и сишарп — фавориты на рынке бизнес-приложений, поэтому то, что принято в них используется в качестве примеров и название я сменю только на "Тип данных и программирование", не более...

Здравствуйте, samius, Вы писали:

s> A>Нормальное это поведение доступ к приватным полям в модуле.

s> Если бы это было нормально, так было бы везде, а не только в delphi

В Ada точно так же, там Private-члены видным всему пакету. Это вообще-то вполне логично

s> A>Написали бы там библиотеку компонентов — знали бы что это и с чем едят.

s> Вы полагаете что в философии сидят непрактикующие философы, которые не знают как с private (strict) библиотеки создавать?

Я так в этом теперь и не сомневаюсь

avalon 1.0rc3 rev 380, zlib 1.2.3

Качество программы задает необходимую степень минимизации трудозатрат на разработку программы и еѐ использование человеком.

Несерьезно, особенно о минимизации трудозатрат.

С точки зрения языка программирования переменная – это структурная единица,
необходимая для определения самого языка (это кирпичик языка).

а ведь есть языки без переменных, что ставит под сомнение необходимость.

Значение. В контексте того, что уже знаем, получаем следующее определение: значение
– это данные в переменной (в памяти компьютера), представленные в конкретный момент
времени.

Значения бывают и вне переменных.

По моему мнению, предшественницей объективно-ориентированного программирования была методология процедурного программирования с императивным синтаксисом языка.

что за императивный синтаксис и чему он противопоставляется?

Теперь давайте перейдем к объектно-ориентированной парадигме в программировании. Основным понятие в ООП является класс.

Это не так в отношении парадигмы. Класс — это специфика некоторых ООЯ.

Класс – пользовательский тип данных,

Неверно. Класс — это шаблон объекта, набор метаданных.

Класс – это статическое понятие времени проектирования, в то время как объекты – динамическое понятие времени выполнения.

специфично для языков со статической типизацией.

Говорят, что класс Б наследует от класса А, когда класс Б получает функциональность класса А при определении класса Б.

туманное определение

Для полного понимания различий необходимо определить еще одно понятие. Полиморфизм отражает ту характеристику методологии, согласно которой с объектом можно работать как с объектом другого класса, экземпляром которого он тоже является

Не уверен, что это определение. Тем более, речь о частном случае полиморфизма как такового.

Теперь о главном в примере: четырехугольник наследует характеристики многоугольников.

Букварный случай нарушения LSP в ООП.

Агрегация – еще один способ повторного использования кода и создания архитектуры классов, наряду с наследованием.

Где композиция?

Инкапсуляция (сокрытие информации) – механизм парадигмы, позволяющий скрывать внутренний функционал класса от классов, его использующих.

понятие вне парадигмы ООП, даже когда речь идет о сокрытии. Правильнее будет сказать "механизм, который использует парадигма". Но это опять определение в стиле "колесо — это то что у велосипеда круглое".

Здравствуйте, hattab, Вы писали:

H>Отчего же? В рамках одного модуля имеет смысл. Private это не строгий ограничитель, и на дружественные (находящиеся в одном модуле) он не действует. Для строгого ограничения (область класса) есть Strict Private.

Причем тут модуль? Это модификатор доступа к члену класса. Виртуальный метод который нельзя переопределить смысла не имеет.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

VD>>>По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.
S>>Тоже глаз резануло, хотя на делфи до 5-ой версии работал. Нифига правда не помню о делфи кроме := и begin/end

VD>Я тоже Дельфи в руки уже более 10 лет не брал. Но я не вижу как можно использовать приватные виртуальные методы.

Там походу действительно private видим всему unit-у. Т.е. все классы unit-а друг другу friend-ы

А в версии 7 ввели strict private

Вот думаю, а чей это косяк с private? Не Хейлсберга ли самого?

Здравствуйте, VladD2, Вы писали:

VD> VD>> Причем тут модуль? Это модификатор доступа к члену класса. Виртуальный метод который нельзя переопределить смысла не имеет.

VD> H>Еще раз. Private это нестрогий ограничитель. Он не закрывает члены класса от дружественных классов (располагающихся в одном с ним модуле).

VD> Еще раз для танкистов. Private закрывает возможность переопределения метода наследниках. Так что virtual просто не имеет смысла.

Private не закрывает возможность перекрытия метода в наследниках, Private ограничивает видимость членов рамками класса и (!) модуля в котором определен класс. Классы определенные в рамках одного модуля считаются дружественными и имеют доступ к Private-членам друг друга. Поэтому код:

Type

 TClassA = Class

  Private

   Procedure Proc; Virtual; Abstract;

 End;

 TClassB = Class(TClassA)

  Private

   Procedure Proc; Override;

 End;

{ TClassB }

Procedure TClassB.Proc;
Begin
 //
End;

является корректным. Для строгого ограничения применяется Strict Private. Так что, господин водитель танка, сними шлемофон и обсыпься пеплом.

avalon 1.0rc3 rev 380, zlib 1.2.3

2. Повествование с сильными перескоками, без разделения. Сначала про архитектуру ЭВМ, потом про битность, потом про клепание формочек мышкой, потом про качество ПО... Вы уж определитесь с темой.
3. Текст перемежается пачками определений на полстраницы-страницу, которые зверски рвут контекст. К следующей странице забываешь, о чём читал.
4. Не совсем понятна истинная цель статьи. Если Вы обьясняете совсем новичку, я бы воздержался от глубокого анализа типов данных и ООП вообще. В этом случае стоило бы объяснить азы последовательно, на базе простеньких императивных примеров. Если же Вы пытаетесь писать для не-новичка, бОльшую часть приведённых Вами определений он уже должен знать и понимать. Зачем тогда они в тексте статьи — неясно.

Мой краткий вывод: статья похожа на вводные институтские лекции в стиле "лишь бы было". Прочитав эту кашу, Ваш племянник будет смотреть на программирование исключительно с отвращением.

В статье выделил следующие крупные темы, каждую из которых неплохо бы осветить отдельно (список вразброс):
1. Архитектура компьютера. Биты, байты, etc.
2. Языки программирования. Базовые элементы программы. Базовые управляющие конструкции.
3. RAD-среды — оставил бы на потом.
4. Требования, предъявляемые к ПО. На совсем потом. Лучше небольшой экскурс в принципы хорошего стиля.
5. Выявление ошибок в программах — после полного понимания 1 и 2.
6. Алгоритмы.
7. ООП. Как уже говорили в соседних ветках, в Вашей статье нарушение LSP в полный рост.
8. Методологии... зачем они здесь? Не стОит грузить школьника такими формализмами. ПМСМ, лучше выдать ему набор "строительных блоков", и пусть комбинирует как хочет.
9. Полиморфизм — отдельная здоровенная тема.

Чего тут точно нет, так это типов данных.

В целом же, я бы на Вашем месте взял что-нибудь готовое.
Сам, к сожалению, подкинуть в данный момент ничего не могу помимо упомянутого в статье и соседних ветках

Припомню — обязательно напишу.

Здравствуйте, samius, Вы писали:

S>Поглядел рефлектором — там IL internal трактуется как private, а IL private как strict private.

Ясно. Как всегда через задницу.

Здравствуйте, VladD2, Вы писали:

VD> H>В этих языках есть понятие пакета/модуля?

VD> Да, сборки.

Сборки это не модули. С практической точки зрения связанность кода в рамках модуля допустима т.к. модуль укрупняет инкапсуляцию, а все что под капотом есть детали реализации. Публичные-то контракты от этого не страдают

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, samius, Вы писали:

s>> видимо речь о "private part of the package declaration", т.е. о типах, а не о членах класса/записи? В общем, в ADA не точно так же.

H>Там просто другая идеология ООП. Поэтому прямой кальки и не получится. Но там есть внутренние пакеты, дочерние пакеты (расширяющие родительский и имеющие доступ к закрытым членам).

Раз кальки не получается, то и аргумент про ADA не состоялся.

Здравствуйте, hattab, Вы писали:

H>Сборки это не модули.

С чего бы это?

H>С практической точки зрения связанность кода в рамках модуля допустима т.к. модуль укрупняет инкапсуляцию, а все что под капотом есть детали реализации. Публичные-то контракты от этого не страдают

Укрупнение инкапсуляции — это очень смешно. Хорошее, полит-корректное название для нарушения инкапсуляции. Я не знаю как там обстоят дела с вашей "практической точки зрения", но если даже забыть про ООП и т.п., на практике есть такая штука как АТД. И возможность залезть в кишки АТД — это недостаток, а не преимущество.

В языках где модули действительно используются по назначению (например, OCaml) АТД представляются именно модулями. В них модуль — это первоклассниц сущность.

В общем-то понятно зачем в Дельфи дали возможность залезать в кишки типов. Периодически бывает ситуация когда несколько типов должны быть очень тесно связаны (например, по соображениям производительности). Пакеты позволяет инкапсулировать такое залезание. Однако это никак не оправдывает столь странного имени модификатора доступа. А strict privat звучит просто смешно. "- Ворона, ворона сколько у тебя ножек? — Две! Особенно левая!!!".

Здравствуйте, VladD2, Вы писали:

VD> VD>> Это называется наследование интерфейса.

VD> H>Класс от интерфейса не наследуется

VD> Тебя случаем не Компиатн Очевидность завут? Какое это имеет отношение к делу?

Что в имени тебе моем? Такое и имеет, что реализация интерфейса не есть наследование интерфейса

Или о чем ты?

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, samius, Вы писали:

s> s>> в C# такая свобода существует и называется internal, в java — package. А в делфи она называется тем словом, которым принято обозначать другой уровень видимости.

s> H>Это слово трактуется весьма широко.

s> Так широко оно трактуется только в делфи.

В английском языке.

s> H>Еще раз напомню тебе, что в C# nested types имеют доступ к private членам класса владельца. У тебя диссонанса не случается от этого?

s> Нет.

А должен бы...

s> s>> И логики в этом походу не больше, чем в том что List-ом в дотнет называют динамический массив.

s> H>List это абстракция. Детали реализации (list as dynamic array) это детали реализации. У нас ОПП или где?

s> Если чо, то ты назвал абстракцией класс, где нет ни одного виртуального метода.

Опять ты с деталями... Я говорю о List (о боже, не о дотнетовском List, а вообще), как об абстракции, а ты все в детали реализации лезешь. Зачем?

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:

A>>>Нормальное это поведение доступ к приватным полям в модуле.
S>>Если бы это было нормально, так было бы везде, а не только в delphi
S>Нужно понимать, что Delphi вырос из Паскаля, в котором границы областей видимости были чётко связаны с unit задолго до вкорячивания в него OOP.
S>Именно опыт с Delphi и прочими языками привёл в конечном итоге к обобщённой модели access modifiers, принятой в дотНет.
Насколько я пошарил по ссылкам, модель access modifiers практически в текущем виде была впервые реализована в Simula до рождения самого Паскаля. А дотнет писали с Java, в котором эта модель уже работала и была срисована с C++ видимо, в котором как я полагаю, access modifiers появился тоже раньше чем в Паскале.

http://stackoverflow.com/questions/1334451/history-of-public-private-protected

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>>http://stackoverflow.com/questions/1334451/history-of-public-private-protected
S>Ещё раз: концепция публичности/приватности появилась в Паскале в незапамятные времена.
Она там не могла появиться раньше симулы. Может быть в ADA?
S>Тогда это называлось Модульное программирование, и было сильно лучше, чем голый C с его глобальной видимостью процедур.
И C тоже еще не родился
S>Границей видимости был модуль, с его interface/implementation секциями.
S>Всё, что внутри implementation, видело друг друга.
Я имел дело с паскалем и делфи около 7и лет в том веке.

S>Поэтому отражение той же реальности в ООП, привнесённом в готовый язык, было полностью логичным. Тем более, что стояла задача сделать OOP максимально простым — без пяти уровней доступа, модификаторов friend и прочего стуффа. Это же учебный язык.
Да, я понимаю мотивы внесения в таком виде. Но было бы разумнее выбрать другое слово, а не вносить потом strict. Сам факт его внесения свидетельствует о том, что модель была неудачная.

S>И вообще, не существует какого-то единого "православного" способа готовить access modifiers. Их существование определяется необходимостью и возможностью. Возможность — это вычислимость предиката доступности в момент биндинга. В модели С++ не так уж много способов вычислить, в каких отношениях находится текущий компилируемый кусок кода к использованным им компонентам класса. К примеру, нет поддержки "модулей" с несколькими классами — а с ней и возможностей провести по ним границу доступа.
Я не считаю модель доступа C++ идеальной. Но границу доступа там можно проводить набором заголовков, что и является обычной практикой.

S>Необходимость — это практический смысл. Даже самый базовый public/private позволяет предотвратить ненамеренную ошибку потребителя кода завязаться на то, что ты считаешь деталью реализации, или случайно сломать тебе инвариант.
S>protected позволяет публиковать разный уровень подробностей для потребителей и для наследников — если наследники предполагаются. Поэтому в COM, где нет наследования, нет никакого protected.

Все что я пытаюсь доказать — это то, что модель, в которой private ограничен уровнем модуля не является нормой для ООП.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:

S>Симула ни при чём. Вы понимаете, что речь идёт про тот Паскаль, в котором не было ООП?
Да, и в нем не было слова private, были только секции interface/implementation, некие аналоги h,c файлов.

S>>Да, я понимаю мотивы внесения в таком виде. Но было бы разумнее выбрать другое слово, а не вносить потом strict. Сам факт его внесения свидетельствует о том, что модель была неудачная.
S>Выбирали одни люди, в 1980х, а вносили другие, через 25 лет. О чём вы говорите?
О том что другие люди таки посчитали что область видимости private слишком широка.

S>>Я не считаю модель доступа C++ идеальной. Но границу доступа там можно проводить набором заголовков, что и является обычной практикой.
S>Покажите мне access modifier в С++, который позволяет провести границу доступа по набору заголовков. Обычной практикой всё же является public/private, а не #ifdef _included_from_same_assembly_
Я отвечал на это

К примеру, нет поддержки "модулей" с несколькими классами — а с ней и возможностей провести по ним границу доступа.

В том плане что несколько классов можно определить в одном header-е. Аналогия не полная, но границы доступа определять позволяет.

S>>Все что я пытаюсь доказать — это то, что модель, в которой private ограничен уровнем модуля не является нормой для ООП.
S>Зато является нормой для модульного программирования.
разве в оригинальном паскале было слово private?

S>А ещё Private — это такая порностудия. Какие выводы можно из этого сделать?
S>Я думаю, такие же, как и из того, raise и throw в разных языках значат одно и то же: ключевые слова контекстно-зависимы. Не имеет смысла объяснять японцам то, что им не стоило называть гору ямой.
Я лишь пытаюсь показать что обычно у этого модификатора другой смысл. Использовать private в делфи без оговорок в статьях, имеющих отношение к ООП — плохая идея.

Здравствуйте, samius, Вы писали:
S>Да, и в нем не было слова private, были только секции interface/implementation, некие аналоги h,c файлов.
Вы лучше такие аналогии не применяйте. Устройство хидеров в С — это ужас летящий на крыльях ночи. Через пятьдесят лет дети будут недоверчиво смеяться, когда мы будем им рассказывать про то, что можно было вот так вот обманывать самих себя, иногда подсовывая компилятору неполные определения.
Паскаль, в отличие от С, имел нормальную модульную архитектуру. С поддержкой, естественно, метаданных.

S>О том что другие люди таки посчитали что область видимости private слишком широка.
Они не считали. Они просто сделали новое поколение языка, перед которым поставили другие задачи. Вы сейчас рассуждаете, как неопытный архитектор, глядя на гостиницу "Каравелла" в Лиссабоне: "чего это они не предусмотрели канализацию при постройке". Гостиницу строили и перестраивали четыреста лет. По-моему, можно даже невооружённым мозгом понять, почему в 1680 году строители не заложились на лифт и канализацию, а также почему в 1980 их всё-таки добавили.
Поймите, разработчики версии 5.0 не могли предусмотреть появления интеграции с дотнетом в версии 15.0. А разработчики версии 15.0 не могли волшебным образом изменить значение существующего ключевого слова, так же как реконструкторы гостиницы не могли волшебным образом пропустить трубы в стенах древнего здания.

S>Я отвечал на это
S>

S>К примеру, нет поддержки "модулей" с несколькими классами — а с ней и возможностей провести по ним границу доступа.

S>В том плане что несколько классов можно определить в одном header-е. Аналогия не полная, но границы доступа определять позволяет.
Аналогия вообще никакая. То, что несколько классов случайно оказались в одном хидере, это даже не часть языка. Нет никакого способа сказать, какой класс пришёл из какого хидера — как только я написал список инклюдов, начинается свальный грех.
Именно поэтому нет никакого ключевого слова вроде "header internal", которое бы позволило дать доступ к мемберу классам из "того же хидера".

S>разве в оригинальном паскале было слово private?
В TP 5.0 — было. Хейльсберг поставил перед собой задачу сделать язык, пригодный для изучения ООП. Он гордился тем, что добился этого всего четырьмя ключевыми словами. То, что вы предлагаете, означало как минимум на 20% больше новых ключевых слов.
S>Я лишь пытаюсь показать что обычно у этого модификатора другой смысл. Использовать private в делфи без оговорок в статьях, имеющих отношение к ООП — плохая идея.
(Вздыхает). То, что вы называете "oбычно" — продукт совсем другой эпохи. В 1989 никаких "обычно" ещё не было. В том же году в С++ добавили access modifier protected. В Simula никаких private не было.
А в наши дни, конечно же, использовать Delphi для примеров в статьях не про Delphi — неожиданно. Тем более при рассуждении о типизации — дельфийская система типов изобилует причудливыми странностями ничуть не меньше, чем древнеэльфийский у JRRT.

Здравствуйте, Albatros, Вы писали:

A>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов. Наследования интерфейсов нет. Не путайте твердое с мягким.
Непонятно. Как раз разные реализации методов и подразумеваются. Попробуйте подразуметь некую "одинаковую" реализацию метода произвольного интерфейса в любом современном ООЯ.
К примеру, в COM, где наследования вовсе нет, интерфейсы представляют собой единственный способ поддержки полиморфизма.

Здравствуйте, VladD2, Вы писали:

VD>В языках где модули действительно используются по назначению (например, OCaml) АТД представляются именно модулями. В них модуль — это первоклассниц сущность.

Модуль да, зато в объектах OCaml (http://www.ocaml.spb.ru/chapter03.html#id2259433) тоже как и в дельфи очень самостийный private

Во первых этот private на самом деле protected, то есть потомки видят private методы предков, и virtual private вполне нормально.
Во вторых private относится к объекту а не к классу и поэтому объекты одного и того же класса не могут копаться у друг друга в кишках.

Здравствуйте, Albatros, Вы писали:

A>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов.
Это полная чушь. Берешь интерфейс IA с методом X и реализуешь его в 20 разных классах. Потом обращаешься к ссылке с типом IA — вот тебе полиморфизм.

A>Наследования интерфейсов нет.

intarface IA {}
intarface IB:IA {}

A>Не путайте твердое с мягким.
Ты полную чушь говоришь.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, VladD2, Вы писали:

VD>>Здравствуйте, Albatros, Вы писали:

S>>>>Интересно. С нетерпением жду узнать, что же годится для инженерных и прикладных задач.

A>>>В статье будет это разжевано. Уже есть текст. Как выложить с заявкой на публикацию не знаете?

VD>>Не обижайтесь, но вам явно рано писать статьи на тему типов данных. Добавьтве в название слово Delphi и многие претензии к вам предъявляться не будут.

VD>>Тема типов данных — это очень не простая научная тема. Описать ее просто и при этом правильно очень не просто.

A>Такие высказывания необходимо обосновывать. Голословные утверждения — известный всем признак необразованности.

Ну у меня например тема типов данных стойко ассоциируется с вот этим

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, FR, Вы писали:

VD>>>Еще раз для танкистов. Private закрывает возможность переопределения метода наследниках. Так что virtual просто не имеет смысла.

FR>>От языка зависит, в C++ не закрывает и даже является одной из достаточно широко используемых идиом:

Z>Почему для этой цели не используется protected?

ЕМНИП, если надо закрыть возможность дёрнуть реализацию предка из потомка.

Здравствуйте, gandjustas, Вы писали:

G>Выше код показывает наследование интерфейсов. В спецификации языка C# можешь посмотреть, оно именно наследованием называется. Для COM тоже есть наследование интерфейсов, для java есть, опять-таки судя по спецификации.

G>Композиция это вообще не то. Композиция это когда один код пользуется другим кодом для реализации своей функциональности.

Ну так это другое наследование, мы про разные вещи говорим! Обеспечением полиморфизма всегда были есть и будут виртуальные методы. Это тоже другой полиморфизм. Назвали и ладно, все равно
это разные вещи.
Это не композиция, это делигирование ты написал. А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Albatros, Вы писали:

A>>Здравствуйте, gandjustas, Вы писали:

A>>>>Это не композиция, это делигирование ты написал.
G>>>А в чем разница?

A>>>>А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись.
G>>>Что значит включает? Покажешь на том примере что я написал отличие композиции от делегирования?

A>>Для меня все просто: Композиция(агрегация) — механизм повторного использования типов, построения иерархии типов. Делегирование — механизм позднего связывания функционала. Это как наследование и виртуальные методы, только имеет большую гибкость, так как работает на этапе выполнения. Наследование же с вирт методами на этапе компиляции работает.

G>Для тебя конечно просто, а я вообще перестал понимать что ты пытаешься сказать. Ты слишком вольно обращаешься с терминологией. Поэтому давай перейдем к более формальным языкам.
G>Повторяю: покажи в коде различия между композицией и делегированием, на том примере что я приводил.

Это уходит от темы. Делегирование — это передача реализации, т.е. это механизм событий и вызова методов. Обращение к методу B — это делегирование, а приватное поле — агрегация.

Здравствуйте, Albatros, Вы писали:
A>Вы тут чушь полную написали. Особенно про образование, то была ирония. Чувство юмора смотрю не всем еще доступно. Я, например, еще и в информационном центре МГУ успел поработать. Как вы думаете, где в стране есть MDA + RUP??? А там ведь delphi используется. Включи свой мозг и не хами учителю!

A>Есть наследование когда наследник является подтипом, а есть когда нет. При этом есть языки, которые это(наследник является еще и подтипом) гарантируют, а есть — нет. То, что вы привели — это подтипы с гарантией. Вопрос в реализации. Класс хранит указатель — это наследование в вашем понятии, всерка классов по совпадению — это тогда что? Есть проверка равенства по указателям, а есть по значениям. Не наводит не накие мысли??? То, что где-то что-то заменили не является обоснованием правильности терминологии. С вашим подходом(на каждое определение у меня свой язык программирования)далеко не уедите. Это невежество и пустозвонство. Для справки, многие учителя на INTUIT признают эйфель лучшим ООП языком. Автор же вывел 11! СПОСОБОВ НАСЛЕДОВАИЯ. Автор первый лауреат премии консорциума ООП. Из этой работы растут ноги у С#. Для тех кто в теме C# кажется плагиатом, не более. Там все повторяется(на момент версии 3.5). Для меня дельфа и сишарп — фавориты на рынке бизнес-приложений, поэтому то, что принято в них используется в качестве примеров и название я сменю только на "Тип данных и программирование", не более...

Простите, но ваш вот этот пост — просто поток сознания.
Для начала переключите просмотр форумов в древовидный режим.
Затем всё же прислушайтесь к тому, что вам тут пишут. Вы многое понимаете правильно, пусть и на интуитивном уровне. Но изобретение собственной терминологии мешает вам двигаться дальше, т.к. вы перестаёте воспринимать накопленный ранее опыт.
Критика дельфи, которая вас так задевает, в основном звучит от людей, которые на этом дельфи отработали в полный рост. Они право критиковать ранних детей Хейльсберга заслужили.

Здравствуйте! Написал небольшую работу, на неформальном языке, посвященную месту типа данных в программировании. Это не учебник, а систематизация моих знаний. Подумал может быть полезна для других. Был бы очень признателен за отзывы по работе. Если она выдержит критику, то в планах написать полную 3-ю главу в журнал. Архив с примерами доступен по ссылке. Там всего 24 страницы с примерами и списком использованной литературы.

На 22 странице опечатка "инерфейс" вместо, очевидно, интерфейса.

Рекомендую изучить TAPL, если вас интересует эта тема.

Спасибо. Буду читать

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Albatros, Вы писали:

VD>Почитал... Не понял только одного. Как работа связанная с введением в Дельфи и списком всевозможных терминов (большая часть не имеющая никакого отношения ни к Дельфи, ни тем более, к типам) относится к типам данных?

VD>К типам данных это писание не имеет никакого отношения.

VD>Как введение в программирование этот материал тоже, на мой взгляд, плох, так как перепачкан не относящимися к делу вопросами. А идея начинать программирование с формочек порочна в принципе. Заниматься формолепством ради того чтобы вывести строку содержащую сумму двух числе — это верх отвлечения от темы. Сдается мне, что даже Дельфи к 21-ому веку доросла до применения консоли, которой здесь самое место.

VD>Даже самое название статьи выглядит как-то странно — "Тип данных в прикладном программировании". Чем типы данных в системном программировании отличаются от них же в прикладном? Очевидно, ничем. Это одно и то же.

Термины — это фиксация предмета обсуждения. Работа не полностью написана, есть 3-я глава где идет попытка достучаться, что необходимо вводить изменения в ООП. Пишется 4-я, как взгляд на базы данных через типы данных. В примерах же идет акцентирование на типах данных. Работа — это не ввод в дельфи, эта работа задумывалась больше для старшеклассников, сам я работал 3 года преподавателем программирования в МГТУ "СТАНКИН", поэтому могу что-то написать на эту тему. В частности в полной 3-й главе предлагается ввести еще один вид сущностей, призванный закрыть один недостаток в ООП (либо использовать как архитектурный шаблон). Как узнаю как можно права защитить, так сразу выложу. Полную третью главу планирую оформить как статью, по вашим правилам.
С формочек начинал чтобы учились сразу работать с РАД системами. Там форма — только средство написания оконной программы, акцентирование идет на математике. Первый пример — раскрытие понятия тип данных. Второй — важность граммотного применения типов данных и заодно модульность в архитектуре ПО.
Название "Тип данных в прикладном программировании" — это отражение того, что работа имеет более широкий вопрос рассмотрения, нежели чисто понятие типа данных. В работе даются советы при программировании задач, востребованных бизнесом. Работа не привязана к дельфям, на них только примеры.

Здравствуйте, deniok, Вы писали:

D>На 22 странице опечатка "инерфейс" вместо, очевидно, интерфейса.

D>Рекомендую изучить TAPL, если вас интересует эта тема.

Хороший перевод, хотя это явно не для всех. Слишком формализовано и опять таки на базе типизирвоанных лямбда-ичислений, т.е. интересно в основном теоретикам.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, VladD2, Вы писали:

VD>>Здравствуйте, Albatros, Вы писали:

VD>>Почитал... Не понял только одного. Как работа связанная с введением в Дельфи и списком всевозможных терминов (большая часть не имеющая никакого отношения ни к Дельфи, ни тем более, к типам) относится к типам данных?

VD>>К типам данных это писание не имеет никакого отношения.

VD>>Как введение в программирование этот материал тоже, на мой взгляд, плох, так как перепачкан не относящимися к делу вопросами. А идея начинать программирование с формочек порочна в принципе. Заниматься формолепством ради того чтобы вывести строку содержащую сумму двух числе — это верх отвлечения от темы. Сдается мне, что даже Дельфи к 21-ому веку доросла до применения консоли, которой здесь самое место.

VD>>Даже самое название статьи выглядит как-то странно — "Тип данных в прикладном программировании". Чем типы данных в системном программировании отличаются от них же в прикладном? Очевидно, ничем. Это одно и то же.

A>Термины — это фиксация предмета обсуждения. Работа не полностью написана, есть 3-я глава где идет попытка достучаться, что необходимо вводить изменения в ООП. Пишется 4-я, как взгляд на базы данных через типы данных. В примерах же идет акцентирование на типах данных. Работа — это не ввод в дельфи, эта работа задумывалась больше для старшеклассников, сам я работал 3 года преподавателем программирования в МГТУ "СТАНКИН", поэтому могу что-то написать на эту тему.

1)Все что написано очень мало относится к типам данных. Скорее получилось введение в делфи с кучей непонятных слов.
2)Старшеклассники не знают множеств (это уже вышка, которую дают в универе), как объяснить типы не через множества —

3)Классическая ошибка для пейсателей статей по программированию: попытка объяснить ООП "на пальцах" с примерами типа наследования четырехугольника от многоугольника. В реальной разработке применение ООП на порядок сложнее, а вы пытаетесь учить неправильному.

A>В частности в полной 3-й главе предлагается ввести еще один вид сущностей, призванный закрыть один недостаток в ООП (либо использовать как архитектурный шаблон).
Не думаю что сферические старшеклассники осилят.

A>С формочек начинал чтобы учились сразу работать с РАД системами.Там форма — только средство написания оконной программы, акцентирование идет на математике.
На это уходит немалая часть объема. С консолькой, а лучше с каким-нить repl, можно было бы упростить себе жизнь.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте! Написал небольшую работу, на неформальном языке, посвященную месту типа данных в программировании. Это не учебник, а систематизация моих знаний. Подумал может быть полезна для других. Был бы очень признателен за отзывы по работе. Если она выдержит критику, то в планах написать полную 3-ю главу в журнал. Архив с примерами доступен по ссылке. Там всего 24 страницы с примерами и списком использованной литературы.
Тоже не понял предмета обсуждения.
Категорчиески не согласен с
1. определением
"Класс – пользовательский тип данных, представляющий такие члены класса, как атрибуты (создают структуру данных класса), события и методы (функции и процедуры). Значениями класса являются объекты."
Логичнее что бы класс порождал объекты, а типы порождали значения. Разница между объектами и значениями в операциях сравнения. И вообще объект равный себе один, а равных значений может быть много.. Ну, и еще там есть.. это классика..
2.
"И так, тип данных определяет множество значений, а также набор операций, которые можно применять к таким значениям."
Все таки операции определяются отдельно а не типом и это отдельная тема..
3. Потому следующее определение операций несколько легкомысленное.
"Оператор (операция) языка программирования. Это структурная единица языка программирования, представляющая инструмент человеку для формирования алгоритмов обработки данных (значений, операндов). Операторы бывают унарными и бинарными. Унарный оператор – действие над одним значением или переменной (или операндом). Бинарный оператор – над двумя. Возьмем, например, оператор «+» в Delphi. Если он стоит слева от значения, то это оператор обозначения знака числа. Если между двумя значениями (либо переменными) – то это оператор сложения."
Оператор и операция несколько разные вещи..Да и операции (в каком-то определении) бывают ассоциативными, префиксные, дистрибутивные и т.д... это все не маловажно..
4. Определение переменных может быть более менее справедливым только для императивной парадигмы.
"Переменная. С точки зрения архитектуры ЭВМ переменная – это структурная единица памяти, ячейка, куда кладутся данные. На аппаратном уровне переменная в процессоре – это регистры (ячейки) процессора, в хранилищах данных – набор единиц и нулей, имеющий свой адрес, чтобы можно было во множестве хранимых данных найти требуемые. С точки зрения языка программирования переменная – это структурная единица, необходимая для определения самого языка (это кирпичик языка). Но мы-то не процессоры, поэтому важнее понимать, что есть переменная для нас, программистов, владеющих каким-нибудь языком программирования. С точки зрения программиста переменная – это изменяемые данные прикладной области, их представление в тексте программы."

И вообще, я не понял о чем тут речь. И причем тут типы?

Здравствуйте, gandjustas, Вы писали:

G>1)Все что написано очень мало относится к типам данных. Скорее получилось введение в делфи с кучей непонятных слов.
G>2)Старшеклассники не знают множеств (это уже вышка, которую дают в универе), как объяснить типы не через множества —

G>3)Классическая ошибка для пейсателей статей по программированию: попытка объяснить ООП "на пальцах" с примерами типа наследования четырехугольника от многоугольника. В реальной разработке применение ООП на порядок сложнее, а вы пытаетесь учить неправильному.

A>>В частности в полной 3-й главе предлагается ввести еще один вид сущностей, призванный закрыть один недостаток в ООП (либо использовать как архитектурный шаблон).
G>Не думаю что сферические старшеклассники осилят.

A>>С формочек начинал чтобы учились сразу работать с РАД системами.Там форма — только средство написания оконной программы, акцентирование идет на математике.
G>На это уходит немалая часть объема. С консолькой, а лучше с каким-нить repl, можно было бы упростить себе жизнь.

1. Это предмет обсуждения фиксируется. Невозможно типы данных описать без того, где они используются. Я же писал, что это неполный вариант. Полную 3-ю главу буду оформлять как статью. Пишу 4-ю главу про БД.
2. Можно и так, если сложно написано: тип данных "целые числа" включает в себя, например, значения ...,-3, -2, -1, 0, 1,... Усё

3. ООП я знакю что такое, разработал библиотеку визуальных компонентов Delphi(порядка 70 модулей по 1..30 классов в каждом)

Хорошо, если ООП описано неправильно, то что там неверно более конкретно?

Здравствуйте, batu, Вы писали:

B>Тоже не понял предмета обсуждения.
B> Категорчиески не согласен с
B>1. определением
B>"Класс – пользовательский тип данных, представляющий такие члены класса, как атрибуты (создают структуру данных класса), события и методы (функции и процедуры). Значениями класса являются объекты."
B>Логичнее что бы класс порождал объекты, а типы порождали значения. Разница между объектами и значениями в операциях сравнения. И вообще объект равный себе один, а равных значений может быть много.. Ну, и еще там есть.. это классика..
B>2.
B>"И так, тип данных определяет множество значений, а также набор операций, которые можно применять к таким значениям."
B>Все таки операции определяются отдельно а не типом и это отдельная тема..
B>3. Потому следующее определение операций несколько легкомысленное.
B>"Оператор (операция) языка программирования. Это структурная единица языка программирования, представляющая инструмент человеку для формирования алгоритмов обработки данных (значений, операндов). Операторы бывают унарными и бинарными. Унарный оператор – действие над одним значением или переменной (или операндом). Бинарный оператор – над двумя. Возьмем, например, оператор «+» в Delphi. Если он стоит слева от значения, то это оператор обозначения знака числа. Если между двумя значениями (либо переменными) – то это оператор сложения."
B>Оператор и операция несколько разные вещи..Да и операции (в каком-то определении) бывают ассоциативными, префиксные, дистрибутивные и т.д... это все не маловажно..
B>4. Определение переменных может быть более менее справедливым только для императивной парадигмы.
B>"Переменная. С точки зрения архитектуры ЭВМ переменная – это структурная единица памяти, ячейка, куда кладутся данные. На аппаратном уровне переменная в процессоре – это регистры (ячейки) процессора, в хранилищах данных – набор единиц и нулей, имеющий свой адрес, чтобы можно было во множестве хранимых данных найти требуемые. С точки зрения языка программирования переменная – это структурная единица, необходимая для определения самого языка (это кирпичик языка). Но мы-то не процессоры, поэтому важнее понимать, что есть переменная для нас, программистов, владеющих каким-нибудь языком программирования. С точки зрения программиста переменная – это изменяемые данные прикладной области, их представление в тексте программы."

B>И вообще, я не понял о чем тут речь. И причем тут типы?

1. Значения, как и объекты, равные себе только одни. Город Москва — он один, число 7 — тоже одно.

Это значения, как и объекты.
2. Это практически определение из ГОСТ.
3. Не понял замечания. Для неформальной фиксации предмета обсуждения считаю моего определения достаточно.
4. А для ООП, там нет переменных-указателейна объекты?? Бертрана Мейера не читали случаем, разработчика Эйфеля?

Выражение. Выражения используются программистами для общения с ЭВМ, поэтому выражение – это представление алгоритма закладываемого в программу во время проектирования. Выражения представляются операторами языка программирования.

Оператор (операция) языка программирования. Это структурная единица языка программирования, представляющая инструмент человеку для формирования алгоритмов обработки данных (значений, операндов). Операторы бывают унарными и бинарными. Унарный оператор – действие над одним значением или переменной (или операндом). Бинарный оператор – над двумя. Возьмем, например, оператор «+» в Delphi. Если он стоит слева от значения, то это оператор обозначения знака числа. Если между двумя значениями (либо переменными) – то это оператор сложения.

Алгоритм обработки данных. Это последовательность обработки данных, описанная в понятиях структурного программирования, направленная на достижение итоговой задачи по обработке данных.

Зачем эти определения в статье по типам? С тем же успехом можно дать определения "ЭВМ", "языка" и т.п.

Кроме того определения очень поверхностные. По вашему Выражение — это представление алгоритма, а алгоритм последовательность обработки данных, то есть или что-то аморфное, или по сути последовательность выражений, т.е. рекурсивное определение.

Переменная Caption – это текст надписи Label1, которую мы кидали при создании примера. Сами слова «Caption» и «Label1» и полностью «Label1.Caption» являются именами переменных. Эти переменные были созданы автоматически, когда кидали компонент надписи на форму.

Зачем это поверхностное, но тем не менее сложное изложение? Почему нельзя было просто вывести надпись на консоль? Целая кипа концепций ушла бы из виду, а суть изложения осталась бы и стала бы яснее.

Символ «;» — в Delphi это символ разделения операторов.

И вы продолжаете утверждать, что пишете не о Дельфи, а о типах?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Albatros, Вы писали:

A>>Термины — это фиксация предмета обсуждения.

VD>Термины они нужны для чего-то, а ради самих себя. Вы же суете их без малейшей системы и следовательно смысла.
VD>Нельзя излагать что-то от печки (т.е. рассчитывая на полное отсутствие знаний по предмету). Иначе вы начнете вводить "термины" для повседневных, общепринятых понятий и ваша работа превратится в некому не нужны сборник терминов.

A>>Работа не полностью написана,

VD>Мне кажется совершенно не важно дописана они или нет. Важно то, что она не отвечает задачам которые озвучены в ее названии.

A>>есть 3-я глава где идет попытка достучаться, что необходимо вводить изменения в ООП.

VD>Что само по себе весьма спорно. К тому же ООП это очень общий термин. В конце концов Смолток или ЖабаСкрип — это тоже ООП.

A>>Пишется 4-я,

VD>Я бы для начала разобрался с первой. Определился бы с целями работы и выкинул из нее все лишнее. В первую очередь формочки и не относящиеся к делу термины. Все термины давно описаны в инциклопедиях. Например, в Википедии, откуда вы, как я понимаю, и черпали определения. Ну, так не давайте ссылки на эти определения, если считаете, что читатель может быть с ними не знаком.

A>>как взгляд на базы данных через типы данных.

VD>Лет за 30 до вас это сделал Кодд. Вы хотите изложить его мысли в более доступной форме или у вас есть новая теория?

A>>В примерах же идет акцентирование на типах данных.

VD>В примерах ваших идут кнопки формы и простейшие мысли. Причем за кнопками уже этих простейших мыслей не разглядеть.

A>> Работа — это не ввод в дельфи, эта работа задумывалась больше для старшеклассников,

VD>"Работа не по Дельфи, а для старшеклассников" — это само по себе пример демонстрации алогичного мышления. Какая связь между тем о чем материал и на кого он рассчитан? Будь ваша работа рассчитана на докторов наук, она не перестала бы быть посвящена введению в дельфи.

A>> сам я работал 3 года преподавателем программирования в МГТУ "СТАНКИН", поэтому могу что-то написать на эту тему.

VD>На какую тему то? У вас получился рассказ на тему как сложить два числа с использованием формы Дельфи. К теории типов и типам это имеет очень отдаленное отношение.

VD>Вам выше привели ссылку на классическую работу по теории типов. Единственная ее проблема — это сильная заформализованность. Очень советую прочесть ее и подумать как изложить тоже самое до менее формально (в расчете на тех самых старшеклассников, хотя им вряд ли это нужно... не тот уровень базовых знаний).

A>> В частности в полной 3-й главе предлагается ввести еще один вид сущностей, призванный закрыть один недостаток в ООП (либо использовать как архитектурный шаблон). Как узнаю как можно права защитить, так сразу выложу.

VD>Пока что это все выглядит как клоунада. Наивно полагать, что при столь поверхностном рассмотрении вопросов вы смогли сказать новое слово в науке.

VD>Права ваши же защищаются законами нашей и других стран. По нашим законам авторское право всегда принадлежит автору. И уже на основании этого права автор может давать права на публикацию своих работ. Права на алгоритмы защитить нельзя. Права на изобретения регулируются патентами (но как я уже сказал запатентовать алгоритм невозможно).

VD>Так что вам надо определиться с тем, что вы хотите добиться. Если первенства идей, то вам достаточно опубликовать эти идеи под своим именем первым. В принципе для этого достаточно публикации в Интернет. Если есть желание получить более официальный статус публикации, то нужно опубликоваться в одном из научных журналов (если конечно публикацию не зарежут), одним из которых является RSDN Magazine (т.е. журнал этого сайта).

A>>Полную третью главу планирую оформить как статью, по вашим правилам.
A>>С формочек начинал чтобы учились сразу работать с РАД системами.

VD>Зачем? Те кто начинают с РАДостей часто ими и заканчивают. Для ваших задач нужен банальный консольный вывод. Если работа посвящена типам, то о них и надо в основном говорить. А все остальное должно быть не более чем неизбежным антуражем.

A>>Там форма — только средство написания оконной программы, акцентирование идет на математике. Первый пример — раскрытие понятия тип данных. Второй — важность граммотного применения типов данных и заодно модульность в архитектуре ПО.

VD>Ваш первый пример — арифметическое выражение находится на четвертой странице и при этом до него нет ничего связанного с типами. До этого едет попытка изложить все что нужно человеку для понимания компьютера. Только вот работа не называется "введение в информатику". А уж определения вроде "Прикладная область" вообще ни в какие ворота не лезут.

VD>Если вы позиционируете работу на новичков, то вместо того чтобы пудрить им мозг терминами лучше сосредоточьтесь на толковом и доходчивом объяснении сути типов. При этом рассчитайте на то, что человек уже имеет хоть какие-то знания в информатике.

VD>Но, на мой взгляд, серьезное рассмотрение типов для начинающих просто не имеет смысла. У них другие проблемы. Им бы понять смысл программирования и т.п. А типы они, как не странно, проглотят без проблем даже если их отдельно не объяснять. Я учился программировать на С. В С типы везде. Но это не привело к кому-то не пониманию.

A>>Название "Тип данных в прикладном программировании" — это отражение того, что работа имеет более широкий вопрос рассмотрения, нежели чисто понятие типа данных. В работе даются советы при программировании задач, востребованных бизнесом. Работа не привязана к дельфям, на них только примеры.

VD>Вы уж определитесь, или вы дате советы начинающим о том что им потребуется в бизнесе, или о типах данных при разработке программ. Для последнего нет никакой разницы пишется ли программа эмуляции физических процессов или бухгалтерия.

VD>Ну, и хочется заметить, что бизнесу Дельфи уже вряд ли когда-то понадобится. Дельфи окончательно слила свои позиции. Сейчас ее место занял C# и VB, которые имеют ту же систему типов, что и Дельфи. В прочем, с точки зрения теории типов совершенно по барабану на чем излагать. В большинстве классических работ просто придумывается свой язык программирования, правда, обычно, он до боли похож на ML

. Но это понятно почему происходит. Эти работы исходят из типизированных лямбда-исчислений, а все что не вписывается в него прибивают сбоку гвоздями.

VD>ЗЫ

VD>В общем, очень советую вам отложить ваш материал на пару недель. Потом сесть, описать на листочке список целей излоежения и попробовать критически прочесть свой материал еще раз.

Спасибо за развернутый ответ. Наиболее точно цель работы описывается как "Строгая типизация в программировании". Допишу про строгую типизацию языка программирования, собственно. Если говорить о работе(на данном этапе её разработки), как о наброске советов начинающим, то акцентирование внимания на типах данных считаю важнейшем среди них. 3-я глава будет отдельно оформлена, по вашим правилам. Как выложить, чтобы подать заявку на рассмотрение для журнала?
С#, как язык с чисто объектно-ориентированным синтаксисом, не является тем, куда он позиционируется. Я это опишу в 3 главе. Хочу уже выложить

Здравствуйте, Albatros, Вы писали:

A>Спасибо за развернутый ответ. Наиболее точно цель работы описывается как "Строгая типизация в программировании".
Этому названию работа тоже не соответствует. Да и странно писать такую работу с примерами где работает неявное приведение и на языке с нестрогой типизацией.

З.Ы. Оверквотинг не приветствуется

Здравствуйте, Albatros, Вы писали:

B>>И вообще, я не понял о чем тут речь. И причем тут типы?

A>1. Значения, как и объекты, равные себе только одни. Город Москва — он один, число 7 — тоже одно.

Это значения, как и объекты.
Имеем объект "Служащий". Меняем ему зарплату. Объект остался тот же. Имеем Дату. Меняем месяц. Значение изменилось. Кроме того таких же дат (равных) может хранится в памяти сколько угодно. Однако объект "Служащий" может быть только один и равен только самому себе.
A>2. Это практически определение из ГОСТ.
Хреновое определение.
A>3. Не понял замечания. Для неформальной фиксации предмета обсуждения считаю моего определения достаточно.
Увы, что я могу еще сказать..
A>4. А для ООП, там нет переменных-указателейна объекты?? Бертрана Мейера не читали случаем, разработчика Эйфеля?
И его читал.. А еще и функциональные языки (хаскель и лисп) и логические (пролог). Займись. Там не совсем так с переменными..

Здравствуйте, 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 классов в каждом)

1)Обсуждения как такового нет. Про типы сказано мало и не по теме. Вообще слабовата система типов в делфи, чтобы о типах в этом контексте говорить.
2)Компьютерная арифметика нереально сложна для того чтобы описывать типы, например сколько будет 2000000000+2000000000? Если говорить о целочесленных типах как о диапазонах, то тоже плохо получается. Например int

-2^31..2^31), (+): (int,int) -> ? какой тип на выходе? По логике (-2^32..2^32), но почему то делфи и другие языки с этим несогласны.
Вообще у Кнута немалая часть книги посвящена компьютерной арифметике.

A>Хорошо, если ООП описано неправильно, то что там неверно более конкретно?
Примеры неадекватны.

Здравствуйте, 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. Это не учебник по ООП. Хотя там написано, что такое АТД и шаблоны проектирования, архитектурные классы и классы прикладной области. Замечание некорректно, еще раз повторяю.

Здравствуйте, samius, Вы писали:

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. Данные парадигмы не являются целью работы. Рассматриваются востребованные бизнесом задачи. Все в одно не возможно засунуть, особенно ООП в логическое и функциональное программирование

Та все без разницы.. Типа личные заблуждения.. Но, вот за цель работы я спрашивал.. Так и не понял.

Здравствуйте, gandjustas, Вы писали:

1. Вкратце так: наследник должен полностью реализовывать контракт предка.
Во попробуй придумать такой контракт для многоугольника, чтобы четырехугольник его не нарушил.
Даже если придумаешь, то вряд ли он встретится в реальной задаче. А уж тем более в автоматизации бизнеса.

2. Не надо повторять, надо обосновывать.

По первому пункту Кодд(с элипсами и окружностями( 800 страница) с вами не согласен

. В моей же работе написано: уточнение ограничений, специализация, выделение подмножества из множества путем наложения дополнительных ограничений — все это декларативная часть наследования, специализирующая. Все просто: наследование — древовидная иерархия. Одной из особенностей древовидной иерархии является то, что листов больше, чем корней. Это достигается разбиением на подмножества дополнительными ограничениями. Т.е. контракт в нашем случае простой: многоугольник — геометрическая замкнутая фигура, обладающая, к примеру, числом вершин и периметром. Что из этого невозможно гарантировать в четырехугольнике? В треугольнике? Или с ними, может, нельзя работать как с такими многоугольниками?
2. Обосновал в предыдущем посте. Математикой это не обосновать. Удачи!

Здравствуйте, samius, Вы писали:

1. Качество ПО это степень соответствия требованиям. Это формальное определение. Отсюда вытекает что неважно кто его делал и сколько убил ресурсов.

2. Агрегация — это композиция без владения. Надо их отличать.

1. Формализовано кем? Это противоречивое определение. А качество качества требований кто формализовал?

Здравствуйте, batu, Вы писали:

Та все без разницы.. Типа личные заблуждения.. Но, вот за цель работы я спрашивал.. Так и не понял.

Все просто: цель указана на первой странице работы — систематизировать свои знания. Только и всего. Может быть полезна другим читателям. Писалась неформальным языком, т.к. где формальное определение я найти не могу. Одного автора, который был бы признан всеми я найти так и не смог. Стандартов море. Писал с ориентиром на племянника, точнее на его будущую учебу в старших классах, т.е. старался не подниматься выше уровня знаний старшеклассника, интересующегося программированием. Хотел дать советы и показать важность акцентирования внимания на типах данных, т.к. по роду работы постоянно сталкиваюсь с тем, что многие прогеры не могут толком ск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 штук планируется). Будут предложены после анализа доработки призванные некоторые моменты улучшить по моему мнению.
Достойная цель. Только для этого надо самому четко представлять предмет. Не уверен что надо было с типов начинать... Но и машина тьюринга сложновато.. А, действительно! Систематизировать свои знания это хорошая идея..Надо много читать.

Здравствуйте, gandjustas, Вы писали:

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.

Здравствуйте, batu, Вы писали:
Надо много читать.
Перечень использованногй литературы и не только уже проработан.

Здравствуйте, batu, Вы писали:

B>.Надо много читать.
Перечень использованной литературы, и далеко не только, уже переработан

Здравствуйте, 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>

A>Собственно так.

Отлично, TFigure у тебя получился интерфейсом.

Никакой развесистой иерархии на нем ты не постороишь.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:
G>>Это слова. В коде как оно будет выражаться?

A>

A>function TestPerimetrOnFigure();
A>var
A>  Figure: TFigure;
A>begin
A>  Figure := TPriamougolnik.Create();

A>  Result := Figure.Perimetr;
A>end;

A>

A>Собственно так.

Интересует отношение многоугольника и прямоугольника, место ромба, квадрата в иерархии

Здравствуйте, samius, Вы писали:

S>Интересует отношение многоугольника и прямоугольника, место ромба, квадрата в иерархии

Иерархия типов зависит от требуемых в системе методов. Поэтому любая, например:

TMnogougolnik = class(TFigure)
T4Ugolnik = class(TMnogougolnik)
TRomb = class(T4Ugolnik)
TKvadrat = class(T4Ugolnik)

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, batu, Вы писали:
A>Надо много читать.
A>Перечень использованногй литературы и не только уже проработан.

Слабенький перечень..

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, batu, Вы писали:

B>>.Надо много читать.
A>Перечень использованной литературы, и далеко не только, уже переработан

Завтра скину чего надо прочитать..

Здравствуйте, gandjustas, Вы писали:

G>Отлично, TFigure у тебя получился интерфейсом.

G>Никакой развесистой иерархии на нем ты не постороишь.

Уровень вложенности рекомендуется специально ограничивать тремя, иначе растет сложность. Это и у Макконнелла вроде есть и у ребят, что систематизировали шаблоны проектирования(GoF). У них весь их редактор текста был во многом построен на интерфейсах.
НО! В этом примере суперкласс TFigure не является интерфейсом, хотя бы потому, что:
а — имеет свойства
б — интерфейсы не поддерживают полиморфизма. Они при наследовании не получают и модифицируют фукционал, а параллельно дополняют. Здесь чистый полиморфизм.
в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так:

TFigure = class
private
  function GetPerimetr(): real; virtual;
....

function TFigure.GetPerimetr(): real;
begin
  raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
end;

Теперь инвариант класса TFigure такой:
Все наследники обязаны иметь периметр. Вот и все, теперь это не интерфейс абсолютно. Еще раз: хорошая иерархия та, у которой суперкласс абстрактный и сами иерархии определяются тем, какие методы нужны будут.

Да напомню для всех: Бертран Мейер выделяет 11 "легальных" способов наследования, в частности "грязное" — наследование, при котором подкласс не является подтипом, т.е. когда берется чисто функционал без АТД. Вот так вот оказывается бывает.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, samius, Вы писали:

S>>Интересует отношение многоугольника и прямоугольника, место ромба, квадрата в иерархии

A>Иерархия типов зависит от требуемых в системе методов. Поэтому любая, например:

A>

A>TMnogougolnik = class(TFigure)
A>T4Ugolnik = class(TMnogougolnik)
A>TRomb = class(T4Ugolnik)
A>TKvadrat = class(T4Ugolnik)
A>

А если многоугольнику нужно устанавливать набор координат?

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Отлично, TFigure у тебя получился интерфейсом.

G>>Никакой развесистой иерархии на нем ты не постороишь.

A>Уровень вложенности рекомендуется специально ограничивать тремя, иначе растет сложность. Это и у Макконнелла вроде есть и у ребят, что систематизировали шаблоны проектирования(GoF). У них весь их редактор текста был во многом построен на интерфейсах.
A>НО! В этом примере суперкласс TFigure не является интерфейсом, хотя бы потому, что:
A>а — имеет свойства
Если в делфи интерфейсы не могут иметь свойства, то это не значит что так везде.

A>б — интерфейсы не поддерживают полиморфизма. Они при наследовании не получают и модифицируют фукционал, а параллельно дополняют. Здесь чистый полиморфизм.
Интерфейс как чисто абстрактный класс поддерживает полиморфизм

A>в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так:
Класс с абстрактными методами играет роль интерфейса.

A>

A>TFigure = class
A>private
A>  function GetPerimetr(): real; virtual;
A>....

A>function TFigure.GetPerimetr(): real;
A>begin
A>  raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
A>end;
A>

Это ничего не меняет

A>Теперь инвариант класса TFigure такой:
A>Все наследники обязаны иметь периметр. Вот и все, теперь это не интерфейс абсолютно. Еще раз: хорошая иерархия та, у которой суперкласс абстрактный и сами иерархии определяются тем, какие методы нужны будут.

С абстрактным методом все точно так же, с той лишь разницей что не наследуется реализация метода с исключением.

Что значит "интерфейсы не поддерживают полиморфизма"? Что ты имеешь ввиду под словом полиморфизм?

A>в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так:
A>

A>TFigure = class
A>private
A>  function GetPerimetr(): real; virtual;
A>....

A>function TFigure.GetPerimetr(): real;
A>begin
A>  raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
A>end;
A>

А зачем? перенести compile-time проверку в runtime?

A>Теперь инвариант класса TFigure такой:
A>Все наследники обязаны иметь периметр. Вот и все, теперь это не интерфейс абсолютно. Еще раз: хорошая иерархия та, у которой суперкласс абстрактный и сами иерархии определяются тем, какие методы нужны будут.

Все равно я пока не вижу "иерархии", потому что на лице интерфейс и его реализации.

Аналогичные вещи, но гораздо более "красивым" способом можно получит в haskell.

Мне кажется, что все это бессмысленно, так как в каждом ООП языке свое ООП. Общая методолгия для меня совсем иное, нежели все сразу, что есть во всех языках. Скорее наборот — только то, что есть у большинства общепризнанных ООП языков. Общие черты, а не все в одном. Литературы море, в каждой свое ООП, стандарта нет. UML вообще иногда мозг взрывает, особенно как у Рембо с Блахой. Давайте прекратим бессмысленный спор. Для меня что-то между интерфейсом и классом имеющим реализацию методов называется классом. Наследование реализации == наследование классов, наследование декларации == наследованию интерфейсов. Как-то так.

Здравствуйте, Albatros, Вы писали:

A>НО! В этом примере суперкласс TFigure не является интерфейсом, хотя бы потому, что:
A>а — имеет свойства

Cупер! И ты хочешь что-то о типах писать?
Вам надо срочно изучить пару-тройку языков отличных от устаревших версий Дельфи.
Даже современные версии дельфи поддерживают свойства в интерфейсах. А уж разные там C#-ы и VB поддирживали их с рождения.

A>б — интерфейсы не поддерживают полиморфизма.

Прочитайте определение полиморфизма прежде чем делать подобные заявления.

A>Они при наследовании не получают и модифицируют фукционал, а параллельно дополняют. Здесь чистый полиморфизм.

После этих слов лично мне стало отчетливо ясно, что у вас ничего путного не выйдет. Вы не только имеете однобокие знания, основанные в основном на устаревших версиях Дельфи. Но даже в этих рамках вы умудряетесь делать феерично абсурдные суждения.

A>в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так:

A>

A>TFigure = class
A>private
A>  function GetPerimetr(): real; virtual;
A>....

A>function TFigure.GetPerimetr(): real;
A>begin
A>  raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
A>end;
A>

А этот, с позволения сказать код, скомпилируется? Неужели Дельфи допускает виртуальные private-методы?

Здравствуйте, samius, Вы писали:

S>Интерфейс как чисто абстрактный класс поддерживает полиморфизм

Почти уверен, что могут. Во-первых, Дельфи поддерживает дотнет где интерфейсы могут, а значит обязаны (для совместимости с другими языками) иметь свойства. Во-вторых, Дельфи начиная со второй версии поддерживает COM в котором так еж есть свойства.

A>>в — Поэтому этокласс с абстрактными методами. Можно сделать не абстрактный метод, а виртуальный, что еще лучше, например так:
S>Класс с абстрактными методами играет роль интерфейса.

+1

A>>

A>>TFigure = class
A>>private
A>>  function GetPerimetr(): real; virtual;
A>>....

A>>function TFigure.GetPerimetr(): real;
A>>begin
A>>  raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
A>>end;
A>>

S>Это ничего не меняет

По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.

Здравствуйте, Albatros, Вы писали:

A>Иерархия типов зависит от требуемых в системе методов. Поэтому любая, например:

A>

A>TMnogougolnik = class(TFigure)
A>T4Ugolnik = class(TMnogougolnik)
A>TRomb = class(T4Ugolnik)
A>TKvadrat = class(T4Ugolnik)
A>

Названия хороши!

Здравствуйте, samius, Вы писали:

S>А если многоугольнику нужно устанавливать набор координат?

Ну, как же? Пихнем массив. Ведь хорошо известно, что плохой дизайн всегда можно скрыть кучей подпорок и замазки.

Здравствуйте, VladD2, Вы писали:

VD> A>>

VD> A>>TFigure = class
VD> A>>private
VD> A>>  function GetPerimetr(): real; virtual;
VD> A>>....

VD> A>>function TFigure.GetPerimetr(): real;
VD> A>>begin
VD> A>>  raise Exception.Create('Нет реализации метода в ' + Self.ClassName);
VD> A>>end;
VD> A>>

VD> S>Это ничего не меняет

VD> По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.

Отчего же? В рамках одного модуля имеет смысл. Private это не строгий ограничитель, и на дружественные (находящиеся в одном модуле) он не действует. Для строгого ограничения (область класса) есть Strict Private.

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, samius, Вы писали:

s> Если в делфи интерфейсы не могут иметь свойства, то это не значит что так везде.

В дельфях интерфейсы вполне себе могут иметь свойства

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

S>>Интерфейс как чисто абстрактный класс поддерживает полиморфизм

VD>Почти уверен, что могут. Во-первых, Дельфи поддерживает дотнет где интерфейсы могут, а значит обязаны (для совместимости с другими языками) иметь свойства.
AFAIR это специальная версия делфи была для разработки под дотнет.

VD> Во-вторых, Дельфи начиная со второй версии поддерживает COM в котором так еж есть свойства.
Вроде бы интерфейсы в делфи перекочевали именно из поддержки COM-а

VD>По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.
Тоже глаз резануло, хотя на делфи до 5-ой версии работал. Нифига правда не помню о делфи кроме := и begin/end

Здравствуйте, VladD2, Вы писали:

VD> Причем тут модуль? Это модификатор доступа к члену класса. Виртуальный метод который нельзя переопределить смысла не имеет.

Еще раз. Private это нестрогий ограничитель. Он не закрывает члены класса от дружественных классов (располагающихся в одном с ним модуле).

avalon 1.0rc3 rev 380, zlib 1.2.3

Я честно не проверял, но уверен, что скомпелится. Это не стрикт приват. Хотя соглашусь, более грамотно в протектед. Я год просто на дельфях не работал, поэтому про свойства забыл у интерфейсов. Но ведь если есть свойства, следовательно могут быть сетеры и гетеры. А если еще, по вашему мнению, полиморфизм как у наследования классов, то чем они от классов отличаются?

Здравствуйте, samius, Вы писали:

VD>>Почти уверен, что могут. Во-первых, Дельфи поддерживает дотнет где интерфейсы могут, а значит обязаны (для совместимости с другими языками) иметь свойства.
S>AFAIR это специальная версия делфи была для разработки под дотнет.

Что значит была? Была, есть и с огромной вероятностью будет. И язык там один и тот же.

VD>> Во-вторых, Дельфи начиная со второй версии поддерживает COM в котором так еж есть свойства.
S>Вроде бы интерфейсы в делфи перекочевали именно из поддержки COM-а

Официально это не говорилось, но по началу поддерживались именно комовские.

VD>>По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.
S>Тоже глаз резануло, хотя на делфи до 5-ой версии работал. Нифига правда не помню о делфи кроме := и begin/end

Я тоже Дельфи в руки уже более 10 лет не брал. Но я не вижу как можно использовать приватные виртуальные методы.

Здравствуйте, hattab, Вы писали:

VD>> Причем тут модуль? Это модификатор доступа к члену класса. Виртуальный метод который нельзя переопределить смысла не имеет.

H>Еще раз. Private это нестрогий ограничитель. Он не закрывает члены класса от дружественных классов (располагающихся в одном с ним модуле).

Еще раз для танкистов. Private закрывает возможность переопределения метода наследниках. Так что virtual просто не имеет смысла.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, samius, Вы писали:

s>> Если в делфи интерфейсы не могут иметь свойства, то это не значит что так везде.

H>В дельфях интерфейсы вполне себе могут иметь свойства

Это была не моя мысль, что в них свойств нет

Здравствуйте, samius, Вы писали:

S>Там походу действительно private видим всему unit-у. Т.е. все классы unit-а друг другу friend-ы

S>А в версии 7 ввели strict private

Даже если так. Очень сомнительно что есть разумное объяснение применению динамического полиморфизма в рамках одного модуля. Этот вид полиморфизма нужен для расширяемых систем.

Что же касается дотнетной версии Дельфи, то в ней обеспечить дружественность типом можно только если они будут вложены друг в друга. Так что я не представляю как это может быть реализовано.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, samius, Вы писали:

S>>Там походу действительно private видим всему unit-у. Т.е. все классы unit-а друг другу friend-ы

S>>А в версии 7 ввели strict private

VD>Даже если так. Очень сомнительно что есть разумное объяснение применению динамического полиморфизма в рамках одного модуля. Этот вид полиморфизма нужен для расширяемых систем.

VD>Что же касается дотнетной версии Дельфи, то в ней обеспечить дружественность типом можно только если они будут вложены друг в друга. Так что я не представляю как это может быть реализовано.

Поглядел рефлектором — там IL internal трактуется как private, а IL private как strict private.

Здравствуйте, VladD2, Вы писали:

VD>Даже если так. Очень сомнительно что есть разумное объяснение применению динамического полиморфизма в рамках одного модуля. Этот вид полиморфизма нужен для расширяемых систем.

Нормальное это поведение доступ к приватным полям в модуле. Напнример для контейнеров и элементов контейнеров — это частая практика. Если мешает — strict protected и strict private решают проблему. Это особенно часто используется для написания компонентов — изоляция кода компонента от программистов его использующих. Т.е. разраюотчик компонентов пишет приоткрытый код в модуле, получает доступ, а пользователи — нет. Написали бы там библиотеку компонентов — знали бы что это и с чем едят.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, VladD2, Вы писали:

VD>>Даже если так. Очень сомнительно что есть разумное объяснение применению динамического полиморфизма в рамках одного модуля. Этот вид полиморфизма нужен для расширяемых систем.

A>Нормальное это поведение доступ к приватным полям в модуле.
Если бы это было нормально, так было бы везде, а не только в delphi

A>Написали бы там библиотеку компонентов — знали бы что это и с чем едят.
Вы полагаете что в философии сидят непрактикующие философы, которые не знают как с private (strict) библиотеки создавать?

Здравствуйте, Albatros, Вы писали:

A> Я честно не проверял, но уверен, что скомпелится. Это не стрикт приват. Хотя соглашусь, более грамотно в протектед. Я год просто на дельфях не работал, поэтому про свойства забыл у интерфейсов. Но ведь если есть свойства, следовательно могут быть сетеры и гетеры. А если еще, по вашему мнению, полиморфизм как у наследования классов, то чем они от классов отличаются?

Это точно мне вопрос? Ну да, у интерфейсов есть свойства, но они, в отличии от свойств классов/объектов, могут быть объявлены только с сеттером/геттером которые будут являться методами интерфейса.

Абстрактный класс и интерфейс это далеко не одно и то же. Абстрактный класс может являться одним из ранних предков в иерархии, а интерфейс это просто контракт, который можно исполнить. То есть, реализация интерфейса вообще ни как не связана с наследованием, в отличии от абстрактного класса.

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, VladD2, Вы писали:

VD> VD>>Почти уверен, что могут. Во-первых, Дельфи поддерживает дотнет где интерфейсы могут, а значит обязаны (для совместимости с другими языками) иметь свойства.

VD> S>AFAIR это специальная версия делфи была для разработки под дотнет.

VD> Что значит была? Была, есть и с огромной вероятностью будет. И язык там один и тот же.

Язык там другой. Вот в Delphi for NET язык был такой же, а в призме он другой.

VD> VD>>По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.

VD> S>Тоже глаз резануло, хотя на делфи до 5-ой версии работал. Нифига правда не помню о делфи кроме := и begin/end

VD> Я тоже Дельфи в руки уже более 10 лет не брал. Но я не вижу как можно использовать приватные виртуальные методы.

Оно и видно. Впрочем, это было возможно во всех версиях.

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, samius, Вы писали:

s>> A>Нормальное это поведение доступ к приватным полям в модуле.

s>> Если бы это было нормально, так было бы везде, а не только в delphi

H>В Ada точно так же, там Private-члены видным всему пакету. Это вообще-то вполне логично

Перечислить языки, где не точно так же?
Интересно увидель логику, согласно которой private объявление класса дает видимость уровня модуля.

s>> A>Написали бы там библиотеку компонентов — знали бы что это и с чем едят.

s>> Вы полагаете что в философии сидят непрактикующие философы, которые не знают как с private (strict) библиотеки создавать?

H>Я так в этом теперь и не сомневаюсь

Очевидно как и в том, что библиотеки можно создавать только на delphi

видимо речь о "private part of the package declaration", т.е. о типах, а не о членах класса/записи? В общем, в ADA не точно так же.

Здравствуйте, Albatros, Вы писали:

A>Нормальное это поведение доступ к приватным полям в модуле. Напнример для контейнеров и элементов контейнеров — это частая практика. Если мешает — strict protected и strict private решают проблему. Это особенно часто используется для написания компонентов — изоляция кода компонента от программистов его использующих. Т.е. разраюотчик компонентов пишет приоткрытый код в модуле, получает доступ, а пользователи — нет. Написали бы там библиотеку компонентов — знали бы что это и с чем едят.

Да, все выяснилось. Просто в дельфи как всегда все не как у всех.

Здравствуйте, samius, Вы писали:

s> s>> A>Нормальное это поведение доступ к приватным полям в модуле.

s> s>> Если бы это было нормально, так было бы везде, а не только в delphi

s> H>В Ada точно так же, там Private-члены видным всему пакету. Это вообще-то вполне логично

s> Перечислить языки, где не точно так же?

В этих языках есть понятие пакета/модуля?

s> Интересно увидель логику, согласно которой private объявление класса дает видимость уровня модуля.

А логика проста. Модуль есть функциональная единица. Классы объявленные в модуле являются (в общем случае) реализацией его функциональности.

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, samius, Вы писали:

H>>>В Ada точно так же, там Private-члены видным всему пакету. Это вообще-то вполне логично

s>> Перечислить языки, где не точно так же?

H>В этих языках есть понятие пакета/модуля?
Во многих

s>> Интересно увидель логику, согласно которой private объявление класса дает видимость уровня модуля.

H>А логика проста. Модуль есть функциональная единица. Классы объявленные в модуле являются (в общем случае) реализацией его функциональности.
... поэтому "private" внутри класса открывает доступ на уровне модуля вопреки тому как это принято. Я верно понял логику?

Здравствуйте, hattab, Вы писали:

H>Абстрактный класс и интерфейс это далеко не одно и то же. Абстрактный класс может являться одним из ранних предков в иерархии, а интерфейс это просто контракт, который можно исполнить. То есть, реализация интерфейса вообще ни как не связана с наследованием, в отличии от абстрактного класса.

Это называется наследование интерфейса.

В научных работах вообще говорят исключительно о подтипах. С точки зрения подтипа совершенно фиолетово интерфейс это или класс. Главное, что некоторый объект можно рассматривать как некоторый (другой) тип.

Здравствуйте, hattab, Вы писали:

H>В Ada точно так же, там Private-члены видным всему пакету. Это вообще-то вполне логично

Это не нормально с точки зрения языка (английского). Модификаторы доступа задаются для членов класса, но почему-то рассматриваются на уровне модуля. Было бы логично ввести модификтатор module private.

Здравствуйте, hattab, Вы писали:

H>В этих языках есть понятие пакета/модуля?

Да, сборки.

Здравствуйте, VladD2, Вы писали:

VD> H>Абстрактный класс и интерфейс это далеко не одно и то же. Абстрактный класс может являться одним из ранних предков в иерархии, а интерфейс это просто контракт, который можно исполнить. То есть, реализация интерфейса вообще ни как не связана с наследованием, в отличии от абстрактного класса.

VD> Это называется наследование интерфейса.

Класс от интерфейса не наследуется

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, VladD2, Вы писали:

VD> Это не нормально с точки зрения языка (английского). Модификаторы доступа задаются для членов класса, но почему-то рассматриваются на уровне модуля. Было бы логично ввести модификтатор module private.

Трактовка Private достаточно широкая. Как один из вариантов — "закрытый, не являющийся доступным для всех" (c) Apresyan.

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, samius, Вы писали:

s> H>А логика проста. Модуль есть функциональная единица. Классы объявленные в модуле являются (в общем случае) реализацией его функциональности.

s> ... поэтому "private" внутри класса открывает доступ на уровне модуля вопреки тому как это принято. Я верно понял логику?

Не правильно. Не вопреки. Модуль это более крупная единица инкапсуляции нежели класс. Тебя же не смущает, что в C# вложенные классы имеют доступ к закрытым членам класса-владельца? Аналогично и с модулем, только свободы еще больше.

avalon 1.0rc3 rev 380, zlib 1.2.3

s> видимо речь о "private part of the package declaration", т.е. о типах, а не о членах класса/записи? В общем, в ADA не точно так же.

Там просто другая идеология ООП. Поэтому прямой кальки и не получится. Но там есть внутренние пакеты, дочерние пакеты (расширяющие родительский и имеющие доступ к закрытым членам).

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, samius, Вы писали:

s>> H>А логика проста. Модуль есть функциональная единица. Классы объявленные в модуле являются (в общем случае) реализацией его функциональности.

s>> ... поэтому "private" внутри класса открывает доступ на уровне модуля вопреки тому как это принято. Я верно понял логику?

H>Не правильно. Не вопреки. Модуль это более крупная единица инкапсуляции нежели класс. Тебя же не смущает, что в C# вложенные классы имеют доступ к закрытым членам класса-владельца? Аналогично и с модулем, только свободы еще больше.
Правильно, вопреки. В паскаль тащили ООП гораздо позже, чем устоялись термины.

в C# такая свобода существует и называется internal, в java — package. А в делфи она называется тем словом, которым принято обозначать другой уровень видимости.

И логики в этом походу не больше, чем в том что List-ом в дотнет называют динамический массив.

Здравствуйте, hattab, Вы писали:

VD>> Это называется наследование интерфейса.

H>Класс от интерфейса не наследуется

Тебя случаем не Компиатн Очевидность завут? Какое это имеет отношение к делу?

Здравствуйте, samius, Вы писали:

s> H>Не правильно. Не вопреки. Модуль это более крупная единица инкапсуляции нежели класс. Тебя же не смущает, что в C# вложенные классы имеют доступ к закрытым членам класса-владельца? Аналогично и с модулем, только свободы еще больше.

s> Правильно, вопреки. В паскаль тащили ООП гораздо позже, чем устоялись термины.

s> в C# такая свобода существует и называется internal, в java — package. А в делфи она называется тем словом, которым принято обозначать другой уровень видимости.

Это слово трактуется весьма широко. Еще раз напомню тебе, что в C# nested types имеют доступ к private членам класса владельца. У тебя диссонанса не случается от этого?

s> И логики в этом походу не больше, чем в том что List-ом в дотнет называют динамический массив.

List это абстракция. Детали реализации (list as dynamic array) это детали реализации. У нас ОПП или где?

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

VD>> Это не нормально с точки зрения языка (английского). Модификаторы доступа задаются для членов класса, но почему-то рассматриваются на уровне модуля. Было бы логично ввести модификтатор module private.

H>Трактовка Private достаточно широкая. Как один из вариантов — "закрытый, не являющийся доступным для всех" (c) Apresyan.

Что это меняет? По факту то он получается открытым для других типов.

В общем, мне этот спор не интересен. Всем кто считает такое именование нормальным счастливо оставаться со своим мнением.

Здравствуйте, VladD2, Вы писали:

VD> H>Трактовка Private достаточно широкая. Как один из вариантов — "закрытый, не являющийся доступным для всех" (c) Apresyan.

VD> Что это меняет? По факту то он получается открытым для других типов.

В рамках одного модуля и только.

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, VladD2, Вы писали:

VD>По-моему — это просто бред какой-то. Приватный виртуальный метод — это нонсенс.

private в Делфи имеет такойже коэффициент кривизны как и internal в дотнете.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, samius, Вы писали:

s>> Так широко оно трактуется только в делфи.

H>В английском языке.
Я про языки программирования

s>> H>Еще раз напомню тебе, что в C# nested types имеют доступ к private членам класса владельца. У тебя диссонанса не случается от этого?

s>> Нет.

H>А должен бы...

Нет, не должен. Внутри класса доступно все что там объявлено. И границы объявления класса ограничивают видимость private. Это логично.

s>> H>List это абстракция. Детали реализации (list as dynamic array) это детали реализации. У нас ОПП или где?

s>> Если чо, то ты назвал абстракцией класс, где нет ни одного виртуального метода.

H>Опять ты с деталями... Я говорю о List (о боже, не о дотнетовском List, а вообще), как об абстракции, а ты все в детали реализации лезешь. Зачем?
А я заговорил о List как о реализации. Причем тут абстракции? Я о том, что есть структура данных Список, и логично было бы предположить что List имеет к нему отношение. Абстракцию не следует называть терминами, широко употребляемыми для других, более конкретных целей.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, VladD2, Вы писали:

VD>> VD>> Это называется наследование интерфейса.

VD>> H>Класс от интерфейса не наследуется

VD>> Тебя случаем не Компиатн Очевидность завут? Какое это имеет отношение к делу?

H>Что в имени тебе моем? Такое и имеет, что реализация интерфейса не есть наследование интерфейса

Или о чем ты?

А в чём, по-твоему, значимая разница? И то, и другое просто исторически сложившиеся названия для подтипирования, о чём тебе Влад и писал.

Здравствуйте, deniok, Вы писали:

d> VD>> Тебя случаем не Компиатн Очевидность завут? Какое это имеет отношение к делу?

d> H>Что в имени тебе моем? Такое и имеет, что реализация интерфейса не есть наследование интерфейса

Или о чем ты?

d> А в чём, по-твоему, значимая разница? И то, и другое просто исторически сложившиеся названия для подтипирования, о чём тебе Влад и писал.

Наследование интерфейса произойдет, если класс будет унаследован от предка реализующего интерфейс. Реализация интерфейса может быть нескольких видов, когда класс сам реализует контракт, когда наследует реализацию (реализация наследованием), когда использует механизмы агрегации и делегирования. Очевидно по моему

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, samius, Вы писали:

s> s>> Так широко оно трактуется только в делфи.

s> H>В английском языке.

s> Я про языки программирования

Отлично. Слово Private оно родом из какого языка программирования?

s> s>> H>Еще раз напомню тебе, что в C# nested types имеют доступ к private членам класса владельца. У тебя диссонанса не случается от этого?

s> s>> Нет.

s> H>А должен бы...

s> Нет, не должен. Внутри класса доступно все что там объявлено. И границы объявления класса ограничивают видимость private. Это логично.

Чудно. Вот теперь раздвинь границы класса, до границ модуля. И получается... Внутри модуля доступно все, что там объявлено. И границы модуля ограничивают видимость приватных членов классов. И в качестве дополнения: а модификатор Strict Private позволяет обозначить границы видимости внутри класса.

Я же говорю, свободы больше.

s> H>Опять ты с деталями... Я говорю о List (о боже, не о дотнетовском List, а вообще), как об абстракции, а ты все в детали реализации лезешь. Зачем?

s> А я заговорил о List как о реализации. Причем тут абстракции? Я о том, что есть структура данных Список, и логично было бы предположить что List имеет к нему отношение. Абстракцию не следует называть терминами, широко употребляемыми для других, более конкретных целей.

Так List это одна из ключевых абстракций АТД

То, что он так реализован в дотнете, личное дело дотнета, и приводить оную реализацию в качестве аналогии к якобы неправильности семантики модификатора Private, как-то уж очень своеобразно... Как будто ты обладаешь знанием о том, каким именно образом должна быть реализована абстракция List

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, samius, Вы писали:

s>> H>В английском языке.

s>> Я про языки программирования

H>Отлично. Слово Private оно родом из какого языка программирования?

Полагаю что первым его задействовали для сокрытия членов класса в Simula

s>> Нет, не должен. Внутри класса доступно все что там объявлено. И границы объявления класса ограничивают видимость private. Это логично.

H>Чудно. Вот теперь раздвинь границы класса, до границ модуля. И получается... Внутри модуля доступно все, что там объявлено. И границы модуля ограничивают видимость приватных членов классов. И в качестве дополнения: а модификатор Strict Private позволяет обозначить границы видимости внутри класса.

Я же говорю, свободы больше.

Не надо ничего раздвигать. Модификаторы видимости по умолчанию описывают видимость вложенных вещей по отношению к непосредственно содержащей части. Так модификаторы public, protected и private типично описывают видимость членов класса по отношению к классу же. И только в делфи private описывает видимость по отношению к модулю. Это при том, что понятие модуля в ООП не формализовано.

Мне надоело что-то доказывать. Если не лень — сравни проценты популярности языков, использующих private в том и ином смысле. И ты увидишь, какой смысл является общепринятым.

s>> А я заговорил о List как о реализации. Причем тут абстракции? Я о том, что есть структура данных Список, и логично было бы предположить что List имеет к нему отношение. Абстракцию не следует называть терминами, широко употребляемыми для других, более конкретных целей.

H>Так List это одна из ключевых абстракций АТД

Во, другое дело. Я тоже когда вижу List, то подразумеваю именно то, на что ты дал ссылку. (Качество материала, правда не радует. Пишут что множество конечное и тут же приводят в пример Haskell, где список может и не являтсья конечным)

H>То, что он так реализован в дотнете, личное дело дотнета, и приводить оную реализацию в качестве аналогии к якобы неправильности семантики модификатора Private, как-то уж очень своеобразно...
Именно то же я могу сказать и о делфи — что личное дело делфи, как реализовывать видимость при указании модификатора private. Общепринятым же считается ограничение области видимости классом.

H>Как будто ты обладаешь знанием о том, каким именно образом должна быть реализована абстракция List

Конечно. Определение по твоей же ссылке:

Первая строка данного определения обозначает, что список элементов типа A (говорят: «список над A») представляет собой размеченное объединение пустого списка и декартова произведения атома типа A со списком над A.

Какие тут могут быть кривотолки? Тут разве написано что-то про массив?

Здравствуйте, samius, Вы писали:

A>>Нормальное это поведение доступ к приватным полям в модуле.
S>Если бы это было нормально, так было бы везде, а не только в delphi
Нужно понимать, что Delphi вырос из Паскаля, в котором границы областей видимости были чётко связаны с unit задолго до вкорячивания в него OOP.
Именно опыт с Delphi и прочими языками привёл в конечном итоге к обобщённой модели access modifiers, принятой в дотНет.

Здравствуйте, hattab, Вы писали:

H>Здравствуйте, deniok, Вы писали:

d>> VD>> Тебя случаем не Компиатн Очевидность завут? Какое это имеет отношение к делу?

d>> H>Что в имени тебе моем? Такое и имеет, что реализация интерфейса не есть наследование интерфейса

Или о чем ты?

d>> А в чём, по-твоему, значимая разница? И то, и другое просто исторически сложившиеся названия для подтипирования, о чём тебе Влад и писал.

H>Наследование интерфейса произойдет, если класс будет унаследован от предка реализующего интерфейс. Реализация интерфейса может быть нескольких видов, когда класс сам реализует контракт, когда наследует реализацию (реализация наследованием), когда использует механизмы агрегации и делегирования. Очевидно по моему

Мне не очевидно. Я не вижу, чем понятие интерфейса отличается от понятия базового класса (с некоторыми требованиями к его уровню абстрактности) + разрешения делать множественное наследование от таких базовых классов. Собственно оно (понятие интерфейса) оттуда и возникло.

Здравствуйте, samius, Вы писали:

S>Здравствуйте, Sinclair, Вы писали:

S>>Здравствуйте, samius, Вы писали:

S>>>http://stackoverflow.com/questions/1334451/history-of-public-private-protected
S>>Ещё раз: концепция публичности/приватности появилась в Паскале в незапамятные времена.
S>Она там не могла появиться раньше симулы. Может быть в ADA?
Симула ни при чём. Вы понимаете, что речь идёт про тот Паскаль, в котором не было ООП?
S>Я имел дело с паскалем и делфи около 7и лет в том веке.
Это хорошо для вас. Я начал года на 3 раньше.

S>Да, я понимаю мотивы внесения в таком виде. Но было бы разумнее выбрать другое слово, а не вносить потом strict. Сам факт его внесения свидетельствует о том, что модель была неудачная.
Выбирали одни люди, в 1980х, а вносили другие, через 25 лет. О чём вы говорите?

S>Я не считаю модель доступа C++ идеальной. Но границу доступа там можно проводить набором заголовков, что и является обычной практикой.
Покажите мне access modifier в С++, который позволяет провести границу доступа по набору заголовков. Обычной практикой всё же является public/private, а не #ifdef _included_from_same_assembly_

S>Все что я пытаюсь доказать — это то, что модель, в которой private ограничен уровнем модуля не является нормой для ООП.
Зато является нормой для модульного программирования.
А ещё Private — это такая порностудия. Какие выводы можно из этого сделать?
Я думаю, такие же, как и из того, raise и throw в разных языках значат одно и то же: ключевые слова контекстно-зависимы. Не имеет смысла объяснять японцам то, что им не стоило называть гору ямой.

Здравствуйте, Albatros, Вы писали:

A>Мне дельфи нравится, очень, больше, чес C#. Я его знаю наизусть, у меня компоненты правили исходники во время проектирования программы. Поэтому примеры на дельфях. На .NET и C# легче писать проги, но он чисто ООП язык. А дельфи гибридный язык, сохраняет императивный синтаксис и процедурный подход в программировании.
Вообще-то С# тоже гибридный. Негибридов в наше время, наверное, уже и не осталось. Ну, разве что джава в версиях примерно так 1.3.

A>Не всЁ в жизни является объектами. Число 7 мне трудно представить как объект. Пример: сложить объект Семи с Объектом трех получим объект десяти!!! Что за чушь!
Ну, это вы зря. В том смысле, что тройки и семёрки не ведут себя как объекты — это правда. Но эмулировать поведение value-типов на ООП можно. См. например smalltalk. Главное — иметь в виду, что существует ровно один объект, соответствующий числу 7, вечный и неизменный. Тогда никакой чуши — посылаем объекту 7 сообщение "прибавь объект 3", он возвращает нам объект 10.
И объект 5, получив сообщение "прибавить объект 5" получает тот же самый объект 5, и возвращает ровно тот же объект 10, что и в примере с 7+3.
То есть у нас нет проблемы различения эквивалентности по ссылке и по значению.
Попытки моделировать арифметику на изменяемых объектах, конечно же обречены на провал. В результате получаем, что это, конечно же, не ООП — из трёх основ мы от двух отказываемся.

Вообще, арифметику можно эмулировать практически на чём угодно. К примеру, можно на чистых функциях (если язык поддерживает функции как первоклассные сущности).

A>Для инженерных прикладных задач ООП не годится. В полной 3 главе будет обоснование этого.
Интересно. С нетерпением жду узнать, что же годится для инженерных и прикладных задач.

Здравствуйте, Sinclair, Вы писали:

S>Непонятно. Как раз разные реализации методов и подразумеваются. Попробуйте подразуметь некую "одинаковую" реализацию метода произвольного интерфейса в любом современном ООЯ.
S>К примеру, в COM, где наследования вовсе нет, интерфейсы представляют собой единственный способ поддержки полиморфизма.

Уточню как я понимаю интерфейсы внутри языка программирования(а не как механизм межпроцессного взаимодействия). Для меня это перечень методов(св-ва тоже можно выражать в виде декларации методов, т.е. методы называть как свойства в виде, например, существительного), декларация. Оно же ведь называется интерфейсом!. Как правильно кто-то тут сказал, это можно назвать контрактом.
Реализации методов в интерфейсах для меня нет. Полиморфизм — полиповедение, разное поведение, т.е. разная реализация одного и того же метода. Наследования интерфейсов с поддержкой полиморфизма(разной реализации виртуальных методов) в иерархии интерфейсов нет. Есть включение(агрегация) деклараций методов наследниками. Интерфейсы другие интерфейсы не реализуют.
Класс — уже совсем другое. Там идет реализация поведения, поэтому там наследование с полиморфизмом. Класс-наследник может менять поведение класса-предка в рамках инварианта(контракта). Вот так наиболее четкое описание разницы между интерфейсом и классом языка программирования..

Здравствуйте, Sinclair, Вы писали:

S>Тогда никакой чуши — посылаем объекту 7 сообщение "прибавь объект 3", он возвращает нам объект 10.

S>Интересно. С нетерпением жду узнать, что же годится для инженерных и прикладных задач.

В статье будет это разжевано. Уже есть текст. Как выложить с заявкой на публикацию не знаете?

Здравствуйте, VladD2, Вы писали:

VD>Еще раз для танкистов. Private закрывает возможность переопределения метода наследниках. Так что virtual просто не имеет смысла.

От языка зависит, в C++ не закрывает и даже является одной из достаточно широко используемых идиом:

#include <iostream>
#include <memory>

using namespace std;

class Base
{
public:
    virtual ~Base()
    {
    }
    
    void Proccess()
    {
    DoProccess();
    }
    
private:
    virtual void DoProccess()
    {
    cout << "Base" << endl;
    }
};


class Derive : public Base
{
private:
    virtual void DoProccess()
    {
    cout << "Derive" << endl;
    }
};


int main()
{
auto_ptr<Base> a(new Base);
a->Proccess();

a.reset(new Derive);
a->Proccess();
}

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, samius, Вы писали:
S>>Да, и в нем не было слова private, были только секции interface/implementation, некие аналоги h,c файлов.
S>Вы лучше такие аналогии не применяйте. ...
S>Паскаль, в отличие от С, имел нормальную модульную архитектуру. С поддержкой, естественно, метаданных.
Это ход в сторону. private таки не было в паскале.

S>>О том что другие люди таки посчитали что область видимости private слишком широка.
S>Они не считали. Они просто сделали новое поколение языка, перед которым поставили другие задачи.
На момент введения strict никакое новое поколение не создавалось. Ввели его если не ошибаюсь, в Delphi 7. Сам не щупал, но где-то в инете видел. Да и интеграцией с дотнетом тогда не пахло.

S>>Я отвечал на это
S>>

S>>К примеру, нет поддержки "модулей" с несколькими классами — а с ней и возможностей провести по ним границу доступа.

S>>В том плане что несколько классов можно определить в одном header-е. Аналогия не полная, но границы доступа определять позволяет.
S>Аналогия вообще никакая. То, что несколько классов случайно оказались в одном хидере, это даже не часть языка. Нет никакого способа сказать, какой класс пришёл из какого хидера — как только я написал список инклюдов, начинается свальный грех.
S>Именно поэтому нет никакого ключевого слова вроде "header internal", которое бы позволило дать доступ к мемберу классам из "того же хидера".
Я писал лишь о границе доступа на уровне классов. Никаких "header internal" не подразумевал.

S>>разве в оригинальном паскале было слово private?
S>В TP 5.0 — было. Хейльсберг поставил перед собой задачу сделать язык, пригодный для изучения ООП. Он гордился тем, что добился этого всего четырьмя ключевыми словами. То, что вы предлагаете, означало как минимум на 20% больше новых ключевых слов.
Я ничего не предлагаю. Я говорю что это нехарактерно для ООП.
Кстати, ОО было в TP 5.5. А до него private не было (почти уверен).

S>(Вздыхает). То, что вы называете "oбычно" — продукт совсем другой эпохи. В 1989 никаких "обычно" ещё не было. В том же году в С++ добавили access modifier protected. В Simula никаких private не было.
Было, в Simula 87, и ранее в TOPS-10. До тех пор в Simula был hidden.

S>А в наши дни, конечно же, использовать Delphi для примеров в статьях не про Delphi — неожиданно. Тем более при рассуждении о типизации — дельфийская система типов изобилует причудливыми странностями ничуть не меньше, чем древнеэльфийский у JRRT.
+1

Здравствуйте, gandjustas, Вы писали:

G>Ты полную чушь говоришь.

Похоже он имеет в виду это:

unit Foo;

interace 

{ вот эту секцию }

implementation


initialization


finalization

end;

Здравствуйте, samius, Вы писали:

S>>Они не считали. Они просто сделали новое поколение языка, перед которым поставили другие задачи.
S>На момент введения strict никакое новое поколение не создавалось. Ввели его если не ошибаюсь, в Delphi 7. Сам не щупал, но где-то в инете видел. Да и интеграцией с дотнетом тогда не пахло.

strict private (вместе с перегрузкой операторов, sealed, вложенными типами и прочим) ввели в Delphi 2007 именно в связи с поддержкой .NET-а.

Здравствуйте, hardcase, Вы писали:

H>Здравствуйте, samius, Вы писали:

S>>>Они не считали. Они просто сделали новое поколение языка, перед которым поставили другие задачи.
S>>На момент введения strict никакое новое поколение не создавалось. Ввели его если не ошибаюсь, в Delphi 7. Сам не щупал, но где-то в инете видел. Да и интеграцией с дотнетом тогда не пахло.

H>strict private (вместе с перегрузкой операторов, sealed, вложенными типами и прочим) ввели в Delphi 2007 именно в связи с поддержкой .NET-а.
Да, я неверно истолковал информацию

Здравствуйте, hardcase, Вы писали:

h> strict private (вместе с перегрузкой операторов, sealed, вложенными типами и прочим) ввели в Delphi 2007 именно в связи с поддержкой .NET-а.

Вообще-то в 2005

avalon 1.0rc3 rev 380, zlib 1.2.3

Здравствуйте, FR, Вы писали:

FR>Во первых этот private на самом деле protected, то есть потомки видят private методы предков, и virtual private вполне нормально.

Ну, да если private самом деле protected, то на самом деле обсуждать тут нечего, кроме (разве что) фееричного мышления авторов языка.

Видимо по этому в ОКамле и используют модули вместо классов.

FR>Во вторых private относится к объекту а не к классу и поэтому объекты одного и того же класса не могут копаться у друг друга в кишках.

Я правильно понимаю, что в ОКамле тип — это что-то вроде интерфейса?

Здравствуйте, VladD2, Вы писали:

FR>>Во первых этот private на самом деле protected, то есть потомки видят private методы предков, и virtual private вполне нормально.

VD>Ну, да если private самом деле protected, то на самом деле обсуждать тут нечего, кроме (разве что) фееричного мышления авторов языка.

Тык французы

VD>Видимо по этому в ОКамле и используют модули вместо классов.

Ну я бы не сказал. ОО система там вполне неплохая, хоть и своеобразная.

FR>>Во вторых private относится к объекту а не к классу и поэтому объекты одного и того же класса не могут копаться у друг друга в кишках.

VD>Я правильно понимаю, что в ОКамле тип — это что-то вроде интерфейса?

Там структурная типизация притом она применятся непосредственно
к объектам, а класс практически чистый сахар ну и для наследования, ну и интерфейсы для структурной типизации также становятся не
нужными.

Здравствуйте, FR, Вы писали:

FR>Там структурная типизация притом она применятся непосредственно к объектам, а класс практически чистый сахар ну и для наследования, ну и интерфейсы для структурной типизации также становятся не нужными.

Ну, да. Туплю. Слишкмо привык к номинальной системе типов. Как грится когда в руках молоток, все вокруг кажется гвоздем.

Здравствуйте, Sinclair, Вы писали:

S>Нужно понимать, что Delphi вырос из Паскаля, в котором границы областей видимости были чётко связаны с unit задолго до вкорячивания в него OOP.
S>Именно опыт с Delphi и прочими языками привёл в конечном итоге к обобщённой модели access modifiers, принятой в дотНет.

Я может бы плохо помню Паскаль тех времен, но я упорно не могу припомнить в нем никаких модификаторов доступа. В Паскале была секция interface где описывались публикуемые функции и переменный. А вот никаких модификаторов доступа я припомнить (до появления ОбжектПаскаля) не могу.

Так что или нужно ткнуть меня носом в описание модификаторов доступа в до ОбжектПаскалевскую эру, или отбросить твою аргументацию как не верную.

Здравствуйте, Sinclair, Вы писали:

S>К примеру, в COM, где наследования вовсе нет, интерфейсы представляют собой единственный способ поддержки полиморфизма.

+1 И перегрузки тоже нет, а полиморфизм на лицо.

Здравствуйте, hardcase, Вы писали:

H>Похоже он имеет в виду это:
H>

H>unit Foo;
H>interace 

H>{ вот эту секцию }

H>implementation
H>initialization
H>finalization
H>end;
H>

Вроде нет, так как рядом он говорил о списке методов и включении методов (при наследовании интерфейсов).

Здравствуйте, VladD2, Вы писали:

VD>Так что или нужно ткнуть меня носом в описание модификаторов доступа в до ОбжектПаскалевскую эру, или отбросить твою аргументацию как не верную.
Добавлены в TP 5.5, в 1989 году, вместе с ключевыми словами object и virtual.

Здравствуйте, FR, Вы писали:

VD>>Еще раз для танкистов. Private закрывает возможность переопределения метода наследниках. Так что virtual просто не имеет смысла.

FR>От языка зависит, в C++ не закрывает и даже является одной из достаточно широко используемых идиом:

Почему для этой цели не используется protected?

Здравствуйте, Albatros, Вы писали:

A>>>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов.
G>>Берешь интерфейс IA с методом X и реализуешь его в 20 разных классах. Потом обращаешься к ссылке с типом IA — вот тебе полиморфизм.

A>Мой опыт — вот единственная гарантия знаний, очередной раз убеждаюсь, что бумажки ничего не означают.

Уважаемый бывший препод МГТУ, какой конкретно ваш опыт опровергает полиморфизм через интерфейсы? Это самое чистое проявление полиморфизма, которое только можно себе представить.

Здравствуйте, Ziaw, Вы писали:

FR>>От языка зависит, в C++ не закрывает и даже является одной из достаточно широко используемых идиом:

Z>Почему для этой цели не используется protected?

Потому что он не подходит, так как позволяет вызывать DoProccess из наследников,

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Albatros, Вы писали:

A>>>Полиморфизм — полиповедение, разное поведение, т.е. разная реализация одного и того же метода.

G>>Наверное стоит начать отсюда

G>>Или отсюда
A>А вы, уважаемый, не думали, что речь там идет о интерфейсе класса, а не о чистом интерфесе? Да и википедия не самый авторитетный источник

А ваша этимология слова полиморфизм кажется притянута за уши, как у Задорнова.

Здравствуйте, Sinclair, Вы писали:

VD>>Так что или нужно ткнуть меня носом в описание модификаторов доступа в до ОбжектПаскалевскую эру, или отбросить твою аргументацию как не верную.
S>Добавлены в TP 5.5, в 1989 году, вместе с ключевыми словами object и virtual.

То есть добавлены для поддержки ООП?

Ну, так а что ты там про наследие былых времен то рассказывал?

Банальная ошибка дизайна. У Хейльсберга их всегда много было. Вот тот object, например. Только от него вовремя отказались, а от странного применения privat — нет.

Здравствуйте, Albatros, Вы писали:

VD>>Не обижайтесь, но вам явно рано писать статьи на тему типов данных. Добавьтве в название слово Delphi и многие претензии к вам предъявляться не будут.

VD>>Тема типов данных — это очень не простая научная тема. Описать ее просто и при этом правильно очень не просто.

A>Такие высказывания необходимо обосновывать. Голословные утверждения — известный всем признак необразованности.

У меня ощущение, что вы с самого начала троллите.

Но я так боюсь показаться невеждой, что готов обосновать все свои утверждения.

Какое из двух приведенных утверждений я должен обосновать?

Здравствуйте, VladD2, Вы писали:

VD>Банальная ошибка дизайна. У Хейльсберга их всегда много было. Вот тот object, например. Только от него вовремя отказались, а от странного применения privat — нет.
А что, уже отказались? В 2000-х Delphi поддерживал object в полный рост. Вся семантика была обратно совместимой.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Albatros, Вы писали:

A>>>Еще раз повторю: интерфесы не поддерживают полиморфизма, так как они, хотябы, не подразумевают разных реализаций методов.
G>>Это полная чушь. Берешь интерфейс IA с методом X и реализуешь его в 20 разных классах. Потом обращаешься к ссылке с типом IA — вот тебе полиморфизм.

A>>>Наследования интерфейсов нет.

G>>

G>>intarface IA {}
G>>intarface IB:IA {}
G>>

A>>>Не путайте твердое с мягким.
G>>Ты полную чушь говоришь.

A>Вы смешали как раз твердое с мягким. Взяли и в наследовании класса указали, что он реализует интерфейс. Это стандартное ИСПОЛЬЗОВАНИЕ интерфейсов, НО НЕ НАСЛЕДОВАНИЕ ИНТЕРФЕЙСОВ ИНТЕРФЕЙСАМИ! У интерфейсов нет наследования, есть композиция.
Выше код показывает наследование интерфейсов. В спецификации языка C# можешь посмотреть, оно именно наследованием называется. Для COM тоже есть наследование интерфейсов, для java есть, опять-таки судя по спецификации.

Композиция это вообще не то. Композиция это когда один код пользуется другим кодом для реализации своей функциональности.
Например так:

class A
{
    private IB b;
    void C()
    {
        b.C();
    }
}

A>Если угодно, если мех-м хотим называть наследованием, то наследование у интерфейсов совсем другое, нежели у классов. Есть наследование деклараций(это интерфейсы), а есть наследование деклараций + реализаций(это уже у классов).
Тоже неверно. В С++ есть наследование реализации без наследования интерфейса.

A>Переопределение реализаций — это обеспечение полиморфизма, ИМЕННО РАЗНОЕ ПОВЕДЕНИЕ, за счет изменения существующих уже реализаций виртуальных методов. У интерфесов нет реализаций, поэтому сами по себе они полиморфизма в понятиях, как у классов, не поддерживают. Есть только использование интерфейса как типа данных, это можно назвать НЕОБЕСПЕЧЕННЫМ ПОЛИМОРФИЗМОМ.
Ты сначала определение полиморфизма изучи, а то "необеспеченный полиморфизм" тут никто не поймет.

A>Неужели это трудно понять, имея столько приблудов сертификационных? Я, бывший препод программирования в МГТУ, и то могу это понять, без сертификатов. Мой опыт — вот единственная гарантия знаний, очередной раз убеждаюсь, что бумажки ничего не означают.

Ты в этом посте три раза выдумал определения, которых я больше нигде не встречал. Приведи в порядок терминологию, иначе тебя вообще никто не поймет.
Ссылки про полипорфизм я уже дал. Также стоит почитать спецификации языков, хотябы по-диагонали. Узнаешь много нового.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, FR, Вы писали:

FR>>Во первых этот private на самом деле protected, то есть потомки видят private методы предков, и virtual private вполне нормально.

VD>Ну, да если private самом деле protected, то на самом деле обсуждать тут нечего, кроме (разве что) фееричного мышления авторов языка.

VD>Видимо по этому в ОКамле и используют модули вместо классов.

FR>>Во вторых private относится к объекту а не к классу и поэтому объекты одного и того же класса не могут копаться у друг друга в кишках.

В Delphi ограничения видимости не распространяются на текущий модуль. То есть внутри одно модуля ограничения видимости не действуют, и любой код в модуле имеет неограниченный доступ ко всем членам всех классов, объявленных в этом-же модуле. Поэтому утверждение "объекты одного и того же класса не могут копаться у друг друга в кишках" не соответствует действительности.

Во-вторых, потомок, объявленный в другом модуле, не имеет доступа к приватным полям предка, поэтому утверждение "потомки видят private методы предков" также некорректно. Они их действиельно видят, но только если объявлены в одном модуле, но то-же видит и любой другой код этого модуля.

С какого-то момента (точно позже D7) ввели strict private. Подробностей о нём я не знаю, но вроде как он закрыл видимость таких членов внутри модуля.

Здравствуйте, Sinclair, Вы писали:

S>К примеру, в COM, где наследования вовсе нет, интерфейсы представляют собой единственный способ поддержки полиморфизма.

Ну как-же нет наследования. Во-первых наследовать можно свой интерфейс от чужого, всё, что требуется — библиотека типов. Во-вторых, есть аггрегация, которая суть наследование включением. Наследование включением не подразумевает полиморфизм, но его обеспечивают интерфейсы.

У нас уже разные наследования появились?
Я знаю только два: наследование интерфейсов и наследование реализации. Композиция ни к одному, ни к другому не относится.

A>Обеспечением полиморфизма всегда были есть и будут виртуальные методы. Это тоже другой полиморфизм. Назвали и ладно, все равно это разные вещи.
А ты ссылки-то читал про полиморфизм? В курсе что generics\шаблоны — тоже полиморфизм, перегрузка функций — аналогично.

A>Это не композиция, это делигирование ты написал.
А в чем разница?

A>А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись.
Что значит включает? Покажешь на том примере что я написал отличие композиции от делегирования?

Здравствуйте, gandjustas, Вы писали:

A>>Это не композиция, это делигирование ты написал.
G>А в чем разница?

A>>А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись.
G>Что значит включает? Покажешь на том примере что я написал отличие композиции от делегирования?

Для меня все просто: Композиция(агрегация) — механизм повторного использования типов, построения иерархии типов. Делегирование — механизм позднего связывания функционала. Это как наследование и виртуальные методы, только имеет большую гибкость, так как работает на этапе выполнения. Наследование же с вирт методами на этапе компиляции работает.

Здравствуйте, Albatros, Вы писали:

A>Здравствуйте, gandjustas, Вы писали:

A>>>Это не композиция, это делигирование ты написал.
G>>А в чем разница?

A>>>А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись.
G>>Что значит включает? Покажешь на том примере что я написал отличие композиции от делегирования?

A>Для меня все просто: Композиция(агрегация) — механизм повторного использования типов, построения иерархии типов. Делегирование — механизм позднего связывания функционала. Это как наследование и виртуальные методы, только имеет большую гибкость, так как работает на этапе выполнения. Наследование же с вирт методами на этапе компиляции работает.

Для тебя конечно просто, а я вообще перестал понимать что ты пытаешься сказать. Ты слишком вольно обращаешься с терминологией. Поэтому давай перейдем к более формальным языкам.
Повторяю: покажи в коде различия между композицией и делегированием, на том примере что я приводил.

Здравствуйте, Sinclair, Вы писали:

S>А что, уже отказались? В 2000-х Delphi поддерживал object в полный рост. Вся семантика была обратно совместимой.

Он вообще-то запрещенный (устаревший) был еще в Дельфи 1.

Здравствуйте, Мишень-сан, Вы писали:

МС>Так может не стОит заморачиваться на ООП? Это ж не священная корова какая. Выкиньте Вы это ООП из статьи и сконцентрируйтесь на главном.

Проблема в том, что для этого надо знать альтернативу. А автор явно знаком в основном с Дельфи.

Здравствуйте, Albatros, Вы писали:

A>Ну так это другое наследование, мы про разные вещи говорим!

Уточним. Вы про другой. Мы про общепринятый научный термин.

A>Обеспечением полиморфизма всегда были есть и будут виртуальные методы.

К сведению бывших преподавателей. Есть разные формы полиморфизма. Например, банальная перегрузка методов (поддерживаемая в Дельфи) — это тоже проявление полиморфизма. Параметрический полиморфизм (когда у типа могут быть параметры), тоже вид полиморфизма. А еще есть динамическая типизация. В языках с динамической типизацией любой метод и любая переменная полиморфная.

Так что прежде чем кого-то чему-то учить ознакомьтесь с принятой в научном мире терминологией.

A>Это тоже другой полиморфизм. Назвали и ладно, все равно это разные вещи.
A>Это не композиция, это делигирование ты написал. А композиция, ну хотя бы из названия, это тогда, когда одно описание и реализапция(один код) включает в себя другие(другой код). Википедию почитай, подучись.

"Другой полиморфизм" это тоже из области вашей фантазии. В теории существует три вида полиморфизма. То о чем говорите вы в теории называется полиморфизмом подтипов (Subtyping polymorphism). Так вот с точки зрения подтипов нет разницы между интерфейсами и классами. Это все подтипы.

Потрудитесь прежде чем рассуждать на эти темы хотя бы вкратце ознакомиться с теорией и принятой в ней терминологией. В начале этой темы дана ссылка на весьма серьезный труд по этой теме. Кроме того все приведенные ссылки на википедию так же имеют весьма высокое качество (что нельзя сказать о русском аналоге).

Здравствуйте, Albatros, Вы писали:

A>Для меня все просто: Композиция(агрегация) — механизм повторного использования типов, построения иерархии типов. Делегирование — механизм позднего связывания функционала. Это как наследование и виртуальные методы, только имеет большую гибкость, так как работает на этапе выполнения. Наследование же с вирт методами на этапе компиляции работает.

А вы в курсе, что наследование необязательно для полиморфизма подтипов?
В курсе, что есть структурные системы типов (большая часть языков семейства ML) в которых понятие подтипа определяется без наследования (по совпадению структуры типов)?
Вы хоть знаете какой системой типов обладает Делфьи?

Здравствуйте, VladD2, Вы писали:
VD>Он вообще-то запрещенный (устаревший) был еще в Дельфи 1.
Ну, warning, возможно, и был (я уже не помню за давностью лет). Но работало всё по-прежнему прекрасно, и я этим даже пользовался.

Хочу предупредить ярых критиков дельфи. Данный язык используется в инженерных и промышленных разработках, в бизнесе и т.д. Покрытие языком задач много выше чем у остальных(кроме си, не сишарп). Программируя бумажки для бизнеса не забывайте об этом. Неуместная критика вызывает только смех.

Здравствуйте, Sinclair, Вы писали:
Я еще раз повторю: мы ущли от темы. Работа не есть учебник, учебники, в основном, пишут коллективы авторов.
Так как статью выкладывать чтобы к редакторам попасть?

Здравствуйте, Albatros, Вы писали:
A>Так как статью выкладывать чтобы к редакторам попасть?
http://rsdn.ru/?summary/2493.xml

Здравствуйте, VladD2, Вы писали:

VD>Ну, Дельфи на сегодня уже не фаворит. А кроме шарпа есть и более распространенные языки (Ява), но я не против примеров на Делфьи. Это не лучший выбор, но и не худший.

Че, разрешаете оставить примеры? Вот спасибо, вы великодушны.

VD>Посему я вам и говорю, что или разберитесь в теме (как следует), или добавьте в название слово Delphi.

Вы вообще кто, чтобы в императивной форме говорить что мне делать? Никак не могу понять этого дешевого бахвальства. Название наверное из принципа не сменю. Я уже давно во всем разобрался, поработал со всеми интересными мне технологиями.
Компилятор какого языка писали? Своего? Он я так понимаю уже загнулся? А я парсер сиквела написал, что дальше-то? Знаете разницу между распознанием своего языка и чужого? Подумайте между делом.

Здравствуйте, Albatros, Вы писали:

A>Че, разрешаете оставить примеры? Вот спасибо, вы великодушны.

Я не могу запретить вам делать что-то в вашей статье.

VD>>Посему я вам и говорю, что или разберитесь в теме (как следует), или добавьте в название слово Delphi.

A>Вы вообще кто, чтобы в императивной форме говорить что мне делать?

А вы кликните по моему профайлу. Там все указано. Я один из тех кто принимает решение о размещении или отказе в размещении материалов на этом сайте. Если других возражений не будет, а их пока что не видно, то ваш материал, в таком виде, не наш сайти никогда не попадет.

Вообще, если вы не тролль, мне искреннее жаль вас.

A>Никак не могу понять этого дешевого бахвальства.

Вас давно следовало бы за банить.

A>Название наверное из принципа не сменю.

Это ваше право. Критику вы получили, сочли ее не интересной. Можете расслабиться и продолжить писать в стол. Точнее (похоже) мучить потом своими писаниями бедных детей.

A> Я уже давно во всем разобрался, поработал со всеми интересными мне технологиями.

Да это видно не вооруженным взглядом. Вы наверно не заметили, что над вами тут уже давно все смеются.

A>Компилятор какого языка писали?

Языка Nemerle.

A>Своего?

К сожалению, нет.

A>Он я так понимаю уже загнулся?

Не правильно понимаете.

A>А я парсер сиквела написал, что дальше-то?

В целом, если не использовать это для целей пенесометрии, это полезный опыт. Вот только с точки зрения типов в языках программирования парсер не особо ценен. Написать интерпретатор было бы куда полезнее.

A>Знаете разницу между распознанием своего языка и чужого? Подумайте между делом.

Я даже не могу понять, что вы тут написали. Вы учитель выражаться яснее. Это и в статьях будет полезно.

PS

Ладно. Всего хорошего. Мне надоел разговор с упрямым невеждой. Считайте себя правым и возмущайтесь тем, что весь мир
вас не понимает.

	От:	Albatros
	Дата:	28.02.11 07:56
	Оценка:

	От:	Albatros
	Дата:	02.03.11 15:10
	Оценка:

	От:	Albatros
	Дата:	02.03.11 15:12
	Оценка:

От:	VladD2	www.nemerle.org
Дата:	04.03.11 09:32
Оценка:	1 (1) +2

	От:	hattab
	Дата:	01.03.11 22:34
	Оценка:	+1 -2

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	02.03.11 06:21
Оценка:	+3

От:	Sinclair	https://github.com/evilguest/
Дата:	01.03.11 22:00
Оценка:	5 (1) +1

От:	samius	http://sams-tricks.blogspot.com
Дата:	28.02.11 08:32
Оценка:	+2

	От:	Мишень-сан
	Дата:	01.03.11 08:03
	Оценка:	+2

От:	hardcase	http://nemerle.org
Дата:	01.03.11 13:28
Оценка: