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

[korvin]

кстати про свойства (properties), вспомнил обсуждение на другом форуме, вобщем есть мнение, что свойства способствуют написанию "говнокода" и вообще анти(ООП)паттерн, т.е. вместо описания "объектов с поведением" программист начинает описывать объекты как просто кортеж свойств, например:

class Window
  method resize (new_x, new_y)
    ...
  end
  ...
end

пишут

class Window
  field _x
  field _y
  property x { set _x; get _x }
  property y { set _y; get_ y }
end

конечно сеттеры и геттеры могут быть менее тривиальными, но
1) я, например, всегда воспринимаю проперти-геттер как чтение _значение поля_, без каких-либо вычислений
2) и сеттер практически так же, в данном случае вызов window.set_x 30 недостаточно информативен, происходит ли при этом перерисовка окна или нужно вызывать window.repaint ?

[Romkin]

Цитата korvin @ 28.10.11, 17:10

2) и сеттер практически так же, в данном случае вызов window.set_x 30 недостаточно информативен, происходит ли при этом перерисовка окна или нужно вызывать window.repaint ?

Свойства были придуманы для того, чтобы сделать некоторые вещи более очевидными. В частности, ожидается что общение с окном изменяет его мгновенно. Что, кстати, не исключает наличия метода, который принимает сразу прямоугольник для окна, наравне со свойствами.
По слухам, Delphi началась с надписи Button.Caption := 'Hello world' на доске.
Геттеры и сеттеры рекомендуется делать небольшими, именно для избежания переноса в них основной функциональности.
Свойства эффективное средство для ограничения видимости и написания более ясного кода, мне кажется. А говнокод можно писать любыми средствами

[korvin]

Цитата Romkin @ 28.10.11, 17:35

Свойства были придуманы для того, чтобы сделать некоторые вещи более очевидными.

ага, чтение и запись приватных полей объекта, т.е. "раскрытие" инкапсуляции

Добавлено 28.10.11, 18:07

Цитата Romkin @ 28.10.11, 17:35

Геттеры и сеттеры рекомендуется делать небольшими, именно для избежания переноса в них основной функциональности.

именно такие они и не нужны, ибо опять получается тупо чтение/запись приватного поля

Добавлено 28.10.11, 18:08

Цитата Romkin @ 28.10.11, 17:35

Свойства эффективное средство для ограничения видимости и написания более ясного кода, мне кажется.

вовсе нет, они делают из объектов простые кортежи нивелируя всю суть ООП и инкапсуляции в частности

[Romkin]

Цитата korvin @ 28.10.11, 18:05

именно такие они и не нужны, ибо опять получается тупо чтение/запись приватного поля

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

Добавлено 28.10.11, 18:11

Цитата korvin @ 28.10.11, 18:05

вовсе нет, они делают из объектов простые кортежи нивелируя всю суть ООП и инкапсуляции в частности

Поясни свою мысль. Особенно меня интересует эта мысль в приложении к т.н. объектам переноса данных и интерфейсам.

[korvin]

Цитата Romkin @ 28.10.11, 18:10

Поля вообще может не быть, это к слову.

для этого есть методы

Добавлено 28.10.11, 18:13

Цитата Romkin @ 28.10.11, 18:10

Или быть, но доступ к нему контролируется, что и требуется.

для этого есть типы

Добавлено 28.10.11, 18:15

Цитата Romkin @ 28.10.11, 18:10

Это не раскрытие инкапсуляции, а наоборот, декомпозиция методов объекта с целью унификации.

эээ... ты про эту унификацию?

Добавлено 28.10.11, 18:15

Цитата Romkin @ 28.10.11, 18:10

декомпозиция методов объекта с целью унификации.

кстати, что вообще эта фраза означает?

Добавлено 28.10.11, 18:16

Цитата Romkin @ 28.10.11, 18:10

Поясни свою мысль. Особенно меня интересует эта мысль в приложении к т.н. объектам переноса данных и интерфейсам.

а меня интересует, при чем тут перенос данных и интрфейсы?

[Romkin]

Цитата korvin @ 28.10.11, 18:13

а меня интересует, при чем тут перенос данных и интрфейсы?

Потому что там тоже есть свойства. И в DTO обычно только они.

Цитата korvin @ 28.10.11, 18:13

кстати, что вообще эта фраза означает?

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

Цитата korvin @ 28.10.11, 18:13

Цитата (Romkin @ Сегодня, 21:10)
Поля вообще может не быть, это к слову.

для этого есть методы

Мне гораздо удобнее обращаться с width окна как с атрибутом окна, а не иметь два метода для изменения ширины. Это, думаю, достаточно очевидно.

Цитата korvin @ 28.10.11, 18:13

Цитата (Romkin @ Сегодня, 21:10)
Или быть, но доступ к нему контролируется, что и требуется.

для этого есть типы

Э? Если атрибут только для чтения, как ты это объявишь с помощью типа?

[korvin]

Цитата Romkin @ 28.10.11, 18:22

Потому что там тоже есть свойства. И в DTO обычно только они.

где "там"? в джава-интерфейсах свойств нет, в Racket интерфейсах свойств нет. и что за DTO?

Добавлено 28.10.11, 18:28

Цитата Romkin @ 28.10.11, 18:22

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

что приводит к говнокоду

Добавлено 28.10.11, 18:29

Цитата Romkin @ 28.10.11, 18:22

Мне гораздо удобнее обращаться с width окна как с атрибутом окна, а не иметь два метода для изменения ширины. Это, думаю, достаточно очевидно.

интересно зачем тебе два метода изменения ширины окна?

[Romkin]

Цитата korvin @ 28.10.11, 18:13

для этого есть типы

А, да, и объяви тип для условия есть объект с полями StartDate и EndDate, и поля связаны условием StartDate <= EndDate.

[korvin]

Цитата Romkin @ 28.10.11, 18:22

Э? Если атрибут только для чтения, как ты это объявишь с помощью типа?

зачем мне это объявлять с помощью типа? про типы я говорил в контексте "установки" значения

Добавлено 28.10.11, 18:34

Цитата Romkin @ 28.10.11, 18:29

А, да, и объяви тип для условия есть объект с полями StartDate и EndDate, и поля связаны условием StartDate <= EndDate.

зачем? я просто объявлю объект с методом changePeriod(period : Period), если уж на то пошло, а не отдельными setStartDate, setEndDate
и поле соответственно будет одно, типа Period, у которого еще в конструкторе проверяется startDate <= endDate

Добавлено 28.10.11, 18:35
при этом я смогу использовать тип Period везде где надо и не заботится в каждом классе об удовлетворении условия startDate <= endDate

[Romkin]

Цитата korvin @ 28.10.11, 18:27

что приводит к говнокоду

Чиво-чиво? Выделение повторяющегося участка кода в отдельный метод приводит к говнокоду?!

Цитата korvin @ 28.10.11, 18:27

где "там"? в джава-интерфейсах свойств нет, в Racket интерфейсах свойств нет. и что за DTO?

А при чем ждесь java? В ней много чего нет, и что? А в Delphi у интерфейсов есть свойства.
DTO = data transfer object, объект переноса данных. В Delphi часто это структура с атрибутами только для чтения, значения которых задаются при ее создании.

Цитата korvin @ 28.10.11, 18:27

интересно зачем тебе два метода изменения ширины окна?

Оговорился, для доступа. GetWidth и SetWidth, поля-то нет, там вызов функций API идет.

Добавлено 28.10.11, 18:38

Цитата korvin @ 28.10.11, 18:30

зачем мне это объявлять с помощью типа? про типы я говорил в контексте "установки" значения

Вот в контексте установки и объявлять. Чтобы нельзя было установить значения полей, нарушающие условие.

Цитата korvin @ 28.10.11, 18:30

при этом я смогу использовать тип Period везде где надо и не заботится в каждом классе об удовлетворении условия startDate <= endDate

Собственно об этом объекте я и говорил. То есть, при изменении периода будешь создавать новый объект? А как обеспечишь невозможность изменения его атрибутов уже после создания?

[korvin]

Цитата Romkin @ 28.10.11, 18:35

Чиво-чиво? Выделение повторяющегося участка кода в отдельный метод приводит к говнокоду?!

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

Добавлено 28.10.11, 18:42

Цитата Romkin @ 28.10.11, 18:35

А при чем ждесь java? В ней много чего нет, и что? А в Delphi у интерфейсов есть свойства.

при том, что она, например, гораздо больше распространена, чем делфи, да =)

[Romkin]

Цитата korvin @ 28.10.11, 18:40

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

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

[korvin]

Цитата Romkin @ 28.10.11, 18:35

DTO = data transfer object, объект переноса данных. В Delphi часто это структура с атрибутами только для чтения, значения которых задаются при ее создании.

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

[Romkin]

Цитата korvin @ 28.10.11, 18:40

при том, что она, например, гораздо больше распространена, чем делфи, да =)

И все графики распространенности показывают достаточно убедительное пике. Вроде тут выше приводилось, или поблизости. Кстати, а что, в java у объектов есть свойства?

[korvin]

Цитата Romkin @ 28.10.11, 18:35

Цитата korvin @ 28.10.11, 18:30

зачем мне это объявлять с помощью типа? про типы я говорил в контексте "установки" значения

Вот в контексте установки и объявлять. Чтобы нельзя было установить значения полей, нарушающие условие.

Цитата korvin @ 28.10.11, 18:30

при этом я смогу использовать тип Period везде где надо и не заботится в каждом классе об удовлетворении условия startDate <= endDate

Собственно об этом объекте я и говорил. То есть, при изменении периода будешь создавать новый объект? А как обеспечишь невозможность изменения его атрибутов уже после создания?

в смысле? у меня же нет дурацких setStartDate и setEndDate =)

Добавлено 28.10.11, 18:47

Цитата Romkin @ 28.10.11, 18:44

И все графики распространенности показывают достаточно убедительное пике. Вроде тут выше приводилось, или поблизости. Кстати, а что, в java у объектов есть свойства?

эм... нет, я вообще-то об этом и говорил.... пятница, да? =))