Скажите пожалуйста, является ли плохим стилем, разрешить обращаться к полям базового класса или надо только через properties

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

IDL>Скажите пожалуйста, является ли плохим стилем, разрешить обращаться к полям базового класса или надо только через properties
В принципе — ничего хорошего в том, чтобы обращаться к полям базового класса нет. Инкапсуляция на то и придумана, чтобы (в том числе) изолировать члены одних классов других. Не знаю, какой язык вы имеете в виду, но в Java общий (и в подавляющем большинстве случаев правильный) принцип состоит в том, чтобы закрывать (private) переменные. Бывают исключения (например, статические поля), но в целом — чем меньше видно, тем лучше. А если нужен доступ — так это надо делать через методы.

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

IDL>Скажите пожалуйста, является ли плохим стилем, разрешить обращаться к полям базового класса или надо только через properties
Кратко: да, это плохой стиль. Надо всегда испольщовать properties.

On Fri, 02 Dec 2005 16:41:53 +0200, IDL <40838@users.rsdn.ru> wrote:

> Скажите пожалуйста, является ли плохим стилем, разрешить обращаться к полям базового класса или надо только через properties

желательно через ф-ции для доступа — просто упрощает поптом жизнь при отловке моментов: "а кто ето поменял"
и еще, иногда упрощает жизнь при необходимости изменить структуру даних бпзового класа, когда всесто возвращения переменно можно подставить и код который берет ее откуда то иначе

Здравствуйте, Максим Зелинский, Вы писали:

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

IDL>>Скажите пожалуйста, является ли плохим стилем, разрешить обращаться к полям базового класса или надо только через properties
МЗ>Кратко: да, это плохой стиль. Надо всегда испольщовать properties.

Верно сказано! В каждом букваре про это пишут.. Тем более, что тип данных полей класса может смениться. А свойства — это способ безопасно положить и взять то, что интересует.

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

IDL>Скажите пожалуйста, является ли плохим стилем, разрешить обращаться к полям базового класса или надо только через properties

Боюсь, что меня счас наминусуют пуристы, но скажу — вполне допустимо. При главном условии — язык поддерживает свойства (так что к C++ и Java это точно не относится). Почему? А всё просто — у свойства и поля совершенно одинаковая семантика использования, а поле описать проще. Если потом потребуется сделать что-то посложнее простой записи в ячейку, ты потом заменишь поле на одноимённое свойство и никто ничего не заметит.

(Правда надо учитывать и разные конъюнктурные фишки, например, public-свойства могут выводиться в каком-нибудь там дизайнере форм, а public-поля — нет).

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

DA>Верно сказано! В каждом букваре про это пишут.. Тем более, что тип данных полей класса может смениться. А свойства — это способ безопасно положить и взять то, что интересует.

Если тип данных поменяется, мы поле просто превратим в одноимённое свойство. Юзер класса ничего и не заметит.

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

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

DA>>Верно сказано! В каждом букваре про это пишут.. Тем более, что тип данных полей класса может смениться. А свойства — это способ безопасно положить и взять то, что интересует.

T>Если тип данных поменяется, мы поле просто превратим в одноимённое свойство. Юзер класса ничего и не заметит.

Ну верно всё...а что я не так сказал?

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

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

IDL>>Скажите пожалуйста, является ли плохим стилем, разрешить обращаться к полям базового класса или надо только через properties

T>Боюсь, что меня счас наминусуют пуристы, но скажу — вполне допустимо. При главном условии — язык поддерживает свойства (так что к C++ и Java это точно не относится). Почему? А всё просто — у свойства и поля совершенно одинаковая семантика использования, а поле описать проще. Если потом потребуется сделать что-то посложнее простой записи в ячейку, ты потом заменишь поле на одноимённое свойство и никто ничего не заметит.

T>(Правда надо учитывать и разные конъюнктурные фишки, например, public-свойства могут выводиться в каком-нибудь там дизайнере форм, а public-поля — нет).
Дело не пуританстве. Вопрос ИМХО стоит иначе: использовать ООП и его преимущества (а если использовать, то как) или не использовать ООП и ограничиться "чистыми" С или Pascal.
Если таки мы используем ООП, то стало быть нужно придерживаться определенной дисциплины проектирования и, в том числе, не лезть из наследников в поля родителя.

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

DA>Ну верно всё...а что я не так сказал?

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

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


F>Дело не пуританстве. Вопрос ИМХО стоит иначе: использовать ООП и его преимущества (а если использовать, то как) или не использовать ООП и ограничиться "чистыми" С или Pascal.
F>Если таки мы используем ООП, то стало быть нужно придерживаться определенной дисциплины проектирования и, в том числе, не лезть из наследников в поля родителя.


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

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

F>Дело не пуританстве. Вопрос ИМХО стоит иначе: использовать ООП и его преимущества (а если использовать, то как) или не использовать ООП и ограничиться "чистыми" С или Pascal.
F>Если таки мы используем ООП, то стало быть нужно придерживаться определенной дисциплины проектирования и, в том числе, не лезть из наследников в поля родителя.

А в свойства родителя лезть можно. В чём отличие-то, разъясните по рабоче-крестьянски?

На всякий случай уточняю — отличие между r/w свойством, get/put которого просто читает/пишет поле и между полем.

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


A>желательно через ф-ции для доступа — просто упрощает поптом жизнь при отловке моментов: "а кто ето поменял"

нужно нормальные IDE использовать. например IDEA позволяет легко отслеживать чтение и запись полей.


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

On Fri, 02 Dec 2005 17:48:30 +0200, vladserge <19703@users.rsdn.ru> wrote:

> Здравствуйте, andrij, Вы писали:
>
>
> A>желательно через ф-ции для доступа — просто упрощает поптом жизнь при отловке моментов: "а кто ето поменял"
>
> нужно нормальные IDE использовать. например IDEA позволяет легко отслеживать чтение и запись полей.
>
ну ето я из своево С++ опыта высказивал мисль
>
> A>и еще, иногда упрощает жизнь при необходимости изменить структуру даних бпзового класа, когда всесто возвращения переменно можно подставить и код который берет ее откуда то иначе

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

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

F>>Дело не пуританстве. Вопрос ИМХО стоит иначе: использовать ООП и его преимущества (а если использовать, то как) или не использовать ООП и ограничиться "чистыми" С или Pascal.
F>>Если таки мы используем ООП, то стало быть нужно придерживаться определенной дисциплины проектирования и, в том числе, не лезть из наследников в поля родителя.

T>А в свойства родителя лезть можно. В чём отличие-то, разъясните по рабоче-крестьянски?

T>На всякий случай уточняю — отличие между r/w свойством, get/put которого просто читает/пишет поле и между полем.
Проще пояснить свою мысль псевдокодом a-la Java:

class Base {
    private int counter = 0;    // Закрытое поле !

    // Открытые (public) методы доступа к закрытому (private) полю
    public int getCounter () {return counter;}
    public void putCounter (int newValue) {counter = newValue;}
}

class SubClass extends Base {

    int c = 0;

    c = super.getCounter ();    // Получить значение counter из суперкласса
    c = 1000;
    super.putCounter (c);       // Изменить значение counter в суперклассе
}

А вот если поле counter в суперклассе Base будет не private, а public — это, на мой взгляд, уже нехорошо. Вот, собственно, что я имел в виду.

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

F>А вот если поле counter в суперклассе Base будет не private, а public — это, на мой взгляд, уже нехорошо. Вот, собственно, что я имел в виду.

Если язык не поддерживает свойства, то это разумно, а если поддерживает? В чём преимущество

class Base {
    private int counter = 0;
    public int Counter{ get counter; set counter; }
}

перед

class Base {
    public int Counter = 0;
}

?

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

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

F>>А вот если поле counter в суперклассе Base будет не private, а public — это, на мой взгляд, уже нехорошо. Вот, собственно, что я имел в виду.

T>Если язык не поддерживает свойства, то это разумно, а если поддерживает? В чём преимущество

T>

T>class Base {
T>    private int counter = 0;
T>    public int Counter{ get counter; set counter; }
T>}
T>

T>перед

T>

T>class Base {
T>    public int Counter = 0;
T>}
T>

T>?
А кто его знает Я просто никогда не работал с языками у которых такая семантика и ничего по этому поводу сказать не могу. Я как-то привык к Java, а там свойств в указанном вами смысле нет.

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

IDL>Скажите пожалуйста, является ли плохим стилем, разрешить обращаться к полям базового класса или надо только через properties

Что для однй задачи черное то для другой красное.

Головой надо думать. И все.

Вот, например, образец плохого стиля (Java):

class Rect 
{
  private int x;
  private int y;
  public int getX() { return x; }
  public int getY() { return y; }
}

по спецификации Java getX генерируется всегда.
В С++ же такое допустимо — вызов getX может быть редуцирован до прямого обращения к памяти.

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

T>Если тип данных поменяется, мы поле просто превратим в одноимённое свойство. Юзер класса ничего и не заметит.

Заметит, если исходники базового недоступны. Есть еще ряд моментов, например рефлекшен по другому работает.

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

CS>по спецификации Java getX генерируется всегда.
CS>В С++ же такое допустимо — вызов getX может быть редуцирован до прямого обращения к памяти.

Скорее всего речь о .NET, а там в таких простых случаях JIT акцессоры инлайнит.