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

Цитата korvin @ 11.04.11, 14:39

Цитата D_KEY @ 11.04.11, 10:43

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

а Реймонд говорит, что сначала нужно спроектировать структуры данных, а алгоритмы тогда станут очевидными =)

И я с ним согласен. Кстати, структуры данных и классы очень разные понятия.

Цитата Повстанець @ 11.04.11, 10:50

Можно пример не ООПшной декомпозиции, не превращающей в дикий гиморой её использование. В двух словах, не надо много писать.

связка Tcl/Tk, если не ошибаюсь неООПшна, а она считается одной из самых простых и удобных

И вообще я сам за ООП, просто решил поддержать разговор

Добавлено 11.04.11, 14:45

Цитата korvin @ 11.04.11, 14:44

Цитата Повстанець @ 11.04.11, 10:50

Можно пример не ООПшной декомпозиции, не превращающей в дикий гиморой её использование. В двух словах, не надо много писать.

связка Tcl/Tk, если не ошибаюсь неООПшна, а она считается одной из самых простых и удобных

А слайды?

Цитата D_KEY @ 11.04.11, 10:59

Никто не мешает. И это уже будет не ООП, если ключевыми компонентами системы являются алгоритмы, действия и модули, а объекты вторичны, не обладают самостоятельным поведением и не определяют систему.

смотря под каким углом смотреть =) в ФП можно считать функции -- объектами, а структуры данных -- сообщениями (в противоположность ООП). если еще взять не чистое ФП, а как в Scheme, например, то вообще получаются полноценные объекты с "поведением" и внутренним состоянием

Добавлено 11.04.11, 14:48

Цитата D_KEY @ 11.04.11, 14:43

И я с ним согласен. Кстати, структуры данных и классы очень разные понятия.

не очень

Цитата korvin @ 11.04.11, 14:47

Цитата D_KEY @ 11.04.11, 10:59

Никто не мешает. И это уже будет не ООП, если ключевыми компонентами системы являются алгоритмы, действия и модули, а объекты вторичны, не обладают самостоятельным поведением и не определяют систему.

смотря под каким углом смотреть =) в ФП можно считать функции -- объектами, а структуры данных -- сообщениями (в противоположность ООП). если еще взять не чистое ФП, а как в Scheme, например, то вообще получаются полноценные объекты с "поведением" и внутренним состоянием

Ну и в ООП, можно завести много "callable"-объектов и построить декомпозицию системы на их основе Использовать исключительно immutable-object и фабрики...
Будет почти-что ФП

Добавлено 11.04.11, 14:51

Цитата korvin @ 11.04.11, 14:47

Цитата D_KEY @ 11.04.11, 14:43

И я с ним согласен. Кстати, структуры данных и классы очень разные понятия.

не очень

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

Сообщение отредактировано: D_KEY - 11.04.11, 14:52

О чем вообще холивар-то идет?

Цитата D_KEY @ 11.04.11, 14:50

В классе важнее интерфейс, а не реализация. Одна из основных задач класса - описывать АТД...

не обязательно. контрпример: CLOS =)

Добавлено 11.04.11, 15:08

Цитата D_KEY @ 11.04.11, 14:50

и фабрики...

фабрики-то зачем? =)

Цитата D_KEY @ 11.04.11, 10:33

Или автор STL говорит чушь?

Во-первых, хотелось бы услышать от тебя стадии реализации ПО. Все Вот прямо как бы ты делал/делаешь.
Во-вторых, уж от тебя то не ожидал "автор STL". Неужели придётся объяснять, что авторитет впереди доводов есть зло?

Цитата Romkin @ 11.04.11, 15:04

О чем вообще холивар-то идет?

Да был вброс против ООП, я ради порядка решил поддержать, ибо понимаю, что тут большинство за ООП. Но у меня не очень удачно получилось

Добавлено 11.04.11, 17:15

Цитата korvin @ 11.04.11, 15:07

Цитата D_KEY @ 11.04.11, 14:50

В классе важнее интерфейс, а не реализация. Одна из основных задач класса - описывать АТД...

не обязательно. контрпример: CLOS =)

Ну значит там какой-то неправильный ООП
Просто теория ООП говорит именно об этом. Тот же Мейер...

Цитата

Цитата D_KEY @ 11.04.11, 14:50

и фабрики...

фабрики-то зачем? =)

Чтобы удобнее было конструировать объекты с полиморфным поведением(возвращаем интерфейс/абстрактный класс, умеющий "вызываться" с соответствующими параметрами).

Добавлено 11.04.11, 17:25

Цитата MyNameIsIgor @ 11.04.11, 15:16

Цитата D_KEY @ 11.04.11, 10:33

Или автор STL говорит чушь?

Во-первых, хотелось бы услышать от тебя стадии реализации ПО. Все Вот прямо как бы ты делал/делаешь.

Вау. Необычные просьбы сегодня на меня так и сыпятся.
Простой цикл: анализ-проектирование-реализация-тестирование-внедрение тебя не устроит?
В основном итеративная разработка, хотя частично применяем scrum.

Цитата

Во-вторых, уж от тебя то не ожидал "автор STL". Неужели придётся объяснять, что авторитет впереди доводов есть зло?

А кто говорит об авторитете? Если не заметил, то я задавал вопрос. STL я решил упомянуть для достижения нескольких целей. В частности, для пояснения тем, кто не знает Степанова, а также напоминание о неплохой библиотеке, в которой ООП не используется(в отличие от библиотек схожей функциональности в других языках, поддерживающий и пропагандирующих ООП).

Сообщение отредактировано: D_KEY - 11.04.11, 17:26

Цитата D_KEY @ 11.04.11, 17:11

Ну значит там какой-то неправильный ООП
Просто теория ООП говорит именно об этом. Тот же Мейер...

там один из самых правильных ООП =)

Цитата korvin @ 11.04.11, 17:32

Цитата D_KEY @ 11.04.11, 17:11

Ну значит там какой-то неправильный ООП
Просто теория ООП говорит именно об этом. Тот же Мейер...

там один из самых правильных ООП =)

Ну это как смотреть А чем там являются классы и почему они не описывают АТД?

Цитата D_KEY @ 11.04.11, 17:11

Чтобы удобнее было конструировать объекты с полиморфным поведением(возвращаем интерфейс/абстрактный класс, умеющий "вызываться" с соответствующими параметрами).

эм... не понимаю о чем ты. нужна только лишь реализация алгебраических типов данных

Добавлено 11.04.11, 17:36

Цитата D_KEY @ 11.04.11, 17:34

А чем там являются классы и почему они не описывают АТД?

метаобъектами =) стандратные классы описывают объект как набор слотов.

Цитата korvin @ 11.04.11, 17:34

нужна только лишь реализация алгебраических типов данных

А в "классических" языках с ООП они и реализуются через абстрактный класс и наследников + проверка типов во время выполнения ну или абстрактной операции. В С/С++ правда можно сделать через размеченные объединения(struct + union + enum с тегом варианта), но это не очень красиво и удобно.

Цитата

Цитата D_KEY @ 11.04.11, 17:34

А чем там являются классы и почему они не описывают АТД?

метаобъектами =) стандратные классы описывают объект как набор слотов.

И как это противоречит АТД?
Только не заставляй меня описывать стэки

Сообщение отредактировано: D_KEY - 11.04.11, 17:41

Цитата D_KEY @ 11.04.11, 17:41

И как это противоречит АТД?

прямо

Цитата

An abstract data type is defined indirectly, only by the operations that may be performed on it

в C++ эти операции описываются непосредственно в классе, поэтому класс может быть АТД, в ЦЛ же в классе никакие операции не описываются (кроме, опционално примитивных акцессоров => классы в ЦЛ не могут описывать АТД. стандартные классы не могут =)

Цитата korvin @ 11.04.11, 18:03

в ЦЛ же в классе никакие операции не описываются (кроме, опционално примитивных акцессоров => классы в ЦЛ не могут описывать АТД. стандартные классы не могут =)

А что в них тогда вообще описывается?