Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

[korvin]

Цитата Flex Ferrum @ 30.10.11, 17:32

Хорошо. Есть сообщение "caption". Какую семантику несёт это существительное? Что (по мнению проектировщика интерфейса) ожидает получить клиент, отправив объекту это сообщение?

объект класса Caption. или String

[Flex Ferrum]

Цитата korvin @ 30.10.11, 17:37

объект класса Caption. или String

Он сам по себе, что-ли, объект? Ещё раз. У объекта (в его публичном интерфейсе) есть метод/сообщение/чего-то-там-ещё "caption". За этот метод дёргает клиент этого объекта. Зачем? Что он ожидает получить от объекта? Что объект обещает ему вернуть из этого метода? Какой его контракт? Какие сценарии использования? Ведь не для красоты же этот метод-сообщение в интерфейсе заведён?

Сообщение отредактировано: Flex Ferrum - 30.10.11, 17:41

[Qraizer]

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

Цитата Romkin @ 30.10.11, 15:32

Наследуется реализация, а не интерфейс, то есть при реализации ты сначала реализуешь предка, а потом - потомков.

Правильно. Продолжай.

Добавлено 30.10.11, 17:50
Если хочешь, конечно. А то D_KEY, вон, не хочет.

[korvin]

Цитата Flex Ferrum @ 30.10.11, 17:33

И (коли мы за чистоту и гигиену интерфейсов), почему сообщение (сиречь метод) не содержит в себе глагола? Какое это тогда поведение, если мы описываем его существительными?

потому что get уже как слово паразит, не несет смысловой нагрузки, но вставляют префиксом в каждый метод, который что-то возвращает. впрочем как хотите, пусть будет getCaption

Добавлено 30.10.11, 18:00

Цитата Flex Ferrum @ 30.10.11, 17:41

Он сам по себе, что-ли, объект? Ещё раз. У объекта (в его публичном интерфейсе) есть метод/сообщение/чего-то-там-ещё "caption". За этот метод дёргает клиент этого объекта. Зачем? Что он ожидает получить от объекта? Что объект обещает ему вернуть из этого метода? Какой его контракт? Какие сценарии использования? Ведь не для красоты же этот метод-сообщение в интерфейсе заведён?

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

но задайте свои вопросы себе же, заменив слово "метод" на "свойство".

Добавлено 30.10.11, 18:06
ах да, пардон, еще типы дают нам некоторую информацию о семантике

[Flex Ferrum]

Цитата korvin @ 30.10.11, 17:55

потому что get уже как слово паразит, не несет смысловой нагрузки, но вставляют префиксом в каждый метод, который что-то возвращает.

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

Цитата korvin @ 30.10.11, 17:55

ох, далеко Вас занесло...

Работа такая.

Цитата korvin @ 30.10.11, 17:55

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

Эххх... Вот ты несколькими постами выше взялся спроектировать интерфейс некоторого объекта. И даже описывал подходы, которыми будешь пользоваться. При этом на простой вопрос ответить не можешь. Ну либо я его не так формулирую. Попробую ещё раз. Ты добавил в интерфейс объекта метод getCaption. Какую смысловую нагрузку несёт каждое слово из его именования? Почему именно get? Почему Caption? Какова семантика этого конкретного метода? Зачем этот метод нужен клиенту объекта? Для каких целей и в каких случаях клиент будет его вызывать? Ведь интерфейс объекта - он появляется не просто так. С этим ты согласен? Он появляется для того, чтобы клиенты могли с этим объектом как-то взаимодействовать. При этом каждый метод интерфейса должен нести конкретную семантику для клиента (называемую также контрактом). В том числе быть непротиворечивым и неизбыточным.

[D_KEY]

Цитата OpenGL @ 30.10.11, 13:44

Цитата D_KEY @ 30.10.11, 13:09

Ну так ты исходишь из того, что объект - это набор свойств...

.. и методов, если смотреть на него снаружи. Что плохого в таком представлении?

Да в принципе ничего. Только вот состояние(набор атрибутов) - это внутреннее дело объекта. Методы должны быть для клиента единственным способом "общаться" с объектом. То, что вы называете "свойствами", это не атрибуты в ОО-смысле, а синтаксический сахар над геттерами и сеттерами. Мне просто не очень ясно, зачем этот сахар нужен.

Цитата

Если я пишу oldLen=a.Length, мне неважно, вызывается там метод или нет, мне важно, чтобы в переменную записалось то, что я запросил.

В какую переменную ?

[Flex Ferrum]

Цитата D_KEY @ 30.10.11, 19:25

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

Начинаем сказку с начала. Геттеры и сеттеры чего?

Добавлено 30.10.11, 19:29

Цитата D_KEY @ 30.10.11, 19:25

В какую переменную ?

Наверное в ту, которая слева от знака присваивания.

[D_KEY]

Цитата Flex Ferrum @ 30.10.11, 13:49

Цитата korvin @ 30.10.11, 13:10

давай. что такое атрибут объекта?

Некоторая часть его состояния.

И ты считаешь, что клиент может/должен что-то знать о представлении этого самого состояния?

Цитата

Цитата D_KEY @ 30.10.11, 12:56

Почему бы тебе не запросить их через методы? Что дают тебе свойства?

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

Я сеттеры в чистом виде редко делаю, геттеры есть, да.
Вот посмотри, например, на std::vector. Хотел бы ты, чтобы size, capacity и, скажем, empty были бы изменяемыми свойствами? И какие это бы дало преимущества(лично я вижу одни лишь недостатки).

[Flex Ferrum]

Цитата D_KEY @ 30.10.11, 19:34

И ты считаешь, что клиент может/должен что-то знать о представлении этого самого состояния?

Клиент знает о представлении "этого самого состояния" ровно столько, сколько сообщает ему интерфейс объекта. С этой точки зрения "свойство" и пара "геттер-сеттер" являются синонимами. По сути, конечно же. Потому что слева от глагола get (или set) стоит наименование того самого "публичного атрибута", о существовании которого объект любезно сообщает своим клиентам.

Цитата D_KEY @ 30.10.11, 19:34

Вот посмотри, например, на std::vector. Хотел бы ты, чтобы size, capacity и, скажем, empty были бы изменяемыми свойствами? И какие это бы дало преимущества(лично я вижу одни лишь недостатки).

Нет. А я и не говорю, что все свойства должны быть r/w. Для каких то (типа тобою перечисленных) доступ должен быть r/o. И именно этой спецификой (определять ограничение доступа) свойство отличается от простого атрибута.

[D_KEY]

Цитата Qraizer @ 30.10.11, 17:49

Я не настолько мелочен, чтобы разжёвывать простые причинно-следственные связи. Всё есть в предыдущем посте, чтобы это увидеть, достаточно выключить режим "чайника".

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

interface A
{
    int f();
}
 
interface B : A
{
    // ...
}
 
interface C : A
{
    // ...
}
 
class D : B, C
{
    // ...
}

Ты говоришь лишь то, что твой класс D предоставит интерфейсы A, B и С. Т.е. с точки зрения клиентов D(а не интерфейсов B и C) нет никакой разницы с таким кодом:

interface A
{
    int f();
}
 
interface B
{
    // ...
}
 
interface C
{
    // ...
}
 
class D : A, B, C
{
    // ...
}

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

Добавлено 30.10.11, 19:49

Цитата Flex Ferrum @ 30.10.11, 19:40

Цитата D_KEY @ 30.10.11, 19:34

И ты считаешь, что клиент может/должен что-то знать о представлении этого самого состояния?

Клиент знает о представлении "этого самого состояния" ровно столько, сколько сообщает ему интерфейс объекта. С этой точки зрения "свойство" и пара "геттер-сеттер" являются синонимами. По сути, конечно же. Потому что слева от глагола get (или set) стоит наименование того самого "публичного атрибута", о существовании которого объект любезно сообщает своим клиентам.

Я понял тебя. Но я, пожалуй, вообще против пар геттер/сеттер...

Цитата

Цитата D_KEY @ 30.10.11, 19:34

Вот посмотри, например, на std::vector. Хотел бы ты, чтобы size, capacity и, скажем, empty были бы изменяемыми свойствами? И какие это бы дало преимущества(лично я вижу одни лишь недостатки).

Нет. А я и не говорю, что все свойства должны быть r/w. Для каких то (типа тобою перечисленных) доступ должен быть r/o. И именно этой спецификой (определять ограничение доступа) свойство отличается от простого атрибута.

Ты наверно не понял о чем я.
У нас есть size. А есть resize.
У нас есть capacity. А есть reserve.
У нас есть empty. А есть clear.
Почему же тогда не сделать это r/w свойствами ?

Сообщение отредактировано: D_KEY - 30.10.11, 19:50

[Flex Ferrum]

Цитата D_KEY @ 30.10.11, 19:45

Ты наверно не понял о чем я.
У нас есть size. А есть resize.
У нас есть capacity. А есть reserve.
У нас есть empty. А есть clean.
Почему же тогда не сделать это r/w свойствами ?

В каких-то случаях логично одно. В других случаях - другое (кстати, capacity - можно и r/w-свойством сделать). Возьми пример с тем же Caption'ом. Как ты сеттер обзовёшь? Recaption? Возьми какой-нибудь EditBox. У него есть атрибут-свойство-называй-как-хочешь "Text", семантика которого - предоставлять доступ к введённому пользователем тексту. Во всех GUI-либах, с которыми мне приходилось иметь дело, это была либо пара методов getText/setText, либо свойство Text. Зачем делать вид, что чего то не существует, если это есть, и никуда ты от этого не денешься?

Добавлено 30.10.11, 20:00

Цитата D_KEY @ 30.10.11, 19:45

Но я, пожалуй, вообще против пар геттер/сеттер...

А куда ты от них денешься?

Добавлено 30.10.11, 20:01
Можно, конечно, и любовью заниматься стоя в скафандре в гамаке, но вот только зачем?

[D_KEY]

Цитата Flex Ferrum @ 30.10.11, 19:56

кстати, capacity - можно и r/w-свойством сделать

И удивляться, почему при чтении свойства полулили не то значение, что устанавливали?

Цитата

Возьми пример с тем же Caption'ом.

Вот почему-то примеры на свойства чаще всего связаны именно с GUI...

Цитата

Как ты сеттер обзовёшь? Recaption?

Почему вообще не сделать набор атрибутов для такого рода "классов" в виде структуры? Зачем себя обманывать и делать вид, что имеет место быть какая-то инкапсуляция, если практически весь объект представляет собой просто набор атрибутов?

Цитата

Зачем делать вид, что чего то не существует, если это есть, и никуда ты от этого не денешься?

Почему бы не существовать объекту "текста", который бы делал бы всю работу по хранению и работы с текстом, и отдельному объекту, который бы умел отображать текст нужного размера, шрифта и т.п. Зачем нужно все валить в одну кучу? Я, конечно, с ГУИ уже работаю очень мало, но все-время как ни посмотрю в его сторону, у меня стабильно возникает ощущение, что что-то там не так...

[Qraizer]

Цитата D_KEY @ 30.10.11, 19:45

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

С какой это стати D должен реализовывать A? Он явно указывает, что реализует B и C. Тот факт, что они расширяют A, не делает реализацию A по требованиям B и C одинаковой. Даже если она одинакова, это не означает, что реализации B и C оперируют (хоть и одинаково) одной и той же реализацией A.
Можешь себе предстваить поток ввода/вывода, связанный с двумя разными объектами? Ввод из одного, вывод в другой. Я могу. Например, ввод по одному TCP порту, вывод через другой, соответственно - через разные экземпляры сокетов. В общем случае D реализует A дважды и по-разному.

Добавлено 30.10.11, 20:40

Цитата D_KEY @ 30.10.11, 20:14

Зачем себя обманывать и делать вид, что имеет место быть какая-то инкапсуляция, если практически весь объект представляет собой просто набор атрибутов?

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

[Romkin]

Цитата Qraizer @ 30.10.11, 17:49

Цитата (Romkin @ Сегодня, 18:32)
Наследуется реализация, а не интерфейс, то есть при реализации ты сначала реализуешь предка, а потом - потомков.
Правильно. Продолжай.

Чего продолжать-то? Все уже, интерфейсы реализованы, столкновений не выявлено

[D_KEY]

Цитата Qraizer @ 30.10.11, 20:36

Даже если она одинакова, это не означает, что реализации B и C оперируют (хоть и одинаково) одной и той же реализацией A.

Причем тут реализации B и C, если речь идет об интерфейсах?

Цитата

Можешь себе предстваить поток ввода/вывода, связанный с двумя разными объектами? Ввод из одного, вывод в другой. Я могу. Например, ввод по одному TCP порту, вывод через другой, соответственно - через разные экземпляры сокетов.

Я могу это представить, но я не могу понять причем тут интерфейсы.

Цитата

Цитата D_KEY @ 30.10.11, 20:14

Зачем себя обманывать и делать вид, что имеет место быть какая-то инкапсуляция, если практически весь объект представляет собой просто набор атрибутов?

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

Какими инвариантами связан заголовок и, скажем, координаты?