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

А>>Как вы от этого обезопаситесь? Сделаете extention Move?
S>Зачем? Инварианты модели данных проверяться в ней же — просто добавьте воды ассерты в сеттер.

То есть геттеры-сеттеры все же оставим в объекте? А методы куда-то вынесем? А в чем принципиальное отличие сеттеров-геттеров от методов?

Ладно, так что сделать с Move/CanMove в этом случае? CanMove — свойство, оставляем в объекте Car, Move — выносим куда-то? Или CanMove — вообще не нужно, убираем "hidden state", и в где-то расположенном методе Move сами определяем, может машина двигаться или нет?

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

G>Ну пусть процедурное программирование, и че?

Ну как же, от него же ушли к объектно-ориентированному. Что, теперь обратно? Вроде ж проходили уже все недостатки, точнее, наелись уже (например, WinAPI).

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

Определенно, ООП имеет (огромные) преимущества. Сравните удобство и эффективность использования WinAPI и .Net BCL. ООП дает более-менее определенный метод структурирования кода (по сравнению с процедурным программированием), и, отказываясь от него, мы возвращаемся... непонятно к чему.

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

А>А в чем принципиальное отличие сеттеров-геттеров от методов?
Если это не риторический вопрос — см. Framework Design Guidelines, в частности,

Consider using a property if the member represents a logical attribute of the type.
...
Do use a method, rather than a property, in the following situations.
...

• The operation has a significant and observable side effect. Note that populating an internal cache is not generally considered an observable side effect.

А>Ладно, так что сделать с Move/CanMove в этом случае? CanMove — свойство, оставляем в объекте Car, Move — выносим куда-то?
Нет, цель у нас — разделить данные и поведение программы. Поэтому в Car оставляем только структуру данных и проверку инвариантов, которые не должны нарушаться ни при каких обстоятельствах. Логика/состояние (и Move/CanMove в том числе) выносится в отдельный слой.

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

А>Все-таки, мне кажется, вы имеете в виду не совсем процедурное программирование, какая-то методика должна быть. Неужели вы всерьез предлагаете вернуться к процедурному программированию, без инкапсуляции, наследования и полиморфизма?
Нет, зачем бросаться из крайности в крайность? Тут, скорее, попытка привнести ФП-подход, так что всё в порядке

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

А>Имеем:
А>Класс Car с методом Move — перемещающим машину.
А>В UI в зависимости от того возможно ли переместить машину становятся доступыми элементы UI.
А>Как более правильно реадизовать такую проверку?
А>Напрашивающееся решение — добавить метод CanMove, но насколько это правильно?
А>Так почти для каждого действия придется заводить соответствующее свойства.

Паттерн State. Выставлять через состояние объект с набором свойств, доступных для
показа пользователю в данном состоянии. В UI рисовать через reflection
(TypeDescriptor, PropertyDescriptor). Скорее всего, некоторые свойства будут
дуплицированы в классах, представляющих разные состояния, но это ерунда.

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

BB>Паттерн State. Выставлять через состояние объект с набором свойств, доступных для
BB>показа пользователю в данном состоянии.
Имхо, неудачный подход.

Во-первых, предыдущие решения хотя бы проверяются при компиляции/первом связывании.
Во-вторых, число различных состояний будет расти очень быстро — комбинаторика, увы.
В-третьих, с состоянием UI работает не только через декларативные биндинги, но и в code behind.

summary: Делать работу за компилятор и покрывать всю динамику тестами — пустой перевод ресурсов.

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

S>Нет, цель у нас — разделить данные и поведение программы. Поэтому в Car оставляем только структуру данных и проверку инвариантов, которые не должны нарушаться ни при каких обстоятельствах. Логика/состояние (и Move/CanMove в том числе) выносится в отдельный слой.

Вообще, я, кажется, понял идею. Мы оставляем в объекте только "ядро" — минимум свойств/методов для обеспечения инкапсуляции/инварианта, а всю функциональность, которую можно выразить через другие свойства/методы, не нарушая инкапсуляции, выносим в другие классы. Так?

А>>А в чем принципиальное отличие сеттеров-геттеров от методов?
S>Если это не риторический вопрос — см. Framework Design Guidelines, в частности,

Я имел в виду с точки зрения теории ООП.

S>Consider using a property if the member represents a logical attribute of the type.

Я примерно, конечно, понимаю, что это значит, но это какая-то "интуитивная" формулировка. На практике свойство скорее ассоциируется с логическим "дочерним объектом", как правило, "элементарного" типа. Ну и, конечно, свойство не является атрибутом типа, уж скорее объекта (экземпляра типа).

Все-таки, мне кажется, свойство это всего лишь синтаксический сахар в контексте языков с синтаксисом типа C#. Можно представить синтаксис, в котором между методами и свойствами не будет различия. Самостоятельного значения в теории ООП я для свойств не вижу.

S>Do use a method, rather than a property, in the following situations.
S>The operation has a significant and observable side effect. Note that populating an internal cache is not generally considered an observable side effect.

Это еще одно "интуитивное" определение. Оно относится разве что к геттерам свойств. Очевидно, сеттер любого свойства имеет очень даже observable side effect, иначе зачем он нужен.

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

А>Вообще, я, кажется, понял идею. Мы оставляем в объекте только "ядро" — минимум свойств/методов для обеспечения инкапсуляции/инварианта, а всю функциональность, которую можно выразить через другие свойства/методы, не нарушая инкапсуляции, выносим в другие классы. Так?
Да. Со всем, что ниже — тоже согласен.

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

S>Если это не риторический вопрос — см. Framework Design Guidelines, в частности

Бла-бла-бла. Почти всё выглядит как "мы тут чего-то писали, ща попробуем это выдать за систему".

"The operation returns a different result each time it is called, even if the parameters do not change.". А почему, собственно? Ах, NewGuid() сделан методом, надо это как-то обьяснить...
Позвольте, но это значит, что DateTime.Now — в методы, а Random.Next() — в property.

И т.д. и т.д.

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

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

G>>Ну пусть процедурное программирование, и че?

А>Ну как же, от него же ушли к объектно-ориентированному. Что, теперь обратно? Вроде ж проходили уже все недостатки, точнее, наелись уже (например, WinAPI).
Ты посмотри на функциональные языки, хаскелл например. Там ООП нет, но уровень абстракции и гибкость кода гораздо выше.
А идея та же самая: мы вызываем функции и комбинируем сами функции и результаты вызовов между собой.

А>Все-таки, мне кажется, вы имеете в виду не совсем процедурное программирование, какая-то методика должна быть. Неужели вы всерьез предлагаете вернуться к процедурному программированию, без инкапсуляции, наследования и полиморфизма? Даже те, кто программирует на чистом C, в котором ООП не было никогда, используют как минимум инкапсуляцию и полиморфизм, потому что без них разработка более-менее сложной программы превращается в ад.
Это не я имею ввиду, а ты.
Я сказал что не надо помещать функции по работе с данными в класс с данными, а ты сразу про процедурное программирование начал.


А>Определенно, ООП имеет (огромные) преимущества. Сравните удобство и эффективность использования WinAPI и .Net BCL. ООП дает более-менее определенный метод структурирования кода (по сравнению с процедурным программированием), и, отказываясь от него, мы возвращаемся... непонятно к чему.
WinAPI сделан в терминах C это накладывает наибольший отпечаток на весь API.

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

А>Я имел в виду с точки зрения теории ООП.

Не существует теории ООП. ООП у каждого свое.

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

G>Это не я имею ввиду, а ты.
G>Я сказал что не надо помещать функции по работе с данными в класс с данными, а ты сразу про процедурное программирование начал.

Дык, я спросил "процедурное программирование?", ты ответил "Ну пусть процедурное программирование, и че?" Ну и "класс" просто с данными без функций — это процедурное программирование и есть.

Ладно, я понял: ты клонишь к функциональному программированию. Я, к сожалению, имею о нем весьма общее представление. Пожалуй, мне стоит все-таки выделить время и ознакомиться с ним поближе.

Хотя из того, что я представляю об ФП на текущий момент — это что оно ортогонально ООП, находится на другом "системном уровне", это как бы процедурное программирование на стероидах. Оно, конечно, гораздо мощнее процедурного программирования (в том виде, каком процедурное программирование использовалось, что мешало в императивном языке сделать first class functions, лямбды, замыкания, комбинаторы и т.п.?), но задачи, которые решает ООП, в нем даже не рассматриваются.

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

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

G>WinAPI сделан в терминах C это накладывает наибольший отпечаток на весь API.

Дело не только в C, хотя возможности языка трудно отделить от парадигмы, которую он реализует. Можно сравнить WinAPI с интерфейсами Mac OS, написанными на C в объектно-ориентированном стиле. Разница в структурированности, интуитивности и удобстве огромна, и это только за счет объектно-ориентированной группировки.

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

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

G>>Это не я имею ввиду, а ты.
G>>Я сказал что не надо помещать функции по работе с данными в класс с данными, а ты сразу про процедурное программирование начал.

А>Дык, я спросил "процедурное программирование?", ты ответил "Ну пусть процедурное программирование, и че?" Ну и "класс" просто с данными без функций — это процедурное программирование и есть.
Ну раз ты так считаешь, то считай. Я тебе переубеждать не собираюсь.

А>Ладно, я понял: ты клонишь к функциональному программированию. Я, к сожалению, имею о нем весьма общее представление. Пожалуй, мне стоит все-таки выделить время и ознакомиться с ним поближе.
Ознакомься.

А>Хотя из того, что я представляю об ФП на текущий момент — это что оно ортогонально ООП, находится на другом "системном уровне", это как бы процедурное программирование на стероидах. Оно, конечно, гораздо мощнее процедурного программирования (в том виде, каком процедурное программирование использовалось, что мешало в императивном языке сделать first class functions, лямбды, замыкания, комбинаторы и т.п.?), но задачи, которые решает ООП, в нем даже не рассматриваются.
Лучше всетаки ознакомься, а потом говори такое.

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

Автор: gandjustas
Дата: 12.08.11

.

G>>WinAPI сделан в терминах C это накладывает наибольший отпечаток на весь API.

А>Дело не только в C, хотя возможности языка трудно отделить от парадигмы, которую он реализует. Можно сравнить WinAPI с интерфейсами Mac OS, написанными на C в объектно-ориентированном стиле. Разница в структурированности, интуитивности и удобстве огромна, и это только за счет объектно-ориентированной группировки.
В маках objective c, это сосвем другой язык. И ты сам видишь как возможности языка влияют на API и дело вовсе не в ООП, возьми например javascript и посмотри какие там API получаются и насколько они похожи на C.
Так что API определяется в первую очередь языком.

Если хочешь понять как сделать хороший API на .NET, то читай Framework Design Guidelines, там все описано и есть комментарии почему так.

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

А>>Дело не только в C, хотя возможности языка трудно отделить от парадигмы, которую он реализует. Можно сравнить WinAPI с интерфейсами Mac OS, написанными на C в объектно-ориентированном стиле. Разница в структурированности, интуитивности и удобстве огромна, и это только за счет объектно-ориентированной группировки.
G>В маках objective c, это сосвем другой язык. И ты сам видишь как возможности языка влияют на API и дело вовсе не в ООП, возьми например javascript и посмотри какие там API получаются и насколько они похожи на C.

Нет, я имел в виду C, что-то типа этого.

JavaScript — это объектно-ориентированный язык (прототипное ООП). И интерфейсы там обычно объектно-ориентированные.

G>Так что API определяется в первую очередь языком.

API, как правило, определяется парадигмой, которой определяется язык.

Но речь была вообще не про это. Ладно, общую идею я понял, никакого метода ты не предлагаешь, просто "функции надо [куда-нибудь] отделять от классов с данными", и "ООП у каждого свое". Понятно, спасибо.

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

G>Не существует теории ООП. ООП у каждого свое.

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

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

А>JavaScript — это объектно-ориентированный язык (прототипное ООП). И интерфейсы там обычно объектно-ориентированные.
Ууу, наверное стоит поближе познакомиться с js
Для затравки: там классов нет и инкапсуляция совсем не объектами делается, а функциями.

G>>Так что API определяется в первую очередь языком.
А>API, как правило, определяется парадигмой, которой определяется язык.
Ну то есть языком.

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

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

BB>>Паттерн State. Выставлять через состояние объект с набором свойств, доступных для
BB>>показа пользователю в данном состоянии.
S>Имхо, неудачный подход.

Как вариант, определить свойство State: enum и сопоставить ему возможные переходы.
На свойства/метода навесить атрибуты, управляющие показом в зависимости от состояния.
В UI анализировать MethodDescriptor на необходимость отрисовки в виде Control в текущем
состоянии.

S>Во-первых, предыдущие решения хотя бы проверяются при компиляции/первом связывании.

Проверяются в смысле? Есть TypeDescriptor с массивом PropertyDescriptor-ов. Задача
показывать/не показывать отдельные свойства в зависимости от состояния, которому
можно сопоставить TypeDescriptor.

С точки зрения привязки к событиям можно вычислять дельту. Взяли объект, показали пользователю
копию, он её поправил, отправил обратно, вычислили разницу, отправили в модель. Пусть она
(или контроллер) решает, как на обновление реагировать (аналогично триггерам в RDBMS),
но в результате события UI показывает/скрывает Control-ы, привязанные к Property/Method Descriptor-ам.

Пользователь ввел новые параметры, нажал Save ->
Машина может ездить с текущими параметрами? ->
Да, может. ОК, заменяем состояние на то, где операция Move() доступна и оповещает UI об обновлении ->
UI перерисовывается с кнопкой (контекстным меню) Move.

interface ICar {
   void Move();
}

class Car : ICar {
    class NonMovable : ICar {
        [EditorBrowsable(EditorBrowsableState.Never)]
        void Move();
    }
    class MovableCar : ICar {
        [EditorBrowsable(EditorBrowsableState.Always)]
        void Move();
    }
    private ICar _state;

    ICar State { get; }
}

S>Во-вторых, число различных состояний будет расти очень быстро — комбинаторика, увы.

По каким причинам это число будет расти? Есть объект Car, набор состояний которого
определяются конечным автоматом. Каждое состояние имеет свой View. Откуда быстрый рост?

S>В-третьих, с состоянием UI работает не только через декларативные биндинги, но и в code behind.

Не уловил... Это специфика Microsoft?

S>summary: Делать работу за компилятор и покрывать всю динамику тестами — пустой перевод ресурсов.

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

BB>

BB>class Car : ICar {
BB>    class NonMovable : ICar {
BB>        void Move();
BB>    }
BB>    class MovableCar : ICar {
BB>        void Move();
BB>    }
BB>}
BB>

Non-movable car — эт че такое? Да и еще и с методом Move.

Car.NonMovable.Move — "сдвинуть недвижимую машину".

Извините, не могу удержаться, чтобы не заржать.

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

BB>

BB>interface ICar {
BB>   void Move();
BB>}

BB>class Car : ICar {
BB>    class NonMovable : ICar {
BB>        [EditorBrowsable(EditorBrowsableState.Never)]
BB>        void Move();
BB>    }
BB>    class MovableCar : ICar {
BB>        [EditorBrowsable(EditorBrowsableState.Always)]
BB>        void Move();
BB>    }
BB>    private ICar _state;

BB>    ICar State { get; }
BB>}
BB>

Да, и еще, человек жаловался, что ему придется на каждый метод типа Move делать свойство типа CanMove.

Вы ему резко упростили задачу: теперь ему придется реализовать N * (N — 1) классов, где N — число свойств.

MovableSaleableCar
NonMovableSaleableCar
MovableNonSaleableCar
NonMovableNonSaleableCar

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

А>Здравствуйте, bl-blx, Вы писали:

BB>>

BB>>class Car : ICar {
BB>>    class NonMovable : ICar {
BB>>        void Move();
BB>>    }
BB>>    class MovableCar : ICar {
BB>>        void Move();
BB>>    }
BB>>}
BB>>

А>Non-movable car — эт че такое? Да и еще и с методом Move.

А>Car.NonMovable.Move — "сдвинуть недвижимую машину".

А>Извините, не могу удержаться, чтобы не заржать.

А>

Да ржите сколько угодно. Вам еще, небось, компилируемый код подавай, чтоб понятнее было?
Аннотации-то куда пропали?