Чем больше я проникаюсь идеями ООП, тем больше возникает ощущение, что я это уже где-то видел

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

С появлением Паттернов от Банды Четырех эта идея окончательно оформилась — вместо того, чтобы скрыть побольше, надо стремиться показать поменьше. Теперь у нас есть интерфейс, и мы можем с ним работать, ничего не зная о том, что за сущность за ним скрывается — и нам собственно все равно, главное, что она реализовывает нужный нам интерфейс.

А теперь вспомним, как развивались определения в математике. Сначала просто тыкали пальцем — вот это то, а вот это — это. А потом появились аксиоматические определения — например, расстояние — это любая штука такого-то рода, удовлетворяющая таким-то и таким-то аксиомам. И нам все равно, что это за расстояние — евклидова метрика на плоскости, или метрика Хаусдорфа на пространстве компактов. Ну как здесь не сказать, что например, норма реализует интерфейс "расстояние"?

Или вот еще — иерархия классов и множество теорем в математике. Если разрешить множественное наследование, то каждый новый класс наследует какое-то количество уже созданных, а каждая теорема опирается в доказательстве на какое-то подмножество уже доказанных. И при этом верхушки иерархий — интерфейсы или аксиоматические определения.

У теоремы есть утверждение и доказательство — интерфейсная часть и реализация.

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

Пишите, что думаете — интересны ваши мысли и наблюдения по этому поводу

Интересная мысль...

Я тебе более скажу, когда после изучения одного раздла математики
я притупал к другому, то я тоже ловил себя на мысле "Где-то я это уже видел..."

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

А>В общем, по настоящему новых идей мало.
А>Но зато есть множество интерпретаций (отражений) одной идеи.
во-во! Как у Платона — мир идей

Может, наверное, это и бред, но мне мерещится общая идея в следующих парах:

• Множества и отображения
  
• Объекты и действия
  
• Данные-члены и функции-члены класса
  
• Масса и гравитация
  
• Материя и взаимодействия
  
• Подлежащее и сказуемое (аналогия между членами предложения и ООП продолжается и дальше)

Предлагаю основать каталогизацию Вселенских Паттернов

Здравствуйте, Кирилл Осенков, Вы писали:

КО>Чем больше я проникаюсь идеями ООП, тем больше возникает ощущение, что я это уже где-то видел

Копайте в сторону алгебры (теория групп). Очень рекомендую посмотреть стандарт языка SDL, в коем была реализована алгебраическая система типов.
Тип определяется множеством литералов, операциями и отношениями эквивалентности (скажем операция умноженя коммутативна, т.е a*b эквивалентно b*a)


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

Здравствуйте, Кирилл Осенков, Вы писали:

А читали книгу Кауфмана "Языки программирования"?
Он там как раз проводит аналогии между математическими понятиями и конструкциями языков программирования.
Чтиво интересное, но не для программистов, хотя и называется "Языки программирования"

Здравствуйте, Кирилл Осенков, Вы писали:

Слышал про науку под названием синергетика? Поинтересуйся, тебе понравится.

Здравствуйте, Кирилл Осенков, Вы писали:

В целом наблюдение верное, позволю себе добавить несколько уточнений:
КО>Например, вот развитие понятия интерфейса в ООП. Начиналось все с того, что некоторые данные из structа научились скрывать. Потом началось повальное скрытие данных — инкапсуляция . И уже в то время оформились обратные идеи — вместо того, чтобы скрывать некоторые данные из всех доступных, надо скрыть все и выдать нагора тщательно отмеренную чуточку — интерфейс. Просто дать обязательство, что помимо всего прочего, я мол являюсь по совместительству и этим-то.

Началось все достаточно давно с появления концепции "Абстрактный Тип Данных" (то, что сейчас в ООП называется "инкапсуляцией"). Определение таково: тип данных, определяемый набором операций над ним. Концепция совершенно математическая, и вообще говоря самостоятельная. Известны языки, поддерживающие только инкапсуляцию, без наследования и полиморфизма. Уже в конце 70-х курс обучения программированию в Массачусетском технологическом институте был полностью основан на концепции ADT. Желающие могут ознакомиться с этим курсом и сейчас в замечательной книге "Использование абстракций и спецификаций при разработке программ" (Лисков Б., Гатэг Дж. 1989). Кстати, если кто не читал, рекомендую , получите массу удовольствия.

КО>С появлением Паттернов от Банды Четырех эта идея окончательно оформилась — вместо того, чтобы скрыть побольше, надо стремиться показать поменьше. Теперь у нас есть интерфейс, и мы можем с ним работать, ничего не зная о том, что за сущность за ним скрывается — и нам собственно все равно, главное, что она реализовывает нужный нам интерфейс.

Идея, соответственно, оформилась еще до вхождения в моду ООП. Единственное, что Gang of Four сделали действительно полезного — они дали паттернам имена, и теперь разработчики могут лучше понимать друг друга, когда обсуждают дизайн. Ну, кроме того, что они написали хорошую и интересную книгу

КО>Или вот еще — иерархия классов и множество теорем в математике. Если разрешить множественное наследование, то каждый новый класс наследует какое-то количество уже созданных, а каждая теорема опирается в доказательстве на какое-то подмножество уже доказанных. И при этом верхушки иерархий — интерфейсы или аксиоматические определения.

Отношение "следствие" в математике ИМХО не очень хорошая аналогия отношения тип-подтип в ООП. Наследование, это почти что отношение "подмножество". Почему "почти"? Вот пара задачек, как раз на эту тему:
1) Связанны-ли отношением "подкласс" действительные и комплексные числа. Если да, то как. Требуется аргументированный ответ.
2) То же для круга и эллипса.

Великолепные задачки, имхо. Позволяют на практике проверить, как именно человек понимает ООП.

AVK>Слышал про науку под названием синергетика? Поинтересуйся, тебе понравится.
Для меня идеи просто духозахватывающие, никакая фантастика не катит. Только вот... попробовал почитать Пригожина и Изабеллу-Не-Помню-Фамилии-Кажется-Сэндерс... и ничего не понял Не по зубам еще наверное

Я еще не гуглил, когда будет минутка гляну, может наткнусь на что-нибудь попроще и попопулярней

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

G>2) То же для круга и эллипса.

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

Все операции для эллипса доступны и для круга. Также у круга есть дополнительные операции.

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

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

GG>Началось все достаточно давно с появления концепции "Абстрактный Тип Данных" (то, что сейчас в ООП называется "инкапсуляцией"). Определение таково: тип данных, определяемый набором операций над ним. Концепция совершенно математическая, и вообще говоря самостоятельная. Известны языки, поддерживающие только инкапсуляцию, без наследования и полиморфизма. Уже в конце 70-х курс обучения программированию в Массачусетском технологическом институте был полностью основан на концепции ADT. Желающие могут ознакомиться с этим курсом и сейчас в замечательной книге "Использование абстракций и спецификаций при разработке программ" (Лисков Б., Гатэг Дж. 1989). Кстати, если кто не читал, рекомендую , получите массу удовольствия.
Согласен! Классное чтиво!

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

AVK>Здравствуйте, Кирилл Осенков, Вы писали:

AVK>Слышал про науку под названием синергетика? Поинтересуйся, тебе понравится.
А еще теория катастроф и теория хаоса.

DG>Эллипс — базовый класс, круг наследуется от эллипса.
Лично я не стал бы связывать эллипс и окружность отношением "подтип". Они оба реализуют интерфейс "эллипс" — это да. Объект типа эллипс может в очень частном случае оказаться окружностью, более того, у него может быть конструктор, инициализируемый объектом типа "окружность". Но способ задания разный.

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

DG>Также у круга есть дополнительные операции.
Круг — подтип эллипса — навязывает задание фокусами и эксцентрисситетом (или полуосями, или еще сотней способов — но не центром и радиусом). Если мы хотим эффективно обращаться с окружностями, их просто необходимо задавать центром и радиусом, иначе это будет очень неестественно.

DG>Я бы даже сказал, что круг поддерживает интерфейс эллипса, а не наследуется от эллипса, т.к. хранить те же два фокуса уже не надо.
Во. Это да.

Здравствуйте, Кирилл Осенков, Вы писали:

КО>Я еще не гуглил, когда будет минутка гляну, может наткнусь на что-нибудь попроще и попопулярней

http://www.keldysh.ru/departments/dpt_17/urss/ser.html

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

AVK>>Слышал про науку под названием синергетика? Поинтересуйся, тебе понравится.
LVV>А еще теория катастроф и теория хаоса.

А это оно и есть. По крайней мере второе совершенно точно.

Здравствуйте, Кирилл Осенков, Вы писали:

DG>>Все операции для эллипса доступны и для круга.
КО>Ну не знаю. А операция "сжать в n раз к большей оси? А как насчет провести прямую через фокусы?

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

class Ellipse
{
  virtual Vector BigAxis {get {return (Focus1 - Focus2).Normalize();}}
}

class Circle:
  Ellipse
{
  override Vector BigAxis {get {return new Vector(0, 1);}}
}

тогда все эти операции продолжают работать.


DG>>Также у круга есть дополнительные операции.
КО>Круг — подтип эллипса — навязывает задание фокусами и эксцентрисситетом (или полуосями, или еще сотней способов — но не центром и радиусом). Если мы хотим эффективно обращаться с окружностями, их просто необходимо задавать центром и радиусом, иначе это будет очень неестественно.

DG>>Я бы даже сказал, что круг поддерживает интерфейс эллипса, а не наследуется от эллипса, т.к. хранить те же два фокуса уже не надо.
КО>Во. Это да.

Но ведь часть реализации тоже можно наследовать.

Здравствуйте, Кирилл Осенков, Вы писали:

DG>>Также у круга есть дополнительные операции.
КО>Круг — подтип эллипса — навязывает задание фокусами и эксцентрисситетом (или полуосями, или еще сотней способов — но не центром и радиусом). Если мы хотим эффективно обращаться с окружностями, их просто необходимо задавать центром и радиусом, иначе это будет очень неестественно.

Особого противоречия — здесь нет:

class Ellipse
{
  public Ellipse(Point focus1, Point focus2, double excentriset){..}
}

class Circle:
  Ellipse
{
  public Circle(Point center, double radius):
   base(center, center, CalcExcentriset(center, radius)){}
}

Конечно, если мы говорит о наиболее эффективной реализации, тогда да. Есть interface IEllipse, который эллипс и круг реализуют немного по разному.

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

DG>Здравствуйте, Кирилл Осенков, Вы писали:

DG>>>Все операции для эллипса доступны и для круга.
КО>>Ну не знаю. А операция "сжать в n раз к большей оси? А как насчет провести прямую через фокусы?

DG>Считаем, что для круга ось, например, всегда вертикальна
DG>

DG>class Ellipse
DG>{
DG>  virtual Vector BigAxis {get {return (Focus1 - Focus2).Normalize();}}
DG>}

DG>class Circle:
DG>  Ellipse
DG>{
DG>  override Vector BigAxis {get {return new Vector(0, 1);}}
DG>}
DG>

DG>тогда все эти операции продолжают работать.

Попался!

Грабли номер 1: в императивных языках с поддержкой ООП есть ограничение на операции. Они должны быть замкнуты, т. е. не выводить экземпляр класса из этого класса. Для функциональных языков это не так, но это случай отдельный и экзотический.

Применение stretch ("сжать в n раз к большей оси") в твоем примере выведет экземпляр Circle из класса Circle, и он станет эллипсом (так как ты все-таки согласился ввести ось для круга). Если не согласен, то просто попробуй написать метод stretch.

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


G>Попался!

Да, про то, что круг перестает быть кругом не подумал. ступил.

G>Грабли номер 1: в императивных языках с поддержкой ООП есть ограничение на операции. Они должны быть замкнуты, т. е. не выводить экземпляр класса из этого класса. Для функциональных языков это не так, но это случай отдельный и экзотический.

Императивные языки — это какие?

Если имеются ввиду — строго типизированные, то в них такие операции (которые меняют тип объекта) плохо реализуются.

G>Применение stretch ("сжать в n раз к большей оси") в твоем примере выведет экземпляр Circle из класса Circle, и он станет эллипсом (так как ты все-таки согласился ввести ось для круга). Если не согласен, то просто попробуй написать метод stretch.

Маленько освобожусь и отвечу

Здравствуйте, Кирилл Осенков, Вы писали:

DG>>Эллипс — базовый класс, круг наследуется от эллипса.
КО>Лично я не стал бы связывать эллипс и окружность отношением "подтип". Они оба реализуют интерфейс "эллипс" — это да. Объект типа эллипс может в очень частном случае оказаться окружностью, более того, у него может быть конструктор, инициализируемый объектом типа "окружность". Но способ задания разный.

КО>Круг — подтип эллипса — навязывает задание фокусами и эксцентрисситетом (или полуосями, или еще сотней способов — но не центром и радиусом). Если мы хотим эффективно обращаться с окружностями, их просто необходимо задавать центром и радиусом, иначе это будет очень неестественно.

На способ задания как важный критерий здесь ориентироваться нельзя. Это надо, конечно, принимать во внимание при разработке реальной системы, но это не должно являться аргументом первой значимости при разработке объектной модели. Речь идет об абстрактных типах данных, которые определяются через поведение, а не структурой. Что такое табуретка? Сидение + четыре ножки (видим экземпляр табуретки)? Сидение с массивом ножек от одной до четырех (вспомнили про табуретку для рояля и другие странные табуретки)? Или то, на чем можно сидеть без опоры для спины?

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

DG>>Все операции для эллипса доступны и для круга.
КО>Ну не знаю. А операция "сжать в n раз к большей оси? А как насчет провести прямую через фокусы?
А вот это очень правильные вопросы

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

DG>Императивные языки — это какие?
В которых ты явно прописываешь последовательность операций, "как решать задачу". В непререкаемом, повелительном (imperative) тоне . Проще говоря, процедурные языки. Прошу прощения за заумную лексику.

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