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

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

у объектов нет свойств, у них есть поведение и может быть внутреннее состояние.

"Свойства" обеспечивают управление доступом к внутреннему состоянию объекта и тривиальной связкой методов "читать/писать", как ты полагаешь, они не ограничиваются.

"Свойства" можно переопределять и редекларировать в производных классах:

  TAncestor = class
  private
    FCaption: string;
    FLength: Integer;
  protected
    property Caption: string read FCaption;
    property Length: Integer read FLength;
  end;
 
  TDerived1 = class(TAncestor)
  public
    property Caption;
    property Length;
  end;
 
  TDerived2 = class(TDerived1)
  private
    function GetCaption: string;
  public
    property Caption: string read GetCaption;
  end;
 
  TDerived3 = class(TDerived2)
  private
    function NewGetCaption: string;
  public
    property Caption: string read NewGetCaption;
  end;
 
  TDerived4 = class(TDerived3)
  private
    procedure SetLength(const ALength: Integer);
  public
    property Caption write FCaption;
    property Length write SetLength;
  end;
 
  TDerived5 = class(TDerived4)
  published
    property Caption;
    property Length default 100;
  end;
 
  TDerived6 = class(TDerived5)
  published
    property Length default 50;
  end;

И заметь, независимо от изменений внутренней реализации - публичный интерфейс остаётся неизменным и всё ясно отражает.

Добавлено 31.10.11, 05:42
Полный перечень тут.

Цитата scorpion @ 30.10.11, 23:23

Если у вон того полудуплексного парня возникли проблемы, то этот полудуплексный парень начинает курить код, если код его не вставляет, то идет ко мне, я ему объясняю что к чему и как

И вся эта идиллия внезапно обрывается на фразе "работа того парня давно сделана и оплачена"

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

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

Ну, тут ты прав.

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

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

Потому что там примеры наиболее показательны и доступны для понимания.

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

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

А потому что далеко не все свойства - именно "атрибуты". У тебя, условно, GetCaption/SetCaption может отображаться непосредственно на WinAPI-шные GetWindowText/SetWindowText. Как ты это в структуру запихнёшь? Какой-нибудь BoundingRect для окна непрямоугольной формы - это отдельная тема. В классе хранится какой-нибудь HREGION на регион, описывающий форму, а на вызове GetBoundingRect у этого региона запрашивают его текущий ограничивающий прямоугольник. Думаю, идея понятна. Тот набор атрибутов, которые видит клиент, лишь отражение некоторого внутреннего состояния объекта, и может быть совсем не идентичен ему.

Вот тебе другой пример. Предположим, есть следующая модель. Некая игра. В игре есть визарды, у визардов есть юниты. Декларация класса визарда может выглядеть следующим образом (на условном C++-подобном синтаксисе):

class Unit;
 
class Wizard
{
public:
   property size_t TotalUnits {get {return m_Units.size();} }
   property lazy_list<Unit*> Units {get {return make_lazy_list(m_Units.begin(), m_Units.end());}}
 
   void AddUnit(Unit* unit) {m_Units.push_back();}
   void RemoveUnit(Unit* unit) {m_Units.erase(std::find(m_Units.begin(), m_Units.end(), unit);}
 
private:
   std::vector<Unit*> m_Units;
};

Здесь, как ты можешь заметить, внутреннее состояние класса (его внутренняя атрибутика) представлена совсем не так, как это выглядит для клиента.

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

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

В какой-то момент ты дойдёшь до операции биндинга представления и модели, и будешь решать ту же проблему.

Цитата scorpion @ 30.10.11, 23:23

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

Цитата D_KEY @ 30.10.11, 23:00

Languages that support multiple inheritance include: C++, Common Lisp (via CLOS), EuLisp (via The EuLisp Object System TELOS), Curl, Dylan, Eiffel, Logtalk, Object REXX, Scala (via the use of mixin classes), OCaml, Perl, Perl 6, Python, and Tcl (via Incremental Tcl).[1]

Other object-oriented languages, such as Java and Ruby implement single inheritance, although protocols, or "interfaces," provide some of the functionality of true multiple inheritance.

http://en.wikipedia.org/wiki/Multiple_inheritance

Цитата Qraizer @ 30.10.11, 22:12

Romkin, их никто и не путает. Вот сейчас ты только что сказал, что наследование интерфейсов - это говнодизайн. Я правильно понял?

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

Добавлено 31.10.11, 07:05

Цитата Qraizer @ 30.10.11, 22:12

Romkin, их никто и не путает. Вот сейчас ты только что сказал, что наследование интерфейсов - это говнодизайн. Я правильно понял?

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

Цитата korvin @ 30.10.11, 22:16

и куда деваются элементы, оставшиеся вне диапазона, при уменьшении размера?

Уничтожаются. И не надо говорить, что ужас-ужас

Цитата Flex Ferrum @ 31.10.11, 06:48

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

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

А потому что далеко не все свойства - именно "атрибуты". У тебя, условно, GetCaption/SetCaption может отображаться непосредственно на WinAPI-шные GetWindowText/SetWindowText. Как ты это в структуру запихнёшь? Какой-нибудь BoundingRect для окна непрямоугольной формы - это отдельная тема. В классе хранится какой-нибудь HREGION на регион, описывающий форму, а на вызове GetBoundingRect у этого региона запрашивают его текущий ограничивающий прямоугольник. Думаю, идея понятна. Тот набор атрибутов, которые видит клиент, лишь отражение некоторого внутреннего состояния объекта, и может быть совсем не идентичен ему.

Есть ли просто с со всеми нужными "настройками", работать как со структурой? А уже ее мы передаем нашему объекту, чтобы он взял из нее какие-то данные?

Цитата

Вот тебе другой пример. Предположим, есть следующая модель. Некая игра. В игре есть визарды, у визардов есть юниты. Декларация класса визарда может выглядеть следующим образом (на условном C++-подобном синтаксисе):

class Unit;
 
class Wizard
{
public:
   property size_t TotalUnits {get {return m_Units.size();} }
   property lazy_list<Unit*> Units {get {return make_lazy_list(m_Units.begin(), m_Units.end());}}
 
   void AddUnit(Unit* unit) {m_Units.push_back();}
   void RemoveUnit(Unit* unit) {m_Units.erase(std::find(m_Units.begin(), m_Units.end(), unit);}
 
private:
   std::vector<Unit*> m_Units;
};

Здесь, как ты можешь заметить, внутреннее состояние класса (его внутренняя атрибутика) представлена совсем не так, как это выглядит для клиента.

В чем здесь преимущества по сравнению с методами?

Добавлено 31.10.11, 07:10

Цитата OpenGL @ 31.10.11, 05:07

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

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

Ты не поверишь, но сейчас ты описал TLabel, отображающий текст и его свойство Caption

Нет. В TLabel все свалено в одну кучу.

Цитата D_KEY @ 30.10.11, 22:22

Все, можно сказать, наоборот. Интерфейсы появились как средство, необходимое в языке с запретом множественного наследования. Если множественное наследование разрешено, то в интерфейсах(в том виде, что они есть в Delphi/C#/Java) просто нет необходимости.

Не знаю, как в Java, но в шарпе интерфейсы очень сильно отличаются (по семантике и реализации) от абстрактных классов. Всё-таки (тут я соглашусь с scorpion'ом) интерфейс описывает ожидаемое клиентом поведение. Кто и как это поведение реализует - клиента мало беспокоит. Главное, чтобы контракт соблюдался. Так вот, если посмотреть на шарп (и .Net вообще), то можно увидеть следующие тонкости в реализации интерфейсов:
- Не имеет значение, сколько раз и как наследуется интерфейс.
- В реализации методов интерфейса учавствует не только концевой класс, но и все его базы.
Последний принцип проще пояснить на примере:

public interface IFoo
{
   void Foo();
   void Bar();
}
 
public class Base
{
   public void Foo() {/* something */}
}
 
public class Derived : Base, IFoo
{
   public void Bar() {/* something else */}
}

Интерфейс IFoo при такой схеме будет считаться полностью реализованным.

Для сравнения достаточно посмотреть на COM - как там "удобно" работать с интерфейсами, и какие там жесткие правила реализации в объекте одновременно нескольких интерфейсов.

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

Цитата Flex Ferrum @ 31.10.11, 06:48

Цитата (D_KEY @ Вчера, 23:14)
И удивляться, почему при чтении свойства полулили не то значение, что устанавливали?

Ну, тут ты прав.

А я вот не понимаю. Иногда - да, получается, что равносильно "дайте в метод значение, которое хотите, а метод вернет то, которое получилось". Но это редкость, а не правило. Как правило либо устанавливается что нужно либо исключение.

Цитата D_KEY @ 31.10.11, 07:08

Есть ли просто с со всеми нужными "настройками", работать как со структурой? А уже ее мы передаем нашему объекту, чтобы он взял из нее какие-то данные?

Это не так удобно, как кажется на первый взгляд.

Цитата D_KEY @ 31.10.11, 07:08

В чем здесь преимущества по сравнению с методами?

Эммм... Удобство и более точное отражение того, как это выглядит в "реальном мире".

Цитата D_KEY @ 31.10.11, 07:08

Нет. В TLabel все свалено в одну кучу.

Поклеп. ТАм есть отдельный объект, "который обестечивает хранение и работу с текстом", string

Цитата Flex Ferrum @ 31.10.11, 07:13

Не знаю, как в Java, но в шарпе интерфейсы очень сильно отличаются (по семантике и реализации) от абстрактных классов.

Безусловно. Речь не об этом. Если в языке есть множественное наследование и абстрактные классы, то потребности в семантике интерфейсов не возникает.

Цитата D_KEY @ 31.10.11, 07:16

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

Зависит от этой семантики. Вот я не отказался бы от семантики интерфейсов в стиле C#. Потому что прекрасно (на своём собственном опыте) знаю, как выглядит то же самое, но в рукопашную и на абстрактных классах.

Цитата D_KEY @ 31.10.11, 07:08

Есть ли просто с со всеми нужными "настройками", работать как со структурой? А уже ее мы передаем нашему объекту, чтобы он взял из нее какие-то данные?

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

Цитата Romkin @ 31.10.11, 07:16

Цитата D_KEY @ 31.10.11, 07:08

Нет. В TLabel все свалено в одну кучу.

Поклеп. ТАм есть отдельный объект, "который обестечивает хранение и работу с текстом", string

Я о композиции, используемой в данном классе.

Добавлено 31.10.11, 07:19
Qraizer, кстати, обрати внимание на пост Flex'а про интерфейсы. Это так же отвечает на твои вопросы.

Добавлено 31.10.11, 07:20

Цитата Flex Ferrum @ 31.10.11, 07:15

Эммм... Удобство и более точное отражение того, как это выглядит в "реальном мире".

В "реальном мире" визард, как я понимаю, не хранит юнитов, а лишь порождает их в некоторые моменты времени. Или нет?

Цитата D_KEY @ 31.10.11, 07:18

Я о композиции, используемой в данном классе.

Исторически сложилось. Во-первых, в API так и получается, во-вторых - быстро. Кстати, а чем принципиально QLabel отличается, например?