Что-то нетак с ООП - Философия программирования

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

A>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

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

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

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

И при чем здесь ООП, когда проблема в людях.

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

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

V>Ой осторожнее, щас защитники ООП на вас накинутся !!!!
V>Сразу начнется со всех сторон
V>- а как же вы без инкапсуляции ?
V>- а как же вы без наследования ?
V>- а как же паттерны без объектов применять ?

Инкапсуляция и паттерны не являются привилегией ООП.

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

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

LVV>2. Объем задачи, для которой нужно применять ООП, должен быть достаточно велик. Ну, ИМХО от 50000 строк примерно. Иначе просто нерентабельно применять мощнячий инструмент для относительно несложной задачи.

если бы вы использовали TDD, то знали бы, что объем задачи может заканчиваться сотней строк кода — один класс, интерфейсы зависимостей, mock-классы зависимостей, тесты

void beginDoFoo()
{
    doStepOne();
    doStepTwo();
    async_doStepThree([this](){ completeDoFoo(); });
}

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

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

LVV>>2. Объем задачи, для которой нужно применять ООП, должен быть достаточно велик. Ну, ИМХО от 50000 строк примерно. Иначе просто нерентабельно применять мощнячий инструмент для относительно несложной задачи.

A>если бы вы использовали TDD, то знали бы, что объем задачи может заканчиваться сотней строк кода — один класс, интерфейсы зависимостей, mock-классы зависимостей, тесты
Можно пример конкретной реальной ЗАДАЧИ, объем которой заканчивается сотней строк.
Мне таких ЗАДАЧ не попадалось...

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

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

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

LVV>>>2. Объем задачи, для которой нужно применять ООП, должен быть достаточно велик. Ну, ИМХО от 50000 строк примерно. Иначе просто нерентабельно применять мощнячий инструмент для относительно несложной задачи.

A>>если бы вы использовали TDD, то знали бы, что объем задачи может заканчиваться сотней строк кода — один класс, интерфейсы зависимостей, mock-классы зависимостей, тесты
LVV>Можно пример конкретной реальной ЗАДАЧИ, объем которой заканчивается сотней строк.
LVV>Мне таких ЗАДАЧ не попадалось...

Вы наверное не прочитали слово "TDD".

Пример задачи — написать класс Foo c интерфейсом IFoo, который делает то-то, используя переданные ему объекты с интерфейсами IBar и IBaz.
Это реальная задача которая решается программистом при написании программы в 100'000 строк.
"скопировать данные из IInputStream в IOutputStream"
"запросить данные у IFooDevice и обновить IFooStateWindow"
"добавить AUserCommand в IMacroRecorder"

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

A>>>если бы вы использовали TDD, то знали бы, что объем задачи может заканчиваться сотней строк кода — один класс, интерфейсы зависимостей, mock-классы зависимостей, тесты
LVV>>Можно пример конкретной реальной ЗАДАЧИ, объем которой заканчивается сотней строк.
LVV>>Мне таких ЗАДАЧ не попадалось...
A>Вы наверное не прочитали слово "TDD".
Читал.
A>Пример задачи — написать класс Foo c интерфейсом IFoo, который делает то-то, используя переданные ему объекты с интерфейсами IBar и IBaz.
A>Это реальная задача которая решается программистом при написании программы в 100'000 строк.
A>"скопировать данные из IInputStream в IOutputStream"
A>"запросить данные у IFooDevice и обновить IFooStateWindow"
A>"добавить AUserCommand в IMacroRecorder"
Понятно. Мы просто по-разному понимаем слово "задача".
Я бы назвал это — программирование ООП "в малом"
В описанном вами контексте — это задача. Но ТС сокрушался, что не возможно понять совместную работу классов:

трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием.

А здесь ИМХО имеется ввиду программирование ООП "в большом"...

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

V>>Ой осторожнее, щас защитники ООП на вас накинутся !!!!
V>>Сразу начнется со всех сторон
V>>- а как же вы без инкапсуляции ?
V>>- а как же вы без наследования ?
V>>- а как же паттерны без объектов применять ?

HH>Инкапсуляция и паттерны не являются привилегией ООП.

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

Если серьезно, то пока мы не сможем количественно измерять насколько принципы ООП плохи любая точка зрения это переливание из пустого в порожнее. И вообще, из того что инкапсуляция принадлежит не только ООП не означает её полезность и работоспособность во всем без исключения случаях. И тем более не значит что инкапсуляцию лучше не применять нигде и никогда. Либо надо прощупать более крутую технологию типа DSL и в сравнении познать истинное лицо ООП. Хотя я не совсем уверен что DSL лучше на самом деле.

V>Уже ни раз начиналась подобная тема и защитники ООП воспринимают затруднения как полный отказ от ООП, не понимая, что вопрос сводится не в оценке полезности ООП. Никто никуда никакие объекты выкидывать не собирается. Разве таким объяснишь что если интерфейс изменился хотя бы раз за время жизненного цикла приложения значит инкапсуляция не сработала! Ну и что что мы можем перевыбрать интерфейс? Задача ведь состояла не в использовании примочек, а в гарантированном разделении внутренних и внешних проектных решений по отношению к этому самому объекту. Не сработало разделение. В случае наследования — не сработало обобщение. В случае паттернов вообще молчу.

какой-то совершенно непонятный поток сознания.
вы б хоть по пунктам с примерами.

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

Да, да, во всем виновато ООП, а вовсе не кривые руки!

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

A>Я сильно начинаю сомневаться в полезности ООП.

Не ты один, вот к примеру цитата из интервью с автором STL.

I find OOP technically unsound.

Alex Stepanov

http://www.stlport.org/resources/StepanovUSA.html

Меня ООП в целом устраивает. Но меня бесит наследования реализации классов. Вот хоть убейте меня — мне не нравится.

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

A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания.
Это все потому, что единственной парадигмой программирования, которая обеспечивает читаемость программы, является не ООП и не ФП и не другое хП, а прямые руки и светлая голова программиста. А это приходит только с опытом. А уж на плюсах, лиспе или джаве он будет писать — дело десятое.

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

0>Это все потому, что единственной парадигмой программирования, которая обеспечивает читаемость программы, является не ООП и не ФП и не другое хП, а прямые руки и светлая голова программиста.

Для этого тоже существует аббревиатура — BDD (Brain Driven Development).

Здравствуйте, Enomay, Вы писали:
Не сработало разделение. В случае наследования — не сработало обобщение. В случае паттернов вообще молчу.

E>какой-то совершенно непонятный поток сознания.
E>вы б хоть по пунктам с примерами.

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

Только давайте без разговоров о правильном сознании, правильных программистах, правильном выборе интерфейса и правильных объектах, а также противопоставление всего этого программистам сомневающимся в ООП. Чего-то ООП не хватает, знать бы чего?

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

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

T>Да, да, во всем виновато ООП, а вовсе не кривые руки!

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

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

A>Что-то нетак с ООП
А с жизнью разве так? Смотрите, все в течение жизни болеют, маются всякими проблемами, а итог — помирають.

Сам посыл абсурден — куча ПО написано и работает как раз с использованием ООП, но вдруг с ним что-то не так.

А с чем извините все так? С ФП? И много на нем написано работающего годами ПО?
А может с логическим программированием все замечательно?

Что у нас еще есть — структурное? Да, ядро Linux — известная вещь.
Но с ним как, с структурным программированием — все так, все замечательно?

Присоединяюсь же к ответам в теме — проектировать нужно вначале. На чем бы потом ни кодировал.
А тяп — ляп — никакой подход программирования не простит.
Когда нужно больше чем вывести в консоль "Hello world!"

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

0>>Это все потому, что единственной парадигмой программирования, которая обеспечивает читаемость программы, является не ООП и не ФП и не другое хП, а прямые руки и светлая голова программиста.

IT>Для этого тоже существует аббревиатура — BDD (Brain Driven Development).

Если это и так, то расшифровка как Behavior Driven Development сейчас более популярна.
Надо заменить.

Здравствуйте, Son of Northern Darkness, Вы писали:

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

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

SON>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.
SON>Вот за этим ООП и нужно.

Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.

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

IT>>Для этого тоже существует аббревиатура — BDD (Brain Driven Development).

N>Если это и так, то расшифровка как Behavior Driven Development сейчас более популярна.
N>Надо заменить.

Это временное недоразумение.

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

LVV>Однако некоторые языки (Додиез и Ява, например) программу сразу считают неким классом. И тут легко скатиться от ясных и понятных процессов в полную неразбериху объектов... Инструмент как бы провоцирует...

Та а чем процедуры и функции не классы. Если в голове порядок, то классы сами организуются. Если в этом имеется смысл. у ООП единственный недостаток это жесткое наследование класс-объект. Чуть отличия у объекта так требуется новый класс, что не всегда разумно с предметной точки зрения. ИМХО, конечно.

V>Осталось только определится с критерием понятного потока сознания. А вот с этим как раз большие проблемы. Даже если мы предположим что смена интерфейса (объекта, функции и т.п.) символизирует о нарушении в каком-то смысле задачи инкапсуляции, то как нам это измерить?

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

V>Тем более что последний интерфейс вполне выполняет свою задачу, иначе нафига его оставили?

а я не понимаю для чего вы меняли интерфейс, если он вполне выполняет свою задачу

V>Только давайте без разговоров о правильном сознании, правильных программистах, правильном выборе интерфейса и правильных объектах, а также противопоставление всего этого программистам сомневающимся в ООП. Чего-то ООП не хватает, знать бы чего?

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

SON>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.
SON>>Вот за этим ООП и нужно.

B>Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.

любой подход, будь то ООП, будь то FP, требуют придерживания данного принципа. это основа.

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

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

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

T>>Да, да, во всем виновато ООП, а вовсе не кривые руки!

V>Привет пряморуким, осталось выяснить у кого руки прямее.

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

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

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

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

ваша практика очень плохая и негодная.

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

SON>>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.
SON>>>Вот за этим ООП и нужно.

B>>Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.

E>любой подход, будь то ООП, будь то FP, требуют придерживания данного принципа. это основа.
Нам шашечки или ехать? Прадигма выбирается под задачу или наоборот? Я как-то не очень понимаю такие принципы. Но если хочется. Имеете право придерживаться

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

B>Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.

Какие конкретно задачи ты имеешь ввиду?

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

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

SON>>>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.
SON>>>>Вот за этим ООП и нужно.

B>>>Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.

E>>любой подход, будь то ООП, будь то FP, требуют придерживания данного принципа. это основа.
B>Нам шашечки или ехать? Прадигма выбирается под задачу или наоборот? Я как-то не очень понимаю такие принципы. Но если хочется. Имеете право придерживаться

вы даже не читаете исходное сообщение и не пытаетесь понять то, на что отвечаете. о чем еще можно говорить?

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

E>ваша практика очень плохая и негодная.
Ну, расскажи, как ты собрался повторно использовать кусок бизнеслогики?

Или вот, например https://github.com/rampelstinskin/ParserGenerator
Из всей этой горы кода единственное, что в теории можно использовать для чего-то еще это вот это:
https://github.com/rampelstinskin/ParserGenerator/blob/d06a33f1b4509d5b89baa1e960180551acb5d7d9/Nemerle.Parser.Macro/FSM/FSM.n
https://github.com/rampelstinskin/ParserGenerator/blob/d06a33f1b4509d5b89baa1e960180551acb5d7d9/Nemerle.Parser.Macro/FSM/FSMBuilder.n
https://github.com/rampelstinskin/ParserGenerator/blob/d06a33f1b4509d5b89baa1e960180551acb5d7d9/Nemerle.Parser.Macro/FSM/FSMTransform.n
https://github.com/rampelstinskin/ParserGenerator/blob/d06a33f1b4509d5b89baa1e960180551acb5d7d9/Nemerle.Parser.Macro/RangeSet.n
https://github.com/rampelstinskin/ParserGenerator/blob/d06a33f1b4509d5b89baa1e960180551acb5d7d9/Nemerle.Parser.Macro/UnicodeCategoryTable.n
И кое-что отсюда.
https://github.com/rampelstinskin/ParserGenerator/blob/d06a33f1b4509d5b89baa1e960180551acb5d7d9/Nemerle.Parser.Macro/Util.n

И как я и сказал это код общего назначения не завязанный на конкретную задачу.

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

LVV>>Однако некоторые языки (Додиез и Ява, например) программу сразу считают неким классом. И тут легко скатиться от ясных и понятных процессов в полную неразбериху объектов... Инструмент как бы провоцирует...

B>Та а чем процедуры и функции не классы. Если в голове порядок, то классы сами организуются. Если в этом имеется смысл. у ООП единственный недостаток это жесткое наследование класс-объект. Чуть отличия у объекта так требуется новый класс, что не всегда разумно с предметной точки зрения. ИМХО, конечно.
Как и все в этой жизни, любой навык требует тренировок.
В голове порядок — это только "потом и кровью".
Топикстартер как раз и признается в первом посте, что у него подобного навыка нет.
Путь только один: — делать и дуумать, думать и делать. Тогда и порядок в голове объектно-ориентированный наступит...

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

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

Не совсем верно. Правильно так:

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

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

у меня коллега с вами с радостью согласится — он второй месяц не может скопипастить нужные ему фрагменты кода, т.к. это не одна функция на 1000 строк, которую он мог бы скопипастить парой кликов, а проклятые классы со сраными функциями-членами, и "фиг их разберет, чо там нужно, чо нет" — первые попытки тупо копипастить "нужную", как ему кажется, функцию, провалились — надо копипастить больше, чем один сплошной фрагмент кода (объявления членов, хотя бы), а его мозг макаки на это уже неспособен. смешно, нужного кода ~200 строк, у класса ~4-5 функций членов, но он, похоже, не осилит.

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

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

B>>Не то что бы не правда. Просто устарело. Новые задачи требуют нового подхода.

T>Какие конкретно задачи ты имеешь ввиду?
Да практически все современные. Тут уместнее подойти с другой стороны и вспомнить старые.

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

L_L>у меня коллега с вами с радостью согласится — он второй месяц не может скопипастить нужные ему фрагменты кода, т.к. это не одна функция на 1000 строк, которую он мог бы скопипастить парой кликов, а проклятые классы со сраными функциями-членами, и "фиг их разберет, чо там нужно, чо нет" — первые попытки тупо копипастить "нужную", как ему кажется, функцию, провалились — надо копипастить больше, чем один сплошной фрагмент кода (объявления членов, хотя бы), а его мозг макаки на это уже неспособен. смешно, нужного кода ~200 строк, у класса ~4-5 функций членов, но он, похоже, не осилит.
И что? Работает программистом?
Охренеть!!
Вот потому и падают Фобос-Грунты...

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

U>Код в виде чистых функций повторно используется прекрасно, т.к. никаких лишних зависимостей за собой не тянет.

И давно это с ним?

Как быть, например, с функцией подключения к DB, в реализации которой жёстко задано имя базы, хост, логин для подключения? Или функцией, которая по завершении сложной работы отправляет отчёт по e-mail? Или привязкой к тому, что данные могут быть только в cp1251?

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

Более того, в случае организации в стиле ООП такую параметризацию делать легче, потому что можно организовать подобные специфики работы в виде объектов или объектных свойств и потом "прицепить" их к объектам основной работы. В этом плане очень показательна история развития Berkeley DB.
Версия 1: открытие базы делается 5-аргументной функцией dbopen(), 3 из которых — для open(). Дальше через полученный указатель зовутся методы — такое себе ООП с виртуальными методами, хоть и на голом C.
Версия 2: поняли, что этого недостаточно, переименовали функцию в db_open(), добавили аргументов.
Версия 3: поняли, что разных параметров типа размера страницы, методов изоляции, блокировок и т.д. будет больше, чем можно задать в одной функции, и сделали db_create(), после которой надо настроить всё, что надо (включая будущие добавки) и сделать после этого handle->open(). Теперь уже и создание/открытие базы стало делаться в объектном стиле, а не только последующая работа. (Напоминаю, что это C. Есть интерфейс и для C++, хотя он просто инкапсулирует работу с хэндлом.)

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

U>Не совсем верно. Правильно так:

U>

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

Это неверно, см. выше.
Вы не учитываете, что "функция" может иметь побочные эффекты, это раз.
Жёстко заданные особенности, это два. Причём вопрос не только в логинах, это как раз самый тривиальный пример. Есть более тонкие случаи. Например, для специфики исходной задачи характерно, что одна из порций промежуточных данных не превосходит 10 единиц, поэтому был взят самый тупой метод работы с ними, имеющий суммарную сложность O(n**3). Но у первого же переиспользующего этот код их стало 20000, и код "умер" на управлении этими данными, пришлось переписывать. Таких проблем можно вспомнить десятками из ближайшей практики.

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

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

LVV>Путь только один: — делать и дуумать, думать и делать. Тогда и порядок в голове объектно-ориентированный наступит...

Ага.. Думать, делать и иметь смелость переделать

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

B>Да практически все современные. Тут уместнее подойти с другой стороны и вспомнить старые.

Ну то есть конкретных примеров нет, правильно я понимаю?

E>>ваша практика очень плохая и негодная.
WH>Ну, расскажи, как ты собрался повторно использовать кусок бизнеслогики?

не нужно кидаться в крайности и возводить всё в абсолют.
бизнес логику необходимо повторно использовать там, где этому место. и никто не предлагает тащить её в другое приложение.

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

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

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

класс такой-то...
On_Init...
On_Exit...
On_XXX...
Do_Get

главная функция...
х = новый_класс...
x.run

и ведь ни черта не понятно. ибо вызов On_Init скрыт за фасадом. и до него хрен доберешься. и выясняется, что у нас есть Do_Get, но нету Do_Post. точнее, у нас есть Do_Post, но оно вызывается из кастомного On_Event, который реализован черт знает в каком месте и который зовет Do_Post (если мы его объявили).

> И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб,
> таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться
лобовой код понять зачастую легче потому что он представляет собой пошаговый план действий, которые можно читать последовательно как художественную книгу. вот, допустим, у нас тут цикл для вывода содержимого директории. вот вызовы find_fist, find_next. все понятно. а вот мы решили засунуть это в интератор. создает объект типа "директория", инициализируем чего-то (путь к директории, флаги поиска). создаем функцию иницилизации итератора. создаем функцию "следующий элемент". создаем функцию, возвращающую кол-во объектов. создаем функцию конвертации списка элементов в строку.

пишем o = dir(base_dir, find_all);
for file_name in o...

красиво? да. и меньше вероятность сделать ошибку. но больше объем кода и менее очевидно, что реально происходит внутри for a in b. код нельзя читать линейно, потому что он нелинеен по своей природе.

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

плюс полулегальная возможность у вызываемой мной функции снимать мой обработчик исключений и ничего мне об этом не говорить. и у меня при выбросе исключения управление передается куда-то внутрь и вообще мне не возвращается. и получается, что баг мой (допустим, обращение к нулевому указателю), но я его не могу отловить. это даже похуже GOTO. дочерняя функция не может заставить мой код прыгать в нее иначе как модификацией кода, что очень грязный хак и напрямую в ЯВУ нереализуем. а в ООП и без исключений дочка меняет таблицы виртуальных функций (тоже грязный хак, но таки реализуемый без ассемблерных вставок) и у меня едет крыша.

> На самую простую функциональность количество порой приближается к сотни.
потому что пытаются решить задачу в общем виде. например, когда мы создаем класс "содержимое директории" нам нужно создать методы "длина" и "преобразвание в строку", ибо они _могут_ потребоваться. хотя это жопа и жуткий оверхид. если АПИ не возвращает кол-во файлов в директории и нам нужно их перечислять явно, то на чистом си мы напишем FindFist/FindNext плюс, увеличивающийся на 1 каждый проход цикла. и за один раз получим и содержимое и кол-во элементов. а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию. но если мы хотим оптимизации, то можно схитрить и считать элементы в итераторе. а при достижении конца устанавливать скрытый флаг, что кол-во элементов известно. после чего функция "Длинны" возвратит это значение и все. но это сильно усложняет логику. и простая задача вывода содержимого директории раздувается до невероятных размеров.

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

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

V>>Осталось только определится с критерием понятного потока сознания. А вот с этим как раз большие проблемы. Даже если мы предположим что смена интерфейса (объекта, функции и т.п.) символизирует о нарушении в каком-то смысле задачи инкапсуляции, то как нам это измерить?

E>а с чего вы взяли что смена интерфейса каким-то образом нарушает инкапусуляцию? реализация алгоритмов и внутренние способы представления данных как были так и остались скрыты от внешних глаз.
E>казалось бы, причем тут изменение интерфейса?
E>если у вас изменение интерфейса раскрывает внутреннюю реализацию, так это ведь исключительно ваши проблемы.

Не только мои, это проблемы у всех программистов на этапе проектирования. Вот если бы можно было выбрать интерфейс кое-как а потом без усилий менять сколько угодно раз во время программирования. Вот это бы расслабило напряжение которое требуется для выбора правильного интерфейса. Иначе вся сложность работы переносится на этап проектирования и неверное решение стоит очень дорого. Да видимо как-то так, например применили паттерн, а потом он нам не понравился захотелось все отменить или даже применить совсем другой паттерн. Я так и вижу в своем воображении окно с тремя листингами и свои размышления — вот сейчас перейдем на второй вариант а потом в любой момент можем вернутся на первый. а для заказчика все перекомпилируем в третьем варианте

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

. Вернее этап думания можно отложить на потом.

Ага если принять это в качестве рабочего варианта то тут возникают серьезные концептуальные проблемы. Пару раз пролетало сравнение листинга с математическими описаниями, сопоставлением этой информацией со свойствами программы. Тут люди проталкивающие математический склад мышления в программировании не учитывают некоторых нюансов. Математические модели в теоретической физике тяготеют к тензорному исчислению, это значит что несмотря на разные данные у разных экспериментаторов законы физики должны записываться в одинаковой форме. Другими словами формула гравитации записывается всегда одинакова во всех экспериментах где учитывается закон гравитации. Тензорная форма записи уравнения не зависит от того кто как и где исследует гравитацию. Казалось бы можно и программу для пользователя расписать в тензорной форме, тогда её функциональность останется для пользователя неизменной не зависимо от того как разные программисты программируют, выбирают интерфейсы применяют принципы ООП или не применяют.

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

Т.е. вопрос был каковы тензорные свойства вашего правильного мышления? Так более понятно? Для своего я что-то не могу подобрать ни тензоров ни инвариантов

Никаких инвариантных форм представления паттернов или чего-то подобного.

V>>Тем более что последний интерфейс вполне выполняет свою задачу, иначе нафига его оставили?
E>а я не понимаю для чего вы меняли интерфейс, если он вполне выполняет свою задачу

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

V>>Только давайте без разговоров о правильном сознании, правильных программистах, правильном выборе интерфейса и правильных объектах, а также противопоставление всего этого программистам сомневающимся в ООП. Чего-то ООП не хватает, знать бы чего?
E>от вас много слов, но о сферическом коне в вакууме. полно отсутствие какой либо конкретики. и для чего вы их пишете, совершенно непонятно.

Дак если бы было понятно. Хотелось бы.

М>а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию.

мда.

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

V>Дак если бы было понятно. Хотелось бы.

давайте вы приведете какие-то примеры кода, с проблемами. так будет понятнее.
а пока это просто размышления.

LVV>И что? Работает программистом?
LVV>Охренеть!!
LVV>Вот потому и падают Фобос-Грунты...

Работает! Этот его "культ Карго от программирования" продолжается уже лет 30. Фобосы не падают, его до такого никто в здравом уме не допустит, а его код, который он высрал лет 10 назад и на поддержке багов которого он, собственно, и живет —
"работает".

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

М>>а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию.

E>мда.
что мда? реализуйте мне класс "директория" с итератором и с api функциями FindFirst/FindNext, т.е. подсчитать сколько у нас элементов можно _только_ через вызов ff/fn. и через пост-процессинг (может мы поиск файла по регуляркам поддерживаем и api оси в ни жизнь не узнают сколько у нас там чего).

len реализуется только через итерирование. и никак иначе. и вывод имен файлов тоже.
for name in dir:
print name;
print len(dir);

и
count = 0;
for name in dir:
print name
count +=1
print count;

вы можете сказать что быстрее? нет, не можете. реализацию нужно смотреть. или доки читать. это плата за унифицированность и абстракцию. с этим вообще сложно спорить.

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

М>>>а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию.
E>>мда.
М>что мда? реализуйте мне класс "директория" с итератором и с api функциями FindFirst/FindNext, т.е. подсчитать сколько у нас элементов можно _только_ через вызов ff/fn. и через пост-процессинг (может мы поиск файла по регуляркам поддерживаем и api оси в ни жизнь не узнают сколько у нас там чего).

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

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

E>не нужно кидаться в крайности и возводить всё в абсолют.
E>бизнес логику необходимо повторно использовать там, где этому место. и никто не предлагает тащить её в другое приложение.
Ну, так расскажи как надо.
Покажи свою очень хорошую и годную практику.
Я тебе показал свой очень плохой и не годный проект.
Там чуть менее чем все функции используются ровно один раз.
Покажи, как это делают реальные пацаны. Чтобы все было круто и годно.
Чтобы каждая функция использовалась хотя бы 5 раз.
Иначе что это за повторное использование...
Кстати ООП там отсутствует чуть менее чем совсем.

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

М>>>>а по правилам ООП мы вынуждены перечитывать директорию два раза. это плата за абстракцию.
E>>>мда.
М>>что мда? реализуйте мне класс "директория" с итератором и с api функциями FindFirst/FindNext, т.е. подсчитать сколько у нас элементов можно _только_ через вызов ff/fn. и через пост-процессинг (может мы поиск файла по регуляркам поддерживаем и api оси в ни жизнь не узнают сколько у нас там чего).

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

E>если len нужно знать после итерирования, то она у нас уже есть, и повторно считать ничего не надо.
об этом я писал. но тут свои нюансы. len не будет перечитывать директорию и фиг его знает как ее обновить. итерировать снова?

E>если len получают до того, мы итерируем все элементы в фолдере и сохраняем len.
E>так же мы можем сохранить все элементы фолдера.
не можем. считаем, что кол-во памяти для хранения всех элементов очень велико. если элементы можно сохранить в памяти, то их можно вернуть одним списком и на фига нам цикл с итератором?

E> тем самым любое последующее обращение к нашему классу сразу вернет готовый
E> разультат без повторного считывания информации с диска.
E> где проблема?
проблем две.
первая -- при итерировании вызывается ff/fn и возвращается актуальный контент. при сохранении контента внутри класса -- увы.
вторая -- памяти может потребоваться очень много.

впрочем, перечитывание тоже имеет проблемы. результат возвращенный len может быть иным, чем кол-во интрированных элементов, т.к. ось живет своей жизнью и абстракция типа "директория" очень кривая абстракция. и чтобы она работала правильно -- нужно еще api для перехвата событий в файловой системе. но даже в этом случае остается проблема, что делать с len. если возвращать счетчик итератора то мы получаем неактуальный результат. если возвращать кол-во элементов на момент вызова len -- оно может не совпадать с тем, что мы получили ранее при итерации.

другими словами, реализовать правильно работающую абстракцию нельзя. ну потому что нельзя и все тут. и оно либо работает в 99 из 100, либо размеры кода поражают воображение, а размер спецификации рвет крышу. у нас есть len, но либо его нельзя применять к кол-ву итераций, либо с его помощью нельзя получать кол-во элементов на момент вызова.

наиболее правильным решением будет модель, реализующая копирование при записи. т.е. мы пишем: for a in b: res.append(a); а при изменении содержимого директории res меняется автоматом. но мне страшно представить объем кода. как минимум нужно переписать весь RTL и все стандартные либы.

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

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

Здравствуйте, мыщъх, Вы писали:

[поскипано]

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

Здравствуйте, мыщъх, Вы писали:

М>драматизм ситуации в том, что в си все каллбэки объявляются явно. а вот в ооп они хитро скрыты.

Ой не говори. Ты когда-нибудь копался, например, в ядре? Там, где read() на дескриптор дёргает функцию заранее неизвестно какого объекта (даже если он выглядит как структура с полем softc)? Это тот же ООП, только оформленный менее явно.

Некоторые задачи в принципе требуют объектно-ориентированной реализации, независимо от того, на каком языке они написаны. Но в ОО языке это будет явно, на C это будет вызов по типу fdp->fd_softc->read(), на Erlang это будет gen_server:call(Ref, foo), ещё где-то это может быть вообще реализовано как вызов Неведомой Сжиженной Триокиси или обращение с заданной молитвой к Его Пастафарианству. В любом из этих вариантов автор чётко определяет "объект" для воздействия, "метод" воздействия и что говорится этому методу. Как только есть явно оформленное обращение и три перечисленных "свойства" этого обращения — мы имеем дело с ООП.
(Дальше уже кто-то может говорить, что для ООП требуется инкапсуляция, наследование и так далее. Я сейчас не об этом, а о более высоком принципе.)

М>и ведь ни черта не понятно. ибо вызов On_Init скрыт за фасадом. и до него хрен доберешься. и выясняется, что у нас есть Do_Get, но нету Do_Post. точнее, у нас есть Do_Post, но оно вызывается из кастомного On_Event, который реализован черт знает в каком месте и который зовет Do_Post (если мы его объявили).

И опять-таки такая фигня может быть на любом языке. Я вот работал с одним пакетом, у которого стандартизованные обработчики были составлены в матрицу конвейеров. Ты "вставляешь" в определённую позицию обработчик — и функционирование всей системы резко меняется. В случае обычного ООП у тебя хоть есть возможность вычислить фиксированный, известный при компиляции порядок и зависимости исполнения кода.

М>лобовой код понять зачастую легче потому что он представляет собой пошаговый план действий, которые можно читать последовательно как художественную книгу. вот, допустим, у нас тут цикл для вывода содержимого директории. вот вызовы find_fist, find_next. все понятно. а вот мы решили засунуть это в интератор. создает объект типа "директория", инициализируем чего-то (путь к директории, флаги поиска). создаем функцию иницилизации итератора. создаем функцию "следующий элемент". создаем функцию, возвращающую кол-во объектов. создаем функцию конвертации списка элементов в строку.

М>пишем o = dir(base_dir, find_all);
М>for file_name in o...

М>красиво? да. и меньше вероятность сделать ошибку. но больше объем кода и менее очевидно, что реально происходит внутри for a in b. код нельзя читать линейно, потому что он нелинеен по своей природе.

А с чего ты решил, что он раньше был линеен? Тот же find_first() может вычитывать целую порцию данных из каталога (или его целиком) и запоминать их. А может пользоваться средствами ОС для этого. Где-то может происходить сортировка данных, чтобы выдавать записи каталога в определённом порядке. А ты надеешься на то, что find_first() тебе будет работать так же, как если бы ты шёл вдоль улицы и считал дома и деревья? Это плохой, негодный пример. То же касается и оценки количества записей. У тебя она может, например, дать другое значение, чем подсчёт прочтённых элементов, потому что пока ты их читал — что-то добавилось и что-то изменилось.

Может, ты тут в каком-то случае прав, но этот пример точно не подходит под описание.

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

М>плюс полулегальная возможность у вызываемой мной функции снимать мой обработчик исключений и ничего мне об этом не говорить.

Этого не понял, можно подробнее?

M> и у меня при выбросе исключения управление передается куда-то внутрь и вообще мне не возвращается. и получается, что баг мой (допустим, обращение к нулевому указателю), но я его не могу отловить. это даже похуже GOTO. дочерняя функция не может заставить мой код прыгать в нее иначе как модификацией кода, что очень грязный хак и напрямую в ЯВУ нереализуем. а в ООП и без исключений дочка меняет таблицы виртуальных функций (тоже грязный хак, но таки реализуемый без ассемблерных вставок) и у меня едет крыша.

Это не в ООП, это в конкретном C++ или C. Или в любом другом, где разрешена игра с указателями и генерация их из чисел.

М>потому что пытаются решить задачу в общем виде. например, когда мы создаем класс "содержимое директории" нам нужно создать методы "длина" и "преобразвание в строку", ибо они _могут_ потребоваться. хотя это жопа и жуткий оверхид.

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

M> если АПИ не возвращает кол-во файлов в директории и нам нужно их перечислять явно, то на чистом си мы напишем FindFist/FindNext плюс, увеличивающийся на 1 каждый проход цикла. и за один раз получим и содержимое и кол-во элементов. а по правилам ООП мы вынуждены перечитывать директорию два раза.

Никто не вынужден. Точно так же можно возвращать длину только если явно пройдено перечисление или запрошена длина заранее (но тогда должно быть указано, что до завершения первого прогона это дорогая операция). А ещё можно закэшировать несколько первых элементов, насколько хватит памяти, чтобы сократить старт, если длину спросили до первого прогона итерирования. И всему этому ООП не противоречит, а, наоборот, способствует (ты зовёшь next() у объекта, не интересуясь, он это берёт из кэша или у ОС).

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

Если ты будешь реализовывать ту же самую логику, то она потребует таких же хитростей и разрастётся до таких размеров. Но вместо ясного отделения сущностей у тебя будет каша в коде.

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

Ну так и не надо строить на неизвестное будущее. Вот зачем тебе "вывод в строку", когда он ещё не требовался?

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

N>И давно это с ним?

Это второстепенная проблема, которая решается достаточно легко грамотной декомпозицией. Основная проблема повторного использования функциональности в ООП заключается в следующем.

Есть объект на десяток сущностей, при использовании ООП мы прибиваем к этому объекту гвоздями функциональность требующую и все 10 сущностей, и 3 сущности из 10, и 1 сущность из 10 и т.д. Соответственно завтра у нас возникает задача, в которой нужна часть из уже реализованной в этом классе функциональности. Реально для этой функциональности нужно всего 3 сущности, которые в новой задаче у нас есть, однако чтобы создать класс нам нужно еще семь сущностей, которых в новой задаче и близко нет. Соответственно получаем картину Репина приплыли, с дальнейшим дублированием кода и прочими прелестями. При использовании чистых функций такой проблемы нет, т.к. если для какой-то функциональности нужны только 3 сущности, то эта чистая функция только 3 этих сущности и будет принимать. А дальше эта чистая функция может использоваться и внутри ООП объекта, и где угодно.

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

ООП как обертка над чистыми функциями это прекрасный инструмент. ООП как функциональность прибитая к объектам это тот еще ужас.

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

N>>И давно это с ним?

U>Это второстепенная проблема, которая решается достаточно легко грамотной декомпозицией.

Простите, при чём тут декомпозиция? От того, что мы разобъём задачу на десяток более мелких, она не станет от этого более гибко реализованной.

U> Основная проблема повторного использования функциональности в ООП заключается в следующем.
U>Есть объект на десяток сущностей,

Уже непонятно, что имеется в виду. При идеальном проектировании одной сущности предметной области или специфики её реализации должен соответствовать один объект. Ладно, пусть у нас тут сплошные криворукие, других не смогли нанять — в одном объекте смешиваются 2-3 сущности или их важные аспекты. Но 10?
Или Вы словом "сущность" обозначили что-то своё особое?

U> при использовании ООП мы прибиваем к этому объекту гвоздями функциональность

Это тоже непонятно — что такое "прибить к объекту функциональность (гвоздями)".

U> требующую и все 10 сущностей, и 3 сущности из 10, и 1 сущность из 10 и т.д. Соответственно завтра у нас возникает задача, в которой нужна часть из уже реализованной в этом классе функциональности. Реально для этой функциональности нужно всего 3 сущности, которые в новой задаче у нас есть, однако чтобы создать класс нам нужно еще семь сущностей, которых в новой задаче и близко нет. Соответственно получаем картину Репина приплыли,

Я попытаюсь конструктивно понять описанную Вами картину. Итак, имеется в виду, что код рассчитан на некоторую предметную область с её особенностями реализации. Например, если сотрудник пропущен в здание, то об этом должна пойти запись в лог, в центральную базу, в базу отдела и т.д., запущен какой-то пересчёт данных (от базы зарплаты до требований по вентиляции) и так далее. Так?
В таком случае вопросы,
1) зачем это всё прибито было изначально гвоздями в коде?
2) чем это отличается от случая, когда то же самое было бы написано явно в функции?
На первое — рекомендованным для ООП случаем является, когда общий класс какой-то функциональности не имеет никакого подобного фиксированного поведения, а оно создаётся или в производном классе, или уже при генерации объекта за счёт набивания его списков реакций нужными элементами. Второе же — случай значительно менее гибкого построения, которое вообще не регулируется. Ну и чем тут ООП хуже?

Да, я сейчас натеоретизировал на ровном месте, но Вы же ничего внятно не объясняете. Объясните, если я пошёл в неверном направлении.

U>ООП как обертка над чистыми функциями это прекрасный инструмент. ООП как функциональность прибитая к объектам это тот еще ужас.

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

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

U>Есть объект на десяток сущностей, при использовании ООП мы прибиваем к этому объекту гвоздями функциональность требующую и все 10 сущностей, и 3 сущности из 10, и 1 сущность из 10 и т.д. Соответственно завтра у нас возникает задача, в которой нужна часть из уже реализованной в этом классе функциональности. Реально для этой функциональности нужно всего 3 сущности, которые в новой задаче у нас есть, однако чтобы создать класс нам нужно еще семь сущностей, которых в новой задаче и близко нет. Соответственно получаем картину Репина приплыли, с дальнейшим дублированием кода и прочими прелестями.

И, конечно, в этом виновато ООП, а вовсе не программист, который написал говнокод, забив на SRP

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

T>И, конечно, в этом виновато ООП, а вовсе не программист, который написал говнокод, забив на SRP

В этом виновато именно ООП, т.к. декомпозиция тут ничем помочь не может. Т.к. первая функция требует, к примеру, 1 и 2 сущности, вторая функция 4, 5 и 7 сущности, третья функция — 1, 5, 6 и 7 сущности. И чем тут ООП может помочь? Как эти сущности в классы не объединяй все равно проблемы с повторным использованием функциональности этих классов в будущем вылезут.

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

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

V>>Дак если бы было понятно. Хотелось бы.

E>давайте вы приведете какие-то примеры кода, с проблемами. так будет понятнее.
E>а пока это просто размышления.

Проблема не в коде (имхо) а в куче предварительных рассуждений. И это касается не только ООП.

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

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

B>>Да практически все современные. Тут уместнее подойти с другой стороны и вспомнить старые.

T>Ну то есть конкретных примеров нет, правильно я понимаю?
Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?

A>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

Такое бывает при неправильном использовании классов и отсутствии архитектуры. Обычно используется высокоуровневая архитектура приложения, которая однозначно определяет как связываются между собой части программы. Для примера посмотрите как построен Qt Creator — он ольшой, в нем сотни классов, но при этом связи между ними прозрачны. Потому что архитектура, сигналы и слоты.

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

B>Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?

Я программирую не с 82 года. Тем не менее, мне доводилось работать с исходниками на Коболе, датированными 1974 годом. В них процедуры уже использовались. Несколько раньше я работал с фортрановским кодом, который начали писать примерно тогда же. Подпрограммы и функции тоже использовались.
Другое дело, что кто-то мне советовал не злоупотреблять вызовами подпрограмм, дескать, он занимает много времени, которое дорого. И да, я видел программы, где 5000 строк и больше находились в одной процедуре.

A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке.

Просто вы смотрели код, в котором отсутствует архитектура. Архитектура как раз и определяет в каком порядке и как взаимодействуют фрагменты программы. Посмотрите на досуге исходники Qt Creator.

A>И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше.

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

A>И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни.

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

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

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

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

B>>>Да практически все современные. Тут уместнее подойти с другой стороны и вспомнить старые.

T>>Ну то есть конкретных примеров нет, правильно я понимаю?
B>Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?
Это что за суперновые процедуры появились в 80е годы. Те, которые были в Алголе-60?

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

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

T>>И, конечно, в этом виновато ООП, а вовсе не программист, который написал говнокод, забив на SRP

U>В этом виновато именно ООП, т.к. декомпозиция тут ничем помочь не может. Т.к. первая функция требует, к примеру, 1 и 2 сущности, вторая функция 4, 5 и 7 сущности, третья функция — 1, 5, 6 и 7 сущности. И чем тут ООП может помочь? Как эти сущности в классы не объединяй все равно проблемы с повторным использованием функциональности этих классов в будущем вылезут.

Тут есть два варианта:
1) либо ты нарушил SRP и сам себе злобный буратино, ООП тут не причем. В данном случае класс представляет собой сборную солянку разных ответственностей и ты не можешь в результате повторно использовать реализацию одной из ответственностей, не получив в довесок кучу лишних зависимостей от остальных ответственностей.

2) либо ты не нарушил SRP и класс обладает ровно одной ответственностью, в таком случае каждая часть класса просто бессмысленна без всего остального и непонятно, что и зачем ты собрался повторно использовать. Например, у некоторой реализации интерфейса IEnumerable ты собрался повторно использовать метод MoveNext, а свойство Current тебе уже не нужно

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

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

B>>Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?

P>Я программирую не с 82 года. Тем не менее, мне доводилось работать с исходниками на Коболе, датированными 1974 годом. В них процедуры уже использовались. Несколько раньше я работал с фортрановским кодом, который начали писать примерно тогда же. Подпрограммы и функции тоже использовались.
P>Другое дело, что кто-то мне советовал не злоупотреблять вызовами подпрограмм, дескать, он занимает много времени, которое дорого. И да, я видел программы, где 5000 строк и больше находились в одной процедуре.
В первых языках высокого уровня вызов процедур был действительно нагружен. В ассемблерах этих проблем не было. Но была другая проблема с распределением памяти. Могу сказать что в первых машинах вообще не было команд вызова процедур. Потом появились, но адрес возврата сохраняли не в стеке, а, например, в следующей ячейке после команды вызова, и там же оставляли параметры, что приходилось учитывать при возврате из процедуры. Но здесь речь не об этих экзерциссах, а в том что ООП как-то значительно позже появилось. Вот, даже вспомнил.. Была еще промежуточная фишка "Структурное программирование"

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

B>>Я с 82-го года программирую. Так что просто поверь. ООП тогда не пахло. Процедуры были супер новой фишкой. Можно я не буду примеры приводить?
A>Это что за суперновые процедуры появились в 80е годы. Те, которые были в Алголе-60?
Алгол да.. Но я тут скорее о проблемах реализации этих процедур на ассемблерах и в архитектурах машин. Не во всех были стеки. Это сейчас кажется естественно. Хотя я так задумался. Мне не очень нравится разделение регистров по использованию. Хорошая машина была.. 16 регистров общего пользования. Не помню какая. Спецпроцессор был. Кстати, тогда еще миллион операций струячил.

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

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

WH>Чтобы каждая функция использовалась хотя бы 5 раз.
Я бы мог показать, но там Powershell и вообще адская императивщина =)

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

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

А на каком языке? А можно подробнее, что имеется ввиду?

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

RA>А на каком языке? А можно подробнее, что имеется ввиду?

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

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

T>Тут есть два варианта:
T>1) либо ты нарушил SRP и сам себе злобный буратино, ООП тут не причем. В данном случае класс представляет собой сборную солянку разных ответственностей и ты не можешь в результате повторно использовать реализацию одной из ответственностей, не получив в довесок кучу лишних зависимостей от остальных ответственностей.

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

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

U>В общем случае не работает этот принцип. Т.к. как замечательно декомпозицию не проводи в конечном итоге все равно возникает функциональность, которой, к примеру, нужно половина одного класса и половина другого. И никакой рефакторинг тут уже ничем помочь не может, т.к. при другая декомпозиция может решить эту проблему, но порождает проблемы с другой функциональностью.

Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.

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

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

Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.

U>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.

паттерн декоратор
почитайте GOF, у них есть отличный пример с текстовым редактором.

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

U>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.

Вынести лишние ответственности из textBox. Причем для всех клиентов textBox это может быть сделано прозрачно.

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

RA>>А на каком языке? А можно подробнее, что имеется ввиду?

Я просто хотел сказать, что не использую ООП и при этом у меня нет проблем. А языки я разные использую (так уж приходится). Основную работу пишу на С.

E>имеется в виду что человек начал копипастить и под каждую задачу писать новый велосипед. без реюза и всякого прочего

Я не понимаю как можно было такой вывод сделать. Моя вас не понимать

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

N>Более того, в случае организации в стиле ООП такую параметризацию делать легче, потому что можно организовать подобные специфики работы в виде объектов или объектных свойств и потом "прицепить" их к объектам основной работы. В этом плане очень показательна история развития Berkeley DB.
N>Версия 1: открытие базы делается 5-аргументной функцией dbopen(), 3 из которых — для open(). Дальше через полученный указатель зовутся методы — такое себе ООП с виртуальными методами, хоть и на голом C.
N>Версия 2: поняли, что этого недостаточно, переименовали функцию в db_open(), добавили аргументов.
N>Версия 3: поняли, что разных параметров типа размера страницы, методов изоляции, блокировок и т.д. будет больше, чем можно задать в одной функции, и сделали db_create(), после которой надо настроить всё, что надо (включая будущие добавки) и сделать после этого handle->open(). Теперь уже и создание/открытие базы стало делаться в объектном стиле, а не только последующая работа. (Напоминаю, что это C. Есть интерфейс и для C++, хотя он просто инкапсулирует работу с хэндлом.)

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

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

N>>Более того, в случае организации в стиле ООП такую параметризацию делать легче, потому что можно организовать подобные специфики работы в виде объектов или объектных свойств и потом "прицепить" их к объектам основной работы. В этом плане очень показательна история развития Berkeley DB.
N>>Версия 1: открытие базы делается 5-аргументной функцией dbopen(), 3 из которых — для open(). Дальше через полученный указатель зовутся методы — такое себе ООП с виртуальными методами, хоть и на голом C.
N>>Версия 2: поняли, что этого недостаточно, переименовали функцию в db_open(), добавили аргументов.
N>>Версия 3: поняли, что разных параметров типа размера страницы, методов изоляции, блокировок и т.д. будет больше, чем можно задать в одной функции, и сделали db_create(), после которой надо настроить всё, что надо (включая будущие добавки) и сделать после этого handle->open(). Теперь уже и создание/открытие базы стало делаться в объектном стиле, а не только последующая работа. (Напоминаю, что это C. Есть интерфейс и для C++, хотя он просто инкапсулирует работу с хэндлом.)

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

Если для hash, btree и recno хранилища handle->get() различается, это уже классический ООПшный полиморфизм: ты через один указатель единообразно делаешь запросы независимо от того, какая внутренняя реализация базы.

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

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

T>>Тут есть два варианта:
T>>1) либо ты нарушил SRP и сам себе злобный буратино, ООП тут не причем. В данном случае класс представляет собой сборную солянку разных ответственностей и ты не можешь в результате повторно использовать реализацию одной из ответственностей, не получив в довесок кучу лишних зависимостей от остальных ответственностей.

U>В общем случае не работает этот принцип. Т.к. как замечательно декомпозицию не проводи в конечном итоге все равно возникает функциональность, которой, к примеру, нужно половина одного класса и половина другого.

Если для чего-то нужна половина класса, то значит декомпозиция не так замечательна.

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

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

S>Сам посыл абсурден — куча ПО написано и работает как раз с использованием ООП, но вдруг с ним что-то не так.

S>А с чем извините все так? С ФП? И много на нем написано работающего годами ПО?
S>А может с логическим программированием все замечательно?

Ну не знаю... Я вот посмотрел на тот софт, с которым работаю, исходники которого могу глянуть. Получилось nginx, gcc, bash, vim, TeX. Почти везде преобладает православный Ц. Иногда проскальзывают скриптовые языки (Tcl, Python, Perl). Качество софта не вызывает нареканий.

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

E>Здравствуйте, мыщъх, Вы писали:

E>[поскипано]

E>тут нужно определится, что важнее для конкретной задачи.

Есть директория, в которой 100 000 файлов. Их надо все обработать и напечатать, сколько файлов было обработано. Это все прекрасно можно сделать с использованием счетчика и FindFirst/FindNext. А теперь предположим, что у нас есть прекрасный класс Directory, скрывающий доступ к FindFirst/FindNext. Какие методы должны быть в нем и как они должны быть реализованы, чтобы избежать накладных расходов (повторное сканирование директории, хранение списка файлов, ...)

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

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

U>>В общем случае не работает этот принцип. Т.к. как замечательно декомпозицию не проводи в конечном итоге все равно возникает функциональность, которой, к примеру, нужно половина одного класса и половина другого. И никакой рефакторинг тут уже ничем помочь не может, т.к. при другая декомпозиция может решить эту проблему, но порождает проблемы с другой функциональностью.

T>Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.

А я постоянно это наблюдаю

Можно даже правило такое замудрить, как декомпозицию не проводи она все равно хоть что-то пополам переедит.

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

E>имеется в виду что человек начал копипастить и под каждую задачу писать новый велосипед. без реюза и всякого прочего

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

... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>

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

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

S>>Профит в том, что повышается переиспользование кода и снижается необходимость вникания в код для использования.

A>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

Вообще повторное использование большого куска кода, не спроектированного для этого изначально, невозможно. Лет 30 назад апологеты ООП пытались утверждать обратное, но практика показала что хорошо реюзаются только маленькие куски кода. Поэтому и были придуманы паттерны проектирования, SOLID и прочее.

T>>Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.

V>А я постоянно это наблюдаю

V>Можно даже правило такое замудрить, как декомпозицию не проводи она все равно хоть что-то пополам переедит.

проблема в том, кто эту самую декомпозицию, с нарушением SRP, проводит

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

А почему ООП противопоставляется ФП?
По-моему ООП — следующий шаг развития языков программирования.
Если начать с простых определений, то:
набор инструкций можно объединить в подпрограммы/функции, для объединения множества переменных(данных) есть record.
Класс всего лишь объединяет функции и данные — и это основная задача ООП.
Это и добавляет сложность — для проектирования иерархии классов нужно оперировать бОльшим количеством понятий.

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

amg>Здравствуйте, Artifact, Вы писали:
amg>...

amg>А почему ООП противопоставляется ФП?
amg>По-моему ООП — следующий шаг развития языков программирования.

Кажется уже второй человек в теме считает что функциональное программирование = процедурное программирование. Это не так.

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

A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием.

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

A>С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

Вкратце: всё это происходит потому, что ООП с лёгкой руки рекламщиков 90-х заполучило ауру чего-то популярного и доступного пониманию любой обезьяны с гранатой. Ну, ещё надо сказать спасибо IBM за её дикую идею Smalltalk, как языка для конечного пользователя — типа, домохозяйки будут писать на ST, чтоб ей икалось! Хотя да, в известном смысле ООП приближено к образным структурам мышления обычного человека, вся проблема в том, что программированием занимаются необычные люди и это — статистически подтверждаемый факт. Отсюда регулярная грызня за самую правильную иерархию, за самый правильный "взгляд" и многая-многая другая фигня. Говоря другими словами — ОО-стиль вобрал в себя уйму сугубо интуиционистского мусора (взять те же паттерны, которые только, что не в одно место засовывают) и что характерно, "лучшие" ОО-структуры почему-то с точностью до деталей похожи на пребанальнейшую декомпозицию "данные vs. действия", но отнюдь не на "активные данные". Ну, так получилось, никто не виноват, что стиль мышления "обычного" человека вызывает уйму вопросов у "необычных" людей. Короче говоря — стиль мышления ~~идиота~~ обычного человека очень трудно рационализируется нормальным программистом. Но! ООП имплицитно апеллирует именно к ~~идиотскому~~ "обычному" стилю мышления и выражения своих мыслей. Это прекрасная игра, мастера которой которой достойны всяческого восхищения, но...

Здесь мы логически выходим на первопричину проблем ООП как культурного явления — изначальную апелляцию не столько к простоте, сколько к упрощенчеству. Отсюда — дебильный корневой Object, отсюда же — не к ночи будь повторно помянутые паттерны и многая другие беды, включая рекурсивные определения (объекты обмениваются сообщениями, которые сами представляют собой объекты, которые обмениваются сообщениями...) и десятки определений "сущности" ООП.

Собственно говоря, ООП — это в принципе вторичная штука. Родилось где-то в недрах исследований ИИ, было подхвачено Аланом Кеем (или наоборот — Кей первым сформулировал принципы ООП, а потом уже... Неважно.) и дальше понеслась.

Нет, я не спорю: ООП удачно и полезно когда оно базируется на строигх формальных выкладках. То есть сначала мы пишем бумаги, выделяем в терминах группы, группы обозначаем "классами" и т.п. Проблема в другом. Телега по имени Осмысление в ООП почему-то часто ставится впереди лошади по кличке Формальная Декомпозиция. Отсюда всё то, что я выше назвал интуиционистским мусором: что кому в башку наглючило, тот такую иерархию и закодировал. Исключение тут составляет А.Степанов, которому в горячечном бреду привиделся вполне натуральный CLOS, воплощённый в C++ (кстати, настоятельно рекомендую проштудировать спецификацию CLOS, сильно прочищает мозги по части "новомодных штучек", которые на поверку многим в бабушки годятся).

Имея в виду всё это (хотя я не высказал и сотой доли причинно-следственных связей), ты будешь продолжать удивляться, что среднестатистический ОО-код менее понятен, чем такой же среднестатистический процедурный, культура построения которого восходит к тем временам, когда профессия программиста была элитной?

ГВ>Вкратце: всё это происходит потому, что ООП с лёгкой руки рекламщиков 90-х заполучило ауру чего-то популярного и доступного пониманию любой обезьяны с гранатой.

Вернее так: самая безобидная обезьяна становится обезьяной с гранатой, когда она "поняла ООП". И это, граждане-товарищи, крайне серьёзно, потому что нельзя понять то, что не имеет точного определения.

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

A>>Я сильно начинаю сомневаться в полезности ООП.
I>Не ты один, вот к примеру цитата из интервью с автором STL.

[skip]

Степанов — умница. Это те нечастые люди, которые не стесняются называть г..но — г..ном.

ГВ>Ответ на твой вопрос был сформулирован аж в далёком 1993 году (словарь-справка). Прошу прощения за самоцитирование.

Подумал некоторое время, переaормулировал lkz rhfnrjcnb. Понимаешь ли, в чем проблема: мы — играли в "парадигмы" и прочую балабонь, а вы — слишком серьёзны.

ГВ>Подумал некоторое время, переaормулировал lkz rhfnrjcnb.

Подумал некоторое время, переформулировал для краткости.

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

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

Угу, поскольку если в это вникнуть, то можно попасть в психушку (если ты не силён духом и не исполнен цинизма). Плавали, знаем.

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

A>>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

EOH>Такое бывает при неправильном использовании классов и отсутствии архитектуры. Обычно используется высокоуровневая архитектура приложения, которая однозначно определяет как связываются между собой части программы. Для примера посмотрите как построен Qt Creator — он ольшой, в нем сотни классов, но при этом связи между ними прозрачны. Потому что архитектура, сигналы и слоты.

А ну-ка, выдерни из Qt какой-нибудь приличный класс, тот же QPainter и заюзай его без самой Qt. Что, скажешь, что у Qt архитектура отсутствует?

Здравствуйте, Son of Northern Darkness, Вы писали:

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

SON>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.

Ошибка. Расширить код, не переделывая его, возможно только при одном условии: что такие расширения были предусмотрены изначально. Иначе ты просто путаешь интуитивное восприятие "расширяемости" с фактическими действиями ради её воплощения.

SON>Вот за этим ООП и нужно.

Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.

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

U>>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.

E>паттерн декоратор

Т.е. надо позвонить в Микрософт и сказать, что у них проектировщики дебилы, не догадавшиеся заюзать в textbox'е паттерн декоратор? После чего решить эти задачи заново, т.к. никакой возможности выковырять эту функциональность из textbox'а ООП не позволяет.

E>почитайте GOF, у них есть отличный пример с текстовым редактором.

Паттерн декоратор тут не нужен и близко. Тут нужно было всю более менее универсальную функциональность textbox'а (в том числе мной перечисленную) вынести в чистые функции. А дальше уже можно было с легкостью использовать эту функциональность и в стандартном textbox'е и в любой другой задаче.

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

U>Т.е. надо позвонить в Микрософт и сказать, что у них проектировщики дебилы, не догадавшиеся заюзать в textbox'е паттерн декоратор? После чего решить эти задачи заново, т.к. никакой возможности выковырять эту функциональность из textbox'а ООП не позволяет.

Ну то есть все претензии к ООП заключаются в том, что ООП позволяет писать говнокод? Ты, наверное, знаешь некоторую парадигму или язык программирования, которые не позволяет писать говногод? Назови его!
Пока что тут прозвучал только один ответ, похожий на правду — Brain Driven Development

E>>почитайте GOF, у них есть отличный пример с текстовым редактором.

U>Паттерн декоратор тут не нужен и близко. Тут нужно было всю более менее универсальную функциональность textbox'а (в том числе мной перечисленную) вынести в чистые функции. А дальше уже можно было с легкостью использовать эту функциональность и в стандартном textbox'е и в любой другой задаче.

Если у функций будут параметры, значит будут и зависимости, а следовательно будут и все те проблемы, что у textBox, если не следовать BDD

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

T>Если у функций будут параметры, значит будут и зависимости, а следовательно будут и все те проблемы, что у textBox, если не следовать BDD

Для примера, будет у тебя функция, которая рисует рамку и которая в качестве своего аргумента принимает textBox. Удачи её использовать без textBox

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

B>у ООП единственный недостаток это жесткое наследование класс-объект. Чуть отличия у объекта так требуется новый класс, что не всегда разумно с предметной точки зрения.

Это недостаток конкретных реализаций, ноги которых растут из C++. А вообще будущее именно за гибридными языками, хорошо умеющими ООП, ФП и МП. Имеющими механизм строгой типизации, мощным выводом типов, но легко переключающиеся на динамику, там где это разумно.

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

Отдельно выскажусь о метапрограммировании. Как и с ООП/ФП его необходимость понимается только теми, кто смог хоть раз воспользоваться его приемами эффективно и безболезненно. И, точно так же, после понимания, начинается некоторая ломка в языках, которые ее не поддерживают. Так как задачи, которые лучше всего решаются с применением МП возникают регулярно. Для примера такой ломки, любой сишарпер, активно использующий linq, может попробовать покодить на C# 2.0.

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

U>>>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.
E>>паттерн декоратор
U>Т.е. надо позвонить в Микрософт и сказать, что у них проектировщики дебилы, не догадавшиеся заюзать в textbox'е паттерн декоратор? После чего решить эти задачи заново, т.к. никакой возможности выковырять эту функциональность из textbox'а ООП не позволяет.

Я не знаю, что такое winforms, но подозреваю, что в итоговой работе используются стандартные контролы Windows. В таком случае Вы, конечно, можете написать проектировщикам, что они дебилы, но думаю, что Вам следует подумать заранее, что это писалось в середине 80-х для машин с 512KB оперативной памяти (да-да, ещё даже не знаменитые 640) и строить декораторы тогда было мало уместно.

Но, с другой стороны, я бы тем проектировщикам пару ласковых отвесил. В ряде программ Microsoft (например, Excel) есть средства, которые по поведению ничуть не отличаются от тех же textbox'ов, но при этом не оформлены как окна на уровне GUI. Мне кажется, это просто нечестно.
В X Window другая традиция — аналогом контрола MS GUI является widget, а окно — более высокий уровень организации, и никто не запрещает использовать готовые виджеты. Вот там уже никто не мешает использовать любые вариации на тему декораторов.

E>>почитайте GOF, у них есть отличный пример с текстовым редактором.

U>Паттерн декоратор тут не нужен и близко. Тут нужно было всю более менее универсальную функциональность textbox'а (в том числе мной перечисленную) вынести в чистые функции. А дальше уже можно было с легкостью использовать эту функциональность и в стандартном textbox'е и в любой другой задаче.

Возможно. Но опять-таки это будет не MS GUI, а что-то специфически своё. А до тех пор, пока при создании, например, кнопки к ней подключается DefButtonProc из стандартной DLL'ки — у Вас не будет такой возможности.

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

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

B>>у ООП единственный недостаток это жесткое наследование класс-объект. Чуть отличия у объекта так требуется новый класс, что не всегда разумно с предметной точки зрения.

Z>Это недостаток конкретных реализаций, ноги которых растут из C++. А вообще будущее именно за гибридными языками, хорошо умеющими ООП, ФП и МП. Имеющими механизм строгой типизации, мощным выводом типов, но легко переключающиеся на динамику, там где это разумно.

Z>В этом направлении, с небольшими отклонениями движется достаточно много языков.

Z>Отдельно выскажусь о метапрограммировании. Как и с ООП/ФП его необходимость понимается только теми, кто смог хоть раз воспользоваться его приемами эффективно и безболезненно. И, точно так же, после понимания, начинается некоторая ломка в языках, которые ее не поддерживают. Так как задачи, которые лучше всего решаются с применением МП возникают регулярно. Для примера такой ломки, любой сишарпер, активно использующий linq, может попробовать покодить на C# 2.0.
Все это хорошо согласуется с моими предложениями в языке. Единственно, что бы я уточнил, что сам язык должен быть метаязыком. Здесь никакого противоречия. Обычный язык мы же используем для его же собственного описания. Потому не только OOП и ФП но и языки документирования, конструирования сайтов, языки определения грамматик должны иметь единый синтаксис и единые правила формирования понятий. Именно последнее и делает язык метаязыком.

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

Z>Отдельно выскажусь о метапрограммировании. Как и с ООП/ФП его необходимость понимается только теми, кто смог хоть раз воспользоваться его приемами эффективно и безболезненно.
Да. К предыдущему можно добавить что язык должен быть как компилируемым, так и интерпретирующим одновременно. И это тоже возможно

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

T>>>Не наблюдал такого никогда. Приведи конкретный пример, посмотрим.
V>>А я постоянно это наблюдаю

V>>Можно даже правило такое замудрить, как декомпозицию не проводи она все равно хоть что-то пополам переедит.

E>проблема в том, кто эту самую декомпозицию, с нарушением SRP, проводит

Не-а и нефиг гнать на людей. Проблема ровно в одной букве: S. SRP — неплохой принцип, но у него одна беда, которая сводит на нет всю его пользу — размытость. "Ответственность" за "работоспособность" — это тоже, знаешь ли, single responsibility.

ГВ>А ну-ка, выдерни из Qt какой-нибудь приличный класс, тот же QPainter и заюзай его без самой Qt. Что, скажешь, что у Qt архитектура отсутствует?

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

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

B>Все это хорошо согласуется с моими предложениями в языке. Единственно, что бы я уточнил, что сам язык должен быть метаязыком. Здесь никакого противоречия. Обычный язык мы же используем для его же собственного описания. Потому не только OOП и ФП но и языки документирования, конструирования сайтов, языки определения грамматик должны иметь единый синтаксис и единые правила формирования понятий. Именно последнее и делает язык метаязыком.

Ты сейчас описываешь проект Nemerle 2. Сам язык будет определен ровно теми же средствами, которые доступны прикладному программисту. В nemerle 1 есть некая прослойка, позволяющая расширять парсер/кодогенератор в отдельно взятых местах. Основные же парсер и генератор захардкожены в компиляторе. Во второй версии весь язык будет описан расширяемой пег грамматикой, тем же инструментом, что дается в распоряжение программисту.

Вот работающий прототип расширяемой грамматики: https://github.com/rampelstinskin/ParserGenerator/blob/master/Test/Main.n
В парсер выражений добавляются операции инкремента, декремента и унарного плюса. На сам парсер и на его расширение понадобилось 45 текстовых неплотных строк.

Насчет интерпретации идей пока не возникало. В принципе написать eval не сложно, сложно найти нужный баланс между скоростью байткод компиляции и выполнением.

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

Z>Ты сейчас описываешь проект Nemerle 2. Сам язык будет определен ровно теми же средствами, которые доступны прикладному программисту. В nemerle 1 есть некая прослойка, позволяющая расширять парсер/кодогенератор в отдельно взятых местах. Основные же парсер и генератор захардкожены в компиляторе. Во второй версии весь язык будет описан расширяемой пег грамматикой, тем же инструментом, что дается в распоряжение программисту.

Z>Вот работающий прототип расширяемой грамматики: https://github.com/rampelstinskin/ParserGenerator/blob/master/Test/Main.n
Z>В парсер выражений добавляются операции инкремента, декремента и унарного плюса. На сам парсер и на его расширение понадобилось 45 текстовых неплотных строк.

Z>Насчет интерпретации идей пока не возникало. В принципе написать eval не сложно, сложно найти нужный баланс между скоростью байткод компиляции и выполнением.
Нет. Я не про немерле. Я про свой язык. И вообще про свою систему. А интерпретацией все очень просто. Операции, операторы и функции с параметрами константами и статическими данными могут выполнятся на предварительном этапе трансляции (у меня это называется обработка стилей). Например, 5+7 вполне может выполнится до трансляции. Так же до трансляции могут выполняться данные определенные в самом стиле и переменные определенные специальным оператором Var(Динамические переменные определяются оператором Dim) для интерпретатора.
А для остальных языков глобальная недоработка это символьные (или текстовые типы. Они вводятся с потолка. У меня все построено на группах. Символы определяются как перечислимые концепты. То, что они перечислимые сомнений не вызывает. Группу перечислимых концептов (любых) можно объединить в перечислимые скобки, где сразу за открывающей скобкой через точку определяется имя перечислимого класса. По умолчанию (т.е. без указания имени перечислимого класса) это является текстовой группой, а скобки так и называются текстовые. Знаки (буквы) в таком случае являются именами перечислимых концептов. Вот такой ход конем. Кстати, еще один любопытный ход. Объединение в группу скобками отключает фунциональную часть концепта. Поэтому можно спокойно включать знаки форматирования. В текстовых скобках они не будут участвовать в форматировании редактируемого текста.
Ну, там долго рассказывать.. Это вкратце..

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

B>Нет. Я не про немерле. Я про свой язык. И вообще про свою систему.

есть где почитать?

Здравствуйте, Mystic, Вы писали:
M>Есть директория, в которой 100 000 файлов. Их надо все обработать и напечатать, сколько файлов было обработано. Это все прекрасно можно сделать с использованием счетчика и FindFirst/FindNext. А теперь предположим, что у нас есть прекрасный класс Directory, скрывающий доступ к FindFirst/FindNext. Какие методы должны быть в нем и как они должны быть реализованы, чтобы избежать накладных расходов (повторное сканирование директории, хранение списка файлов, ...)
Не понял. Вы серъёзно или это такой тонкий троллинг?
Если нет — то вот вам схема класса (компилироваться не будет, т.к. пишу по памяти в уме):

public class Directory
{
  public IEnumerablr<FileInfo> FindFiles(string pattern)
  {
     try
     { 
       var r = FindFirst(_path, pattern);
       while (r.Found)
       {
         yield return r.FileInfo;
         r = FindNext(r);
       }
     }
     finally
     {
       FindClose(r);
     }
  }
}

Как видите, он скрывает доступ к FindFirst/FindNext/FindClose, при этом нет никаких накладных расходов на повторное сканирование директории или хранение списка файлов.
При этом я могу совершенно спокойно писать, скажем, вот так:

...
foreach(var fi in d.FindFiles("*.cs")
  if (fi.LastModified >= yesterday)
    return fi.Name

Это значительно компактнее, чем вариант с прямым использованием FindXXX, и гарантированно закрывает хэндл поиска.

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

ГВ>>А ну-ка, выдерни из Qt какой-нибудь приличный класс, тот же QPainter и заюзай его без самой Qt. Что, скажешь, что у Qt архитектура отсутствует?

EOH>Не помню чтобы я утверждал про связь наличия архитектуры и полной изолированности компонентов.

Возможно, что я тебя неправильно понял.

EOH>А ну-ка, выдерни из здания туалет и попробуй его заюзать без канализации. Что, скажешь, у зданий архитектура отсутствут?

Так в том-то и дело, что наличие архитектурного планирования, — т.е. того самого высокоуровневого разделения обязанностей, напрямую препятствует повторному использованию компонентов вне определённых сценариев. Или без двойного отрицания: архитектура прямо предписывает определённые сценарии как для использования компонентов, так и для расширения системы.

Поэтому ты не можешь поставить туалет в чисто поле без канализации. И поэтому же должен знать взаимосвязи классов, чтобы правильно их использовать (например, QAbstractItem, QAbstractItemView и сопутствующие). Так что, ИМХО, вот это высказывание всё-таки довольно близко к истине:

К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

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

ГВ>Так в том-то и дело, что наличие архитектурного планирования, — т.е. того самого высокоуровневого разделения обязанностей, напрямую препятствует повторному использованию компонентов вне определённых сценариев. Или без двойного отрицания: архитектура прямо предписывает определённые сценарии как для использования компонентов, так и для расширения системы.

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

.

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

ГВ>Поэтому ты не можешь поставить туалет в чисто поле без канализации. И поэтому же должен знать взаимосвязи классов, чтобы правильно их использовать (например, QAbstractItem, QAbstractItemView и сопутствующие). Так что, ИМХО, вот это высказывание всё-таки довольно близко к истине:
ГВ>

К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

ООП вроде как != повторному использованию кода?

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

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

B>>Нет. Я не про немерле. Я про свой язык. И вообще про свою систему.

Z>есть где почитать?
Здесь концепция http://files.rsdn.ru/91645/%d0%9a%d0%be%d0%bd%d1%86%d0%b5%d0%bf%d1%82%d0%bd%d0%b0%d1%8f%20%d0%bf%d0%b0%d1%80%d0%b0%d0%b4%d0%b8%d0%b3%d0%bc%d0%b0.doc
Здесь о группировании http://files.rsdn.ru/91645/%d0%93%d1%80%d1%83%d0%bf%d0%bf%d0%b8%d1%80%d0%be%d0%b2%d0%b0%d0%bd%d0%b8%d0%b5%20%d0%be%d0%b1%d1%8a%d0%b5%d0%ba%d1%82%d0%be%d0%b2.doc
Это так вкратце что б не грузить деталями. Концепцию можно назвать субъектно-ориентированой. Но думаю концептная не так громко звучит.
Группирование это центральные классы в реализации и они же определяют применение скобок и потому являются основой синтаксиса языка. Cинтаксис в основе простой и универсальный: Концепт = "имя класса концепта" "имя концепта" "Реализация". Дальше только применение групп сразу после имени класса концепта и т.д. Реализация тоже группа. Обычно это операторы или так называемое тело оператора или класса.. вообщем так.. Для затравки достаточно. Будет интересно дальше расскажу..

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

S>Как видите, он скрывает доступ к FindFirst/FindNext/FindClose, при этом нет никаких накладных расходов на повторное сканирование директории или хранение списка файлов.
S>При этом я могу совершенно спокойно писать, скажем, вот так:
S>

S>...
S>foreach(var fi in d.FindFiles("*.cs")
S>  if (fi.LastModified >= yesterday)
S>    return fi.Name
S>

S>Это значительно компактнее, чем вариант с прямым использованием FindXXX, и гарантированно закрывает хэндл поиска.

Количество файлов придется подсчитывать самому.

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

M>Количество файлов придется подсчитывать самому.
И? А что, FindFirst/FindNext уже предлагают какой-то волшебный способ подсчитать его, не заканчивая итерирование?

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

EOH>А ну-ка, выдерни из здания туалет и попробуй его заюзать без канализации. Что, скажешь, у зданий архитектура отсутствут?
Ну, например, унитаз можно выдернуть из здания и поставить в другое здание. С другой архитектурой и системой канализации.

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

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

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

U>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.

Винформсовский textBox — всего лишь обертка над винапишным. Соответственно все эти задачи решаются кодом написаным на С без всякого ООП.
С другой стороны в совершенно ООП-ном Qt даже выковыривать ничего не придется, всю эту функциональность можно использовать и так.

Ну и вывод из всего этого: притянутыми за уши примерами можно доказать все что угодно.

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

ГВ>Здравствуйте, Son of Northern Darkness, Вы писали:

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

SON>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.

ГВ>Ошибка. Расширить код, не переделывая его, возможно только при одном условии: что такие расширения были предусмотрены изначально. Иначе ты просто путаешь интуитивное восприятие "расширяемости" с фактическими действиями ради её воплощения.

Красиво сказано! Но какая между ними разница?
Расширяемость = наращивание функционала с минимальными усилиями, и по возможности не трогая существующий код.

SON>>Вот за этим ООП и нужно.

ГВ>Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.

Я этого не утверждал. Но пока что ООП — это наиболее эффективный инструмент снижения структурной сложности.

Здравствуйте, Son of Northern Darkness, Вы писали:

SON>Здравствуйте, Геннадий Васильев, Вы писали:

SON>>>Вот за этим ООП и нужно.

ГВ>>Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.

SON>Я этого не утверждал. Но пока что ООП — это наиболее эффективный инструмент снижения структурной сложности.

А вот это утверждение нуждается как минимум в аргументах.

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

S>А вот это утверждение нуждается как минимум в аргументах.

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

ЗOH>>А ну-ка, выдерни из здания туалет и попробуй его заюзать без канализации. Что, скажешь, у зданий архитектура отсутствут?
Т>Ну, например, унитаз можно выдернуть из здания и поставить в другое здание. С другой архитектурой и системой канализации.

Туалет и унитаз — штуки хорошие, но немного разные.

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

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

M>>Количество файлов придется подсчитывать самому.
S>И? А что, FindFirst/FindNext уже предлагают какой-то волшебный способ подсчитать его, не заканчивая итерирование?

Но мы вроде проектируем волшебный библиотечный класс, который должен поддерживать (1) получение списка файлов в директории и (2) количество файлов в директории. Вот и получается, что или (а) класс работает неэффективно (б) класс перегружен логикой.

Здравствуйте, Son of Northern Darkness, Вы писали:

A>>>>И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?
SON>>>Это не правда. Хороший код, это код в который можно расширить, не переделывая уже сделанную работу или переделывая минимально.

ГВ>>Ошибка. Расширить код, не переделывая его, возможно только при одном условии: что такие расширения были предусмотрены изначально. Иначе ты просто путаешь интуитивное восприятие "расширяемости" с фактическими действиями ради её воплощения.

SON>Красиво сказано! Но какая между ними разница?

Огромная — как между "кажется" и "есть на самом деле".

SON>Расширяемость = наращивание функционала с минимальными усилиями, и по возможности не трогая существующий код.

Если такая возможность реализовалась, то из этого прямо следует, что некоторые способы "расширения" были предусмотрены изначально. Не правда ли?

SON>>>Вот за этим ООП и нужно.
ГВ>>Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.

SON>Я этого не утверждал. Но пока что ООП — это наиболее эффективный инструмент снижения структурной сложности.

Наиболее эффективный среди каких инструментов (назови хотя бы три)? По каким критериям оценивается эффективность?

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

ГВ>>Так в том-то и дело, что наличие архитектурного планирования, — т.е. того самого высокоуровневого разделения обязанностей, напрямую препятствует повторному использованию компонентов вне определённых сценариев. Или без двойного отрицания: архитектура прямо предписывает определённые сценарии как для использования компонентов, так и для расширения системы.

EOH>На мой предвзятый взгляд они ортогональны. Не помню, чтобы основным достоинством ООП считали возможность повторного использования кода.

Скажем так, в контексте этого обсуждения reusability — злостный онтопик. Считать ли это каким-то особенным достоинством ООП — не знаю, здесь много мнений имеется. Например, в лучшие для ООП времена бытовала такая мифологема, что скоро программы будут собирать "из кубиков". Так что, равны между собой ООП и reusability, или нет — это зависит от того, какую идеологему принять за точку отсчёта.

EOH>ООП был создан и используется с единственной целью — борьбы с complexity problem, а точнее с композицией больших сущностей из фрагментов и взаимодействие с этими большими сущностями как с единым целом. То, что кто-то бегает и кричит про повторное использование кода... Люди вообще любят бегать и кричать

.

Как раз топикстартер говорит о прямо противоположном: о том, что элементы ОО-программ на самом деле трудны в повторном использовании.

EOH>А повторное использование кода как я его понимаю — это библиотеки и фреймворки. Тоесть низкий уровень и архитектура с посадочными местами. Предметную логику писали, пишут и писать будут.

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

ГВ>>Поэтому ты не можешь поставить туалет в чисто поле без канализации. И поэтому же должен знать взаимосвязи классов, чтобы правильно их использовать (например, QAbstractItem, QAbstractItemView и сопутствующие). Так что, ИМХО, вот это высказывание всё-таки довольно близко к истине:
ГВ>>

К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

EOH>ООП вроде как != повторному использованию кода?

С этим, вроде бы, никто не спорит.

ГВ>Если такая возможность реализовалась, то из этого прямо следует, что некоторые способы "расширения" были предусмотрены изначально. Не правда ли?

Применение проверенных практик часто решает этот вопрос автоматически. Это могут быть паттерны GoF, личные изобретения или просто здравый смысл.

SON>>>>Вот за этим ООП и нужно.
ГВ>>>Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.

SON>>Я этого не утверждал. Но пока что ООП — это наиболее эффективный инструмент снижения структурной сложности.

ГВ>Наиболее эффективный среди каких инструментов (назови хотя бы три)?

Смотри мой ответ в соседнем сообщении: ПП, ФП, ООП.

ГВ>По каким критериям оценивается эффективность?я бы три)? По каким критериям оценивается эффективность?

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

Здравствуйте, Son of Northern Darkness, Вы писали:

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

S>>А вот это утверждение нуждается как минимум в аргументах.

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

SON>Элементы ФП, которые стали сейчас появляться в мэйнстримовых языках, только дополняют ООП приятными фичами. Основа остается той же.
Из того что элементы ФП дополняют ООП не следует что ООП наиболее эффективный инструмент снижения структурной сложности. Наоборот, это повод задуматься, а не является ли ФП более эффективным инструментом?

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

SON>По поводу процедурного программирования... Ну можно, да, только зачем?
Я хотел взглянуть на объективные причины делать такое утвреждение

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

SON>>По-моему, это очевидно.
S>Очевидно употребляется вместо "взгляните, доказательство этого утверждения тривиально и лежит на поверхности". И само по себе весу утверждению не добавляет и заменой доказательству не является.

Мне очевидно, что положение дел на рынке ПО таково а не другое по вполне объективной причине. Цене разработки.

SON>>Элементы ФП, которые стали сейчас появляться в мэйнстримовых языках, только дополняют ООП приятными фичами. Основа остается той же.
S>Из того что элементы ФП дополняют ООП не следует что ООП наиболее эффективный инструмент снижения структурной сложности. Наоборот, это повод задуматься, а не является ли ФП более эффективным инструментом?

Судя по судьбе F#, пока что нет.

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

"При определенных обстоятельствах."

SON>>По поводу процедурного программирования... Ну можно, да, только зачем?
S>Я хотел взглянуть на объективные причины делать такое утвреждение

Инкапсуляция на уровне модулей, отсутствие динамического полиморфизма, данные и методы работы над ними никак не связаны.

Здравствуйте, Son of Northern Darkness, Вы писали:

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

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

SON>Мне очевидно, что положение дел на рынке ПО таково а не другое по вполне объективной причине. Цене разработки.
Позвольте, мы говорили об эффективности инструмента в отношении снижения структурной сложности программ, а не о положении дел на рынке и цене разработки. Что до рынка, то у меня есть уверенность в том что процедурный подход преобладает.

S>>Из того что элементы ФП дополняют ООП не следует что ООП наиболее эффективный инструмент снижения структурной сложности. Наоборот, это повод задуматься, а не является ли ФП более эффективным инструментом?

SON>Судя по судьбе F#, пока что нет.
Судьба F# не является объективным инструментом оценки эффективности в отношении снижения структурной сложности. Что касается субъективных ощущений — так по мне с F# куда проще бороться со сложностью, чем с C#.

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

SON>"При определенных обстоятельствах."

SON>>>По поводу процедурного программирования... Ну можно, да, только зачем?
S>>Я хотел взглянуть на объективные причины делать такое утвреждение

SON>Инкапсуляция на уровне модулей
Присутствует, и что с ней?

SON>отсутствие динамического полиморфизма
Как так? Функции с одной сигнатурой заменяемы, в том числе динамически.

SON>данные и методы работы над ними никак не связаны.
Связаны тем что методы работают с данными. Какая еще связь нужна? Положить метод в данную? Вы это называете снижением структурной сложности?

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

M>Но мы вроде проектируем волшебный библиотечный класс, который должен поддерживать (1) получение списка файлов в директории и (2) количество файлов в директории.
Я не понял, откуда взялась такая задача. Нижележащий API не предоставляет таких сервисов. Откуда взялись ожидания от ООП как-то улучшить ситуацию по сравнению с этим?
Чтоб два раза не вставать: также не стоит ожидать от "библиотечного класса" для расчёта FFT производительности лучше, чем O(NlogN).

Здравствуйте, Son of Northern Darkness, Вы писали:

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

S>>А вот это утверждение нуждается как минимум в аргументах.

SON>По-моему, это очевидно. Элементы ФП, которые стали сейчас появляться в мэйнстримовых языках, только дополняют ООП приятными фичами. Основа остается той же.

Это потому, что туда добавляют "элементы". Haskell такой не потому, что там лямбдочку добавили, а потому, что всё в совокупности.

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

ГВ>Ну, ещё надо сказать спасибо IBM за её дикую идею Smalltalk, как языка для конечного пользователя — типа, домохозяйки будут писать на ST, чтоб ей икалось!

Откуда дровишки? У IBM её среда стоила бешеных бабок. Домохозяйка скорее б удавилась... Еще я понимаю такое про REXX написать, и то...

ГВ>Здесь мы логически выходим на первопричину проблем ООП как культурного явления — изначальную апелляцию не столько к простоте, сколько к упрощенчеству. Отсюда — дебильный корневой Object,

нет

ГВ>отсюда же — не к ночи будь повторно помянутые паттерны

нет

ГВ>и многая другие беды, включая рекурсивные определения (объекты обмениваются сообщениями, которые сами представляют собой объекты, которые обмениваются сообщениями...) и десятки определений "сущности" ООП.

"рекурсивные определения" это, как бы, не следствие, а причина.

ГВ> То есть сначала мы пишем бумаги, выделяем в терминах группы, группы обозначаем "классами" и т.п.

Это антипатерн.

ГВ>Имея в виду всё это (хотя я не высказал и сотой доли причинно-следственных связей), ты будешь продолжать удивляться, что среднестатистический ОО-код менее понятен, чем такой же среднестатистический процедурный, культура построения которого восходит к тем временам, когда профессия программиста была элитной?

Во времена, когда профессия программиста была элитной не было процедурного кода.

EOH>>ООП был создан и используется с единственной целью — борьбы с complexity problem, а точнее с композицией больших сущностей из фрагментов и взаимодействие с этими большими сущностями как с единым целом. То, что кто-то бегает и кричит про повторное использование кода... Люди вообще любят бегать и кричать

.
ГВ>Как раз топикстартер говорит о прямо противоположном: о том, что элементы ОО-программ на самом деле трудны в повторном использовании.

Увы, я довольно слабый телепат и в оригинальном сообщении не нашел ничего про повторное использование кода

. На всякий случай, вот оно:

EOH>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

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

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

M>Но мы вроде проектируем волшебный библиотечный класс, который должен поддерживать (1) получение списка файлов в директории и (2) количество файлов в директории. Вот и получается, что или (а) класс работает неэффективно (б) класс перегружен логикой.
На всякий случай напомню, что обсуждался фрагмент про

если АПИ не возвращает кол-во файлов в директории и нам нужно их перечислять явно, то на чистом си мы напишем FindFist/FindNext плюс, увеличивающийся на 1 каждый проход цикла. и за один раз получим и содержимое и кол-во элементов. а по правилам ООП мы вынуждены перечитывать директорию два раза

Выход — в том, что нет никаких таких "правил ООП", по которым мы вынуждены перечитывать директорию два раза.
Там далее по тексту идут всякие приседания, связанные с тем, что кто-то очень хочет иметь функцию "длина" там, где длины нету.
Если её нету — значит не надо её делать. Неспроста в интерфейсе IEnumerable нет свойства Count.

E>>паттерн декоратор

U>Т.е. надо позвонить в Микрософт и сказать, что у них проектировщики дебилы, не догадавшиеся заюзать в textbox'е паттерн декоратор? После чего решить эти задачи заново, т.к. никакой возможности выковырять эту функциональность из textbox'а ООП не позволяет.

ты очень плохо знаешь как написаны вин форм контролы

E>>почитайте GOF, у них есть отличный пример с текстовым редактором.

U>Паттерн декоратор тут не нужен и близко. Тут нужно было всю более менее универсальную функциональность textbox'а (в том числе мной перечисленную) вынести в чистые функции. А дальше уже можно было с легкостью использовать эту функциональность и в стандартном textbox'е и в любой другой задаче.

реюз кода совершенно не исключает ООП. так же как функциональщина не является панацеей.

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

Вдолбить истину не получится, до этого либо дойти мозгом либо помереть в неведении. Можно лишь помочь человеку дойти до истины, повести его, другого пути нет.

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

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

A>>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

_>Получается, потому что есть модное слово ООП, и под веянием моды пихают классы куда ни попадя

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

_>Вдолбить истину не получится, до этого либо дойти мозгом либо помереть в неведении. Можно лишь помочь человеку дойти до истины, повести его, другого пути нет.

А можно ссылку на "кошерное ООП", в котором есть истина, а не шлак?

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

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

OK. Предложи какой-нибудь численный критерий оценки структурной сложности, который мы могли бы применить к существующим системам. Взять open source проект в процедурном стиле, например, и сравнить его с проектом в ОО стиле. Без общепринятного критерия мы вынужденны оперировать общими соображениями и косвенными данными. По поводу того, какой подход преобладает на рынке, можно посмотреть количество вакансий на разные языки.

S>>>Из того что элементы ФП дополняют ООП не следует что ООП наиболее эффективный инструмент снижения структурной сложности. Наоборот, это повод задуматься, а не является ли ФП более эффективным инструментом?

SON>>Судя по судьбе F#, пока что нет.
S>Судьба F# не является объективным инструментом оценки эффективности в отношении снижения структурной сложности. Что касается субъективных ощущений — так по мне с F# куда проще бороться со сложностью, чем с C#.

Тоже самое. Предложи объективный критерий оценки, буду очень рад.

SON>>Инкапсуляция на уровне модулей
S>Присутствует, и что с ней?

SON>>отсутствие динамического полиморфизма
S>Как так? Функции с одной сигнатурой заменяемы, в том числе динамически.

Это будет эмуляция ООП костыльными методами. Безусловно, можно сделать на Си свою vtbl, эмулировать наследование но зачем? Для этого есть языки, которые поддерживают эти парадигмы на уровне синтаксиса.

SON>>данные и методы работы над ними никак не связаны.
S>Связаны тем что методы работают с данными. Какая еще связь нужна? Положить метод в данную? Вы это называете снижением структурной сложности?

Да. А что не так?

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

G>А можно ссылку на "кошерное ООП", в котором есть истина, а не шлак?

Смысл был в том, что городить какое-то ООП не надо. Хватает функции — пиши фукнцию, хватает 5 функций — пиши только их, незачем огород городить. Если со временем проект разростется, то имея голову на плечах законы ООП сами выведутся. Только нужны ли будут они?

Здравствуйте, Son of Northern Darkness, Вы писали:

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

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

SON>OK. Предложи какой-нибудь численный критерий оценки структурной сложности, который мы могли бы применить к существующим системам. Взять open source проект в процедурном стиле, например, и сравнить его с проектом в ОО стиле. Без общепринятного критерия мы вынужденны оперировать общими соображениями и косвенными данными.
Э, не. Ты сделал утверждение, тебе и вымпел. Я же не пытаюсь его опровергать. Только лишь интересуюсь соображениями, которые привели к такому утверждению. Судя по этому ответу, метрики измерения сложности у тебя под рукой нет. А утверждение о наиболее эффективном инструменте есть. Вот это и интересно.

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

S>>Судьба F# не является объективным инструментом оценки эффективности в отношении снижения структурной сложности. Что касается субъективных ощущений — так по мне с F# куда проще бороться со сложностью, чем с C#.

SON>Тоже самое. Предложи объективный критерий оценки, буду очень рад.
Объективный — нет, воздержусь. Косвенные — могу предложить. Например, объем исходников или LOC. Если сравнивать F# и C#, то на F# объем в среднем меньше.

SON>>>Инкапсуляция на уровне модулей
S>>Присутствует, и что с ней?

SON>>>отсутствие динамического полиморфизма
S>>Как так? Функции с одной сигнатурой заменяемы, в том числе динамически.

SON>Это будет эмуляция ООП костыльными методами. Безусловно, можно сделать на Си свою vtbl, эмулировать наследование но зачем? Для этого есть языки, которые поддерживают эти парадигмы на уровне синтаксиса.

SON>>>данные и методы работы над ними никак не связаны.
S>>Связаны тем что методы работают с данными. Какая еще связь нужна? Положить метод в данную? Вы это называете снижением структурной сложности?

SON>Да. А что не так?
Тогда надо определиться, что именно ты подразумеваешь под структурной сложностью, потом уже определяться с тем, как именно расположение метода в классе (или вне него) влияет на эту сложность.

Википедия говорит что structural complexity это о классах вычислительной сложности. На рсдн тоже упоминается, но там скорее об отношении полезности кода к добавляемой им сложности без явного определения. В обоих источниках влияние расположения метода на сложность не очевидна.

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

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

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

A>>>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

_>>Получается, потому что есть модное слово ООП, и под веянием моды пихают классы куда ни попадя

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

_>>Вдолбить истину не получится, до этого либо дойти мозгом либо помереть в неведении. Можно лишь помочь человеку дойти до истины, повести его, другого пути нет.

G>А можно ссылку на "кошерное ООП", в котором есть истина, а не шлак?

Кошерное ООП здесь

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

S>Э, не. Ты сделал утверждение, тебе и вымпел. Я же не пытаюсь его опровергать. Только лишь интересуюсь соображениями, которые привели к такому утверждению. Судя по этому ответу, метрики измерения сложности у тебя под рукой нет. А утверждение о наиболее эффективном инструменте есть. Вот это и интересно.

Да ничего интересного на самом деле, обычная субъективщина. Последнее время приходится работать с огромным объемом легаси кода 15-20летней давности и меньшим объемом современного вплоть до 4го фреймворка. Эволюция парадигм как на ладони.

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

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

S>>>Судьба F# не является объективным инструментом оценки эффективности в отношении снижения структурной сложности. Что касается субъективных ощущений — так по мне с F# куда проще бороться со сложностью, чем с C#.

SON>>Тоже самое. Предложи объективный критерий оценки, буду очень рад.
S>Объективный — нет, воздержусь. Косвенные — могу предложить. Например, объем исходников или LOC. Если сравнивать F# и C#, то на F# объем в среднем меньше.

Ну тут есть два соображения. 1) смотря как ты его используешь, можно писать в ОО стиле используя элементы ФП, как большинство, и делает, скорее всего. 2) критерий не очень хороший. Если я обфусцирую существующую программу на Си, уберу проблемы, идентификаторы заменю на двухбуквенные, программа станет короче, но не проще.
Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем.

SON>>>>Инкапсуляция на уровне модулей
S>>>Присутствует, и что с ней?

SON>>>>отсутствие динамического полиморфизма
S>>>Как так? Функции с одной сигнатурой заменяемы, в том числе динамически.

SON>>Это будет эмуляция ООП костыльными методами. Безусловно, можно сделать на Си свою vtbl, эмулировать наследование но зачем? Для этого есть языки, которые поддерживают эти парадигмы на уровне синтаксиса.

SON>>>>данные и методы работы над ними никак не связаны.
S>>>Связаны тем что методы работают с данными. Какая еще связь нужна? Положить метод в данную? Вы это называете снижением структурной сложности?

SON>>Да. А что не так?
S>Тогда надо определиться, что именно ты подразумеваешь под структурной сложностью, потом уже определяться с тем, как именно расположение метода в классе (или вне него) влияет на эту сложность.

Возможно, увидел у Макконелла. К сожалению, книги нет под рукой, чтобы проверить точное определение. Если упрощенно, то это количество сущностей в программе и их взаимосвязей. Но, например, глобальная переменная, которая меняется неявно в 10 местах, сильно увеличивает сложность. Так что тут имеет место быть еще и качественная составляющая.

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

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

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

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

A>>>>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе делает и в каком порядке. И это даже при отсутствии злоупотребления наследованием. С кодом написанным, что называется в лоб, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности ООП. Складывается впечатление, что ООП это такой хорошо замаскированный современный GOTO. И ещё я не понимаю, почему как только люди беруться за проект, то тут же как грибы после дождя начинают появляться классы. На самую простую функциональность количество порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

_>>>Получается, потому что есть модное слово ООП, и под веянием моды пихают классы куда ни попадя

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

_>>>Вдолбить истину не получится, до этого либо дойти мозгом либо помереть в неведении. Можно лишь помочь человеку дойти до истины, повести его, другого пути нет.

G>>А можно ссылку на "кошерное ООП", в котором есть истина, а не шлак?

T>Кошерное ООП здесь

Слишком мутные эти принципы. Критериев проверки нет. Формальности нет, кроме LSP, да и его каждый понимает по-своему.

Кроме того они не дают представления о процессе ОО-программирования.

Здравствуйте, Son of Northern Darkness, Вы писали:

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

S>>Э, не. Ты сделал утверждение, тебе и вымпел. Я же не пытаюсь его опровергать. Только лишь интересуюсь соображениями, которые привели к такому утверждению. Судя по этому ответу, метрики измерения сложности у тебя под рукой нет. А утверждение о наиболее эффективном инструменте есть. Вот это и интересно.

SON>Да ничего интересного на самом деле, обычная субъективщина. Последнее время приходится работать с огромным объемом легаси кода 15-20летней давности и меньшим объемом современного вплоть до 4го фреймворка. Эволюция парадигм как на ладони.
А, тогда более-менее понятно. Т.е. выводы основаны на сравнении кода 15-20 летней давности (на чем, если не секрет?) и относительно свежего. ИМХО, в таком случае мог повлиять не только парадигм-шифт, сколько само по себе развитие библиотек/фреймворка. Уже одна только библиотека хороших контейнеров может значительно упростить код, написанный без нее. В дотнете библиотека контейнеров скорее объектно ориентирована, но не без признаков функциональого подхода. А могла бы иметь более функциональный уклон. Так вот, мысль в том, что само использование библиотеки не означает изменение парадигмы, и можно продолжать писать в процедурном подходе используя ОО или ФП библиотеки. Уже только от этого код может оказаться проще, чем оригинальный 20-летний.
Это не говоря уже о том, что даже в рамках одной парадигмы и одного набора библиотек код одного человека может существенно отличаться от кода другого (или того же, но спустя несколько лет) в аспекте сложности.

S>>Не думаю что кол-во вакансий будет как-то определять преобладание подхода. Ведь не запрещено писать ООП на C или процедурно (или функционально) на C#.

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

В свете этого даже мой пример с F# не показателен, т.к. F# несколько более высокоуровневый, чем C#. В идеале было бы взять некоторое множество задач и сравнить решения выполненные на одном языке (допустим C#) в разных подходах (ОО, ПП, ФП)... Это было бы интересно. Только боюсь, что код пера одного автора не будет отличаться разительным образом.

SON>>>Тоже самое. Предложи объективный критерий оценки, буду очень рад.
S>>Объективный — нет, воздержусь. Косвенные — могу предложить. Например, объем исходников или LOC. Если сравнивать F# и C#, то на F# объем в среднем меньше.

SON>Ну тут есть два соображения. 1) смотря как ты его используешь, можно писать в ОО стиле используя элементы ФП, как большинство, и делает, скорее всего. 2) критерий не очень хороший. Если я обфусцирую существующую программу на Си, уберу проблемы, идентификаторы заменю на двухбуквенные, программа станет короче, но не проще.
Согласен
SON>Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем.
Нужно выбрать метрики, которые имеют смысл для разных подходов. Так, если мы возьмем метрику, учитывающую взаимосвязь классов, то куда ее прикладывать в ПП? А если будем учитывать лишь связи функций и структур данных, то может оказаться что ОО не дает существенного упрощения согласно таким метрикам.

S>>Тогда надо определиться, что именно ты подразумеваешь под структурной сложностью, потом уже определяться с тем, как именно расположение метода в классе (или вне него) влияет на эту сложность.

SON>Возможно, увидел у Макконелла. К сожалению, книги нет под рукой, чтобы проверить точное определение. Если упрощенно, то это количество сущностей в программе и их взаимосвязей. Но, например, глобальная переменная, которая меняется неявно в 10 местах, сильно увеличивает сложность. Так что тут имеет место быть еще и качественная составляющая.
Полистал Макконелла — навскидку не нашел.
Глобальная переменная — отличный пример сложности. Только сложно сказать, для какого из подходов она более характерна? Во времена ПП их не боялись и использовали достаточно широко. И только. Т.е. если в ПП не будем использовать глобальные переменные слишком широко, то все еще останемся в рамках ПП.
(я работал в институте, где 64-килобайтный файл объявлений глобальных переменных был вариантом нормы, т.е. никого особо не удивлял. Но это не проблема ПП вцелом, это проблема конкретных разработчиков)

Что нам предлагает ОО в отношении глобальных переменных? Положить ее в класс? Вобщем-то ничего особенно и не изменилось по сравнению с ПП. Скрыть доступ к глобальной переменной и инкапсулировать работу с ней? Мы могли это сделать и в ПП тоже.
Самое мудрое решение в отношении глобальной переменной предлагает ФП — избавиться от нее. Точно так же мы можем не использовать ее в ОО/ПП.
Т.е. как только в отношении глобальной переменной мы принимаем что она увеличивает сложность больше чем добавление параметров к методам и избавляемся от нее вне конкретного подхода, так сразу рассмотренные подходы становятся ближе друг к другу в этом отношении.
В конце концов, после того как мы примем несколько правильных решений, может оказаться что разница в подходах сведется к синтаксической. Вопрос лишь в том, на сколько далеко мы пойдем. Наверняка ведь захочется остаться в рамках теплого и привычного подхода.

Здравствуйте, Son of Northern Darkness, Вы писали:

ГВ>>Если такая возможность реализовалась, то из этого прямо следует, что некоторые способы "расширения" были предусмотрены изначально. Не правда ли?

SON>Применение проверенных практик часто решает этот вопрос автоматически. Это могут быть паттерны GoF, личные изобретения или просто здравый смысл.

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

SON>>>>>Вот за этим ООП и нужно.
ГВ>>>>Это распространённый миф. Расширяемую программу можно написать совсем не в одной только в ОО-парадигме.
SON>>>Я этого не утверждал. Но пока что ООП — это наиболее эффективный инструмент снижения структурной сложности.
ГВ>>Наиболее эффективный среди каких инструментов (назови хотя бы три)?

SON>Смотри мой ответ в соседнем сообщении: ПП, ФП, ООП.

Я почитал соседнюю дискуссию, чтобы не повторяться. В общем — крайне спорное утверждение.

ГВ>>По каким критериям оценивается эффективность?я бы три)? По каким критериям оценивается эффективность?

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

Скорость разработки и лёгкость освоения, ИМХО, относятся к стилю программирования (а всё, что ты назвал — это именно стили) как... Короче, слабовато относятся. Ну а структурную сложность программ нужно измерять на эквивалентных программах, иначе это чистые домыслы.

Хотя тот же самый Буч утверждал, что хороший структурный проект (т.е. — оформленный в стиле структурного программирования) ничуть не хуже объектно-ориентированного, тем более — плохого объектно-ориентированного проекта. Проблема, собственно, сводилась к тому, что среди структурных программ чаще встречались ходячие ужасы, чем среди ОО-программ. Во всяком случае, так было во времена расцвета ОО-апологии. Ну, сейчас, как видим, положение выправляется.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

ГВ>>Ну, ещё надо сказать спасибо IBM за её дикую идею Smalltalk, как языка для конечного пользователя — типа, домохозяйки будут писать на ST, чтоб ей икалось!
ANS>Откуда дровишки? У IBM её среда стоила бешеных бабок. Домохозяйка скорее б удавилась... Еще я понимаю такое про REXX написать, и то...

Из какой-то книжки второй половины 80-х.

ГВ>>Здесь мы логически выходим на первопричину проблем ООП как культурного явления — изначальную апелляцию не столько к простоте, сколько к упрощенчеству. Отсюда — дебильный корневой Object,
ANS>нет
ГВ>>отсюда же — не к ночи будь повторно помянутые паттерны
ANS>нет

Хе-хе. Я могу и ошибаться.

ГВ>>и многая другие беды, включая рекурсивные определения (объекты обмениваются сообщениями, которые сами представляют собой объекты, которые обмениваются сообщениями...) и десятки определений "сущности" ООП.
ANS>"рекурсивные определения" это, как бы, не следствие, а причина.

Причина чего?

ГВ>> То есть сначала мы пишем бумаги, выделяем в терминах группы, группы обозначаем "классами" и т.п.
ANS>Это антипатерн.

ИМХО, твой пример — это пример на свободную функцию, а не на метод: Доить(Доярка, Корова). Ну или как вариант — это может быть мультиметод. Не в объектном стиле, зато просто и понятно.

ГВ>>Имея в виду всё это (хотя я не высказал и сотой доли причинно-следственных связей), ты будешь продолжать удивляться, что среднестатистический ОО-код менее понятен, чем такой же среднестатистический процедурный, культура построения которого восходит к тем временам, когда профессия программиста была элитной?

ANS>Во времена, когда профессия программиста была элитной не было процедурного кода.

Возможно.

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

T>>Кошерное ООП здесь

G>Слишком мутные эти принципы. Критериев проверки нет. Формальности нет, кроме LSP, да и его каждый понимает по-своему.

G>Кроме того они не дают представления о процессе ОО-программирования.

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

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

ГВ>Не совсем так. Проверенные времени практики (я понимаю, что ты имеешь в виду — разбиение на модули, выделение абстракций и т.п.) часто изначально подразумевают возможность расширения получающегося кода. Иными словами — изначально-таки расширение предусматривалось как явное требование, просто со временем это требование перестали явно озвучивать. Собственно, структурное программирование — это как раз и есть такая правильная практика, созданная отчасти ради поддержки дальнейшего расширения и сопровождения текста программы.

Проверенные временем практики кроме возможности расширения, дают:

1) дешевую модификацию кода (достаточно внести изменение в одно место, а не в сотню)
2) качественную декомпозицию (упрощает разработку)
3) простота изучения кода (чтобы понять, как работает одна фича не надо изучать исходники всей системы)
4) простота локализации ошибок (место положение кода, в котором ошибка, становится понятно из описания ошибки)

и другие полезные вещи, о которых я забыл написать

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

U>>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.

КБ>С другой стороны в совершенно ООП-ном Qt даже выковыривать ничего не придется, всю эту функциональность можно использовать и так.

Членами каких классов перечисленная функциональность является в Qt?

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

ГВ>в известном смысле ООП приближено к образным структурам мышления обычного человека

В известном смысле, ООП приближено к представлениям подкатегории необычных людей об образных структурах мышления обычного человека. Вот так будет вернее.

... << RSDN@Home 1.2.0 alpha 4 rev. 1476>>

Здравствуйте, Son of Northern Darkness, Вы писали:

SON>Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем.

Цикломатическая сложность

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

U>Здравствуйте, Константин Б., Вы писали:

U>>>Например, у нас есть винформсовский textBox. В том числе при своей работе он решает следующие задачи: 1) вывод рамки, 2) получение символа на который пришелся клик мышки, 3) получение координат изображения и текста при их совместном выводе. Все это типовые задачи, вероятность повторного использования которых в других контролах весьма высока. Ежели вы не видите недостатков у ООП, то продемонстрируйте как можно выковырять эту функциональность из textBox'а и использовать при написании своих контролов.

КБ>>С другой стороны в совершенно ООП-ном Qt даже выковыривать ничего не придется, всю эту функциональность можно использовать и так.

U>Членами каких классов перечисленная функциональность является в Qt?

QStyle, QTextLayout

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

ГВ>>>и многая другие беды, включая рекурсивные определения (объекты обмениваются сообщениями, которые сами представляют собой объекты, которые обмениваются сообщениями...) и десятки определений "сущности" ООП.
ANS>>"рекурсивные определения" это, как бы, не следствие, а причина.

ГВ>Причина чего?

Ну то есть, не "сначала домохозяйки потом рекурсивные определения и пр. беды", а наоборот "сначала рекурсивные определения потом домохозяйки и пр. беды".

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

G>Слишком мутные эти принципы. Критериев проверки нет. Формальности нет, кроме LSP, да и его каждый понимает по-своему.

Просто, хочу прояснить для себя. Вот тут ты говорил:

Так вот anemic по формальным свойствам не менее ООП, а учитывая SOLID — даже более ООП, чем рич

Т.е. SOLID выступал критерием степени ООП-нусти

а теперь SOLID стал мутным. Это проапгрейдилось твоё мнение или в том посте ты просто так сказал?

ЗЫ. Никогда не понимал, что в SOLID людям нравится, и зачем Д.Боба противопоставляют Фаулеру? С практической т.зрения смысл есть только в LSP, а всё остальное — явная белиберда.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

G>>Слишком мутные эти принципы. Критериев проверки нет. Формальности нет, кроме LSP, да и его каждый понимает по-своему.

ANS>Просто, хочу прояснить для себя. Вот тут ты говорил:
ANS>

Так вот anemic по формальным свойствам не менее ООП, а учитывая SOLID — даже более ООП, чем рич

ANS>Т.е. SOLID выступал критерием степени ООП-нусти

а теперь SOLID стал мутным. Это проапгрейдилось твоё мнение или в том посте ты просто так сказал?

А ты контекст того обсуждения прочитай. Там выше оппоненты описывали свое понимание solid.

ANS>ЗЫ. Никогда не понимал, что в SOLID людям нравится, и зачем Д.Боба противопоставляют Фаулеру? С практической т.зрения смысл есть только в LSP, а всё остальное — явная белиберда.
Рациональное зерно в SOLID есть, но очень глубоко зарыто. Проблема в том что Мартин пытался популяризировать принципы, которые сам довольно плохо понимал. У фаулера вышло лучше, так как он больше аппелирует к объектности, моделям итп. Хотя в его книге много явных передергиваний и книга уже давно устарела.

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

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

ГВ>>Не совсем так. Проверенные времени практики (я понимаю, что ты имеешь в виду — разбиение на модули, выделение абстракций и т.п.) часто изначально подразумевают возможность расширения получающегося кода. Иными словами — изначально-таки расширение предусматривалось как явное требование, просто со временем это требование перестали явно озвучивать. Собственно, структурное программирование — это как раз и есть такая правильная практика, созданная отчасти ради поддержки дальнейшего расширения и сопровождения текста программы.

T>Проверенные временем практики кроме возможности расширения, дают:

T>1) дешевую модификацию кода (достаточно внести изменение в одно место, а не в сотню)
T>2) качественную декомпозицию (упрощает разработку)
T>3) простота изучения кода (чтобы понять, как работает одна фича не надо изучать исходники всей системы)
T>4) простота локализации ошибок (место положение кода, в котором ошибка, становится понятно из описания ошибки)

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

В деталях можно оспорить, но по сути верно: проверенные временем практики как раз вобрали в себя эти самые требования.

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

ГВ>Не совсем так. Проверенные времени практики (я понимаю, что ты имеешь в виду — разбиение на модули, выделение абстракций и т.п.) часто изначально подразумевают возможность расширения получающегося кода. Иными словами — изначально-таки расширение предусматривалось как явное требование, просто со временем это требование перестали явно озвучивать. Собственно, структурное программирование — это как раз и есть такая правильная практика, созданная отчасти ради поддержки дальнейшего расширения и сопровождения текста программы.

Да, ты меня правильно понял. Я это и имел в виду. Мой поинт в ответе на первое сообщение был в том, что хорошая программа это не есть минимальная программа (если это не есть отдельное требование, например, при разработке под какой-нибудь микроконтроллер).

ГВ>Скорость разработки и лёгкость освоения, ИМХО, относятся к стилю программирования (а всё, что ты назвал — это именно стили) как... Короче, слабовато относятся. Ну а структурную сложность программ нужно измерять на эквивалентных программах, иначе это чистые домыслы.

Что же тогда делать?

Я подхожу с практической точки зрения — сложности/дороговизны создания/поддержки программы. Может я не прав... В соседней подветке предложили использовать цикломатическую сложность для оценки, пока не вчитывался. Если есть существующие тулзы для вычисления, я мог бы погонять ее на кусках проекта написанных в разных стилях.

ГВ>Хотя тот же самый Буч утверждал, что хороший структурный проект (т.е. — оформленный в стиле структурного программирования) ничуть не хуже объектно-ориентированного, тем более — плохого объектно-ориентированного проекта. Проблема, собственно, сводилась к тому, что среди структурных программ чаще встречались ходячие ужасы, чем среди ОО-программ. Во всяком случае, так было во времена расцвета ОО-апологии. Ну, сейчас, как видим, положение выправляется.

Да я, в общем-то, не фанат ООП, если подкинут денег, то готов писать на чем угодно вплоть до ассмеблера VAX

Так же готов согласиться, что хороший структурный проект лучше плохого ОО. Но скорее всего, я бы предполчел работать с хорошим ОО, чем с хорошим структурным. Ничего кроме субъективного мнения предложить по этому поводу не могу. Мне всегда казалось, что класс проще в понимании чем разрозненные функции и данные, но что это, и правда, проще я доказать не возьмусь.

У меня есть друг — энтузиаст низкоуровнего программирования, работает сейчас в одном небезизвестном производителе антивирусов. Ну так вот, он умудряется писать на ассемблере программы в несколько десятков тысяч строк, и они нормально стабильно работают (в основном это, правда, всякие конверторы, распаковщики и т.д..) Просто аккурантно работает с памятью, выделяет процедуры, где нужно, соблюдает конвенции на передачи параметров. Тот же стркуктурный подход, но я бы не стал всем советовать так делать.

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

FR>Здравствуйте, Son of Northern Darkness, Вы писали:

SON>>Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем.

FR>Цикломатическая сложность

Спасибо! Посмотрю.

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

S>А, тогда более-менее понятно. Т.е. выводы основаны на сравнении кода 15-20 летней давности (на чем, если не секрет?) и относительно свежего. ИМХО, в таком случае мог повлиять не только парадигм-шифт, сколько само по себе развитие библиотек/фреймворка. Уже одна только библиотека хороших контейнеров может значительно упростить код, написанный без нее. В дотнете библиотека контейнеров скорее объектно ориентирована, но не без признаков функциональого подхода. А могла бы иметь более функциональный уклон. Так вот, мысль в том, что само использование библиотеки не означает изменение парадигмы, и можно продолжать писать в процедурном подходе используя ОО или ФП библиотеки. Уже только от этого код может оказаться проще, чем оригинальный 20-летний.
S>Это не говоря уже о том, что даже в рамках одной парадигмы и одного набора библиотек код одного человека может существенно отличаться от кода другого (или того же, но спустя несколько лет) в аспекте сложности.

Часть кода на C, часть C++, часть C# и C++/CLI. По поводу использования ОО контейнеров в процедурном коде... Да, ты прав. Но еще больший выигрышь будет от использования ОО контейнеров в ОО коде

Голословное заявление, конечно, но ничего кроме личного опыта предлодить не могу. Кстати, доводилось видеть и обратные примеры, то есть когда человек с помощью ООП простреливал себе ногу (голову?). Это когда 700 кб кода запихано в 10 классов, половина из которых просто интерфейсы для callback-ов, то есть по сути в 5 классов. Дежурная шутка была: "ну по крайней мере его уволят последним"

S>В свете этого даже мой пример с F# не показателен, т.к. F# несколько более высокоуровневый, чем C#. В идеале было бы взять некоторое множество задач и сравнить решения выполненные на одном языке (допустим C#) в разных подходах (ОО, ПП, ФП)... Это было бы интересно. Только боюсь, что код пера одного автора не будет отличаться разительным образом.

Да, было бы интересно. Но дело даже не в этом, это довольно серьезная инвестиция по времени.

SON>>>>Тоже самое. Предложи объективный критерий оценки, буду очень рад.
S>>>Объективный — нет, воздержусь. Косвенные — могу предложить. Например, объем исходников или LOC. Если сравнивать F# и C#, то на F# объем в среднем меньше.

SON>>Ну тут есть два соображения. 1) смотря как ты его используешь, можно писать в ОО стиле используя элементы ФП, как большинство, и делает, скорее всего. 2) критерий не очень хороший. Если я обфусцирую существующую программу на Си, уберу проблемы, идентификаторы заменю на двухбуквенные, программа станет короче, но не проще.
S>Согласен
SON>>Интуиция подсказывает, что искать надо в сторону построения графа объектов программы (функции, переменные, классы...) и пытаться считать метрики на нем.
S>Нужно выбрать метрики, которые имеют смысл для разных подходов. Так, если мы возьмем метрику, учитывающую взаимосвязь классов, то куда ее прикладывать в ПП? А если будем учитывать лишь связи функций и структур данных, то может оказаться что ОО не дает существенного упрощения согласно таким метрикам.

Тут предложили цикломатическую сложность. Будет время, посмотрю, есть ли что-то бесплатное, что умеет считать метрики на основе нее. Правда, обещать не могу, есть чем заняться на работе.

S>Глобальная переменная — отличный пример сложности. Только сложно сказать, для какого из подходов она более характерна? Во времена ПП их не боялись и использовали достаточно широко. И только. Т.е. если в ПП не будем использовать глобальные переменные слишком широко, то все еще останемся в рамках ПП.
S>(я работал в институте, где 64-килобайтный файл объявлений глобальных переменных был вариантом нормы, т.е. никого особо не удивлял. Но это не проблема ПП вцелом, это проблема конкретных разработчиков)

S>Что нам предлагает ОО в отношении глобальных переменных? Положить ее в класс? Вобщем-то ничего особенно и не изменилось по сравнению с ПП. Скрыть доступ к глобальной переменной и инкапсулировать работу с ней? Мы могли это сделать и в ПП тоже.
S>Самое мудрое решение в отношении глобальной переменной предлагает ФП — избавиться от нее. Точно так же мы можем не использовать ее в ОО/ПП.

Ну ООП предлагает синглтон как стандартный паттерн для реализации глобальной переменной. С моей точки зрения, переменная обернутая в синглтон — это уже неплохо. Мы можем поставить брейкпоинт в геттер/сеттер, логировать изменения, можем управлять временем жизни. Вообще ты прав, конечно. Есть хорошие практики и плохие. Делай правильно, не делай неправильно и выбор инструмента отходит на второй план.

S>В конце концов, после того как мы примем несколько правильных решений, может оказаться что разница в подходах сведется к синтаксической. Вопрос лишь в том, на сколько далеко мы пойдем. Наверняка ведь захочется остаться в рамках теплого и привычного подхода.

Уровень синтаксиса, это как раз еще один уровень сложности. Чем более он прозрачен, тем проще реализовать нужный функционал определенным образом. Я имею в виду, если, например, C++ 11 явным образом поддерживает лямбда выражения, отпадает необходимость городить кошмарные шаблоны, подключать сторонню библиотеку... Если язык поддерживает инкапсуляцию на уровне синтаксиса, на уровне описания интерфейса, то не надо городить огород со статическими глобальными переменными и разбиением на единицы компиляции. Можно много чего еще придумать, но, надеюсь, мысль понятна.

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

Здравствуйте, Son of Northern Darkness, Вы писали:

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

SON>Часть кода на C, часть C++, часть C# и C++/CLI.
Да, злая солянка.

SON>По поводу использования ОО контейнеров в процедурном коде... Да, ты прав. Но еще больший выигрышь будет от использования ОО контейнеров в ОО коде

Голословное заявление, конечно, но ничего кроме личного опыта предлодить не могу.
Голословно соглашусь.

SON>Кстати, доводилось видеть и обратные примеры, то есть когда человек с помощью ООП простреливал себе ногу (голову?). Это когда 700 кб кода запихано в 10 классов, половина из которых просто интерфейсы для callback-ов, то есть по сути в 5 классов. Дежурная шутка была: "ну по крайней мере его уволят последним"

Прострелить себе что-нибудь можно чем угодно

S>>В свете этого даже мой пример с F# не показателен, т.к. F# несколько более высокоуровневый, чем C#. В идеале было бы взять некоторое множество задач и сравнить решения выполненные на одном языке (допустим C#) в разных подходах (ОО, ПП, ФП)... Это было бы интересно. Только боюсь, что код пера одного автора не будет отличаться разительным образом.

SON>Да, было бы интересно. Но дело даже не в этом, это довольно серьезная инвестиция по времени.
Конечно, не на столько интересно что бы делать один проект 3 раза, даже очень маленький.

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

SON>Тут предложили цикломатическую сложность. Будет время, посмотрю, есть ли что-то бесплатное, что умеет считать метрики на основе нее. Правда, обещать не могу, есть чем заняться на работе.
http://www.campwoodsw.com/sourcemonitor.html
Вроде бы считает на основе цикломатической сложности, возможно с модификациями. Как-то сразу не подумал, что цикломатическую сложность называют и структурной тоже.

SON>Ну ООП предлагает синглтон как стандартный паттерн для реализации глобальной переменной. С моей точки зрения, переменная обернутая в синглтон — это уже неплохо. Мы можем поставить брейкпоинт в геттер/сеттер, логировать изменения, можем управлять временем жизни.
Не согласен. Синглтон для переменной в плане удобства вряд ли лучше геттера. А сеттер синглтону вообще противопоказан, во всяком случае видимый извне. Как и глобальная переменная, синглтон так же создает неявные зависимости, которые выстреливают в ногу в неожиданный момент.
SON>Вообще ты прав, конечно. Есть хорошие практики и плохие. Делай правильно, не делай неправильно и выбор инструмента отходит на второй план.
Конечно, правило универсальное. Жаль, что узнаешь о том, как неправильно, когда нога отстрелена

SON>Уровень синтаксиса, это как раз еще один уровень сложности. Чем более он прозрачен, тем проще реализовать нужный функционал определенным образом. Я имею в виду, если, например, C++ 11 явным образом поддерживает лямбда выражения, отпадает необходимость городить кошмарные шаблоны, подключать сторонню библиотеку... Если язык поддерживает инкапсуляцию на уровне синтаксиса, на уровне описания интерфейса, то не надо городить огород со статическими глобальными переменными и разбиением на единицы компиляции. Можно много чего еще придумать, но, надеюсь, мысль понятна.
Да, понятна. Но есть обратная сторона. Пока посторонний человек не разберется с синтаксисом того, что позволяет язык, вряд ли он сможет понять, что именно написано и как это поддерживать.
Т.е. как только мы воспользовались синтаксической возможностью и сделали код прозрачнее, сложность понимания кода не исчезла, просто она ушла в документацию этой синтаксической возможности. Хотя, цикломатическая сложность уменьшится. Т.е. код стал проще, а что бы его прочитать стало нужно знать больше. И часто непропорционально больше, несоразмерно. Но на больших количествах употреблений можно и сэкономить.

SON>ООП сделано с учетом опыта ПП и при разрабке концепции применение "хороших" практик старались упростить, так чтобы разработчик, идя по пути наименьшего сопротивления, создавал простой и надежный код.
Наверное так и было. Только, имхо, сложность программ растет быстрее, чем обилие хороших пратктик позволяет контроллировать сложность. Я не про конкретную программу или проект, вообще в целом.

Практически сложно представить код (например совеременного браузера) в ПП виде. Благодаря ООП, код современного браузера будет значительно проще, чем он мог бы быть в ПП, но сказать что ООП код браузера прост и надежен безотносительно сравнения с ПП —

Соответственно, упрощать его далее средствами ООП если и возможно, то вряд ли существенно. А вот ФП (с метапрограммированием), а то и DSL, могут и потягаться с задачей.

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

U>>Членами каких классов перечисленная функциональность является в Qt?
КБ>QStyle, QTextLayout

Насколько я понял, QStyle это базовый класс имеющий специфического наследника для textBox. При этом QStyle отвечает не только за вывод рамочки, а вообще за всю отрисовку контрола. Соответственно состояние QStyleTextBox будет намного более жирным, нежели требуется для отрисовки одной только рамочки. Из-за этого при решение своей задачи я точно также могу столкнуться с ситуацией, когда состояние необходимое для отрисовки рамочки у меня есть, а состояния необходимого для создания QStyleTextBox — нет. Т.е. за счет лишнего абстрактного слоя ситуация в Qt несколько лучше, чем в Winforms, но принципиально проблемы те же самые. Если же подобную функциональность вынести в чистые функции, то такой проблемы не будет в принципе.

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

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

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

G>Рациональное зерно в SOLID есть, но очень глубоко зарыто. Проблема в том что Мартин пытался популяризировать принципы, которые сам довольно плохо понимал. У фаулера вышло лучше, так как он больше аппелирует к объектности, моделям итп. Хотя в его книге много явных передергиваний и книга уже давно устарела.

А что не устарело, если не секрет?

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

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

G>>Рациональное зерно в SOLID есть, но очень глубоко зарыто. Проблема в том что Мартин пытался популяризировать принципы, которые сам довольно плохо понимал. У фаулера вышло лучше, так как он больше аппелирует к объектности, моделям итп. Хотя в его книге много явных передергиваний и книга уже давно устарела.

AM>А что не устарело, если не секрет?

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

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

U>Здравствуйте, Константин Б., Вы писали:

U>>>Членами каких классов перечисленная функциональность является в Qt?
КБ>>QStyle, QTextLayout

U>Насколько я понял, QStyle это базовый класс имеющий специфического наследника для textBox.

Неправильно понял. Специфическим наследником будет например QWindowsVistaStyle чтобы рисовать контролы как в Висте.

U>При этом QStyle отвечает не только за вывод рамочки, а вообще за всю отрисовку контрола. Соответственно состояние QStyleTextBox будет намного более жирным, нежели требуется для отрисовки одной только рамочки. Из-за этого при решение своей задачи я точно также могу столкнуться с ситуацией, когда состояние необходимое для отрисовки рамочки у меня есть, а состояния необходимого для создания QStyleTextBox — нет.

Нету в QStyle никакого состояния. Вообще.

U>Т.е. за счет лишнего абстрактного слоя ситуация в Qt несколько лучше, чем в Winforms, но принципиально проблемы те же самые. Если же подобную функциональность вынести в чистые функции, то такой проблемы не будет в принципе.

Тут и так вполне чистые функции. И ООП при этом. Здорово правда?

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

КБ>Здравствуйте, Undying, Вы писали:

U>>Т.е. за счет лишнего абстрактного слоя ситуация в Qt несколько лучше, чем в Winforms, но принципиально проблемы те же самые. Если же подобную функциональность вынести в чистые функции, то такой проблемы не будет в принципе.

КБ>Тут и так вполне чистые функции. И ООП при этом. Здорово правда?
Не помню уже, что именно Undying подразумевает под чистыми функциями, но в QStyle функции не чистые. По крайней мере те, что пачкают QPainter.

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

КБ>Нету в QStyle никакого состояния. Вообще.

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

КБ>Тут и так вполне чистые функции. И ООП при этом. Здорово правда?

Так с чем ты тогда спорил? Речь шла о том, что совмещение ООП и чистых функций дает много лучший код, нежели жесткое привязывание функциональности к состоянию. Qt оказалась примером этого.

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

U>Здравствуйте, Константин Б., Вы писали:

КБ>>Нету в QStyle никакого состояния. Вообще.

U>Если QStyle не имеет состояния, то все функции экземпляра QStyle являются чистыми функциями. Соответственно благодаря широкому использованию чистых функций возможности QStyle по повторному использованию коду много богаче чем в Winforms.

Тут дело не в чистых функциях, а в том что в Qt вынесли наружу функцию рисования рамки, а в винде — не вынесли.
Очевидно что в недрах USER32 такая функция есть, вся из себя чистая и не-ООПная, а повторно использовать ее — не получится.

КБ>>Тут и так вполне чистые функции. И ООП при этом. Здорово правда?
U>Так с чем ты тогда спорил? Речь шла о том, что совмещение ООП и чистых функций дает много лучший код, нежели жесткое привязывание функциональности к состоянию. Qt оказалась примером этого.

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

http://www.rsdn.ru/forum/philosophy/4582222.1.aspx
http://www.rsdn.ru/forum/philosophy/4582636.1.aspx

И в качестве примера привел пример не-ООП кода рисующего textBox в винде %)

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

S>Здравствуйте, Константин Б., Вы писали:

КБ>>Здравствуйте, Undying, Вы писали:

U>>>Т.е. за счет лишнего абстрактного слоя ситуация в Qt несколько лучше, чем в Winforms, но принципиально проблемы те же самые. Если же подобную функциональность вынести в чистые функции, то такой проблемы не будет в принципе.

КБ>>Тут и так вполне чистые функции. И ООП при этом. Здорово правда?
S>Не помню уже, что именно Undying подразумевает под чистыми функциями, но в QStyle функции не чистые. По крайней мере те, что пачкают QPainter.

Думаю мы подразумеваем функции результат/действие которых зависит только от переданных параметров. Или что-то вроде того.

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

КБ>Здравствуйте, samius, Вы писали:

КБ>>>Тут и так вполне чистые функции. И ООП при этом. Здорово правда?
S>>Не помню уже, что именно Undying подразумевает под чистыми функциями, но в QStyle функции не чистые. По крайней мере те, что пачкают QPainter.

КБ>Думаю мы подразумеваем функции результат/действие которых зависит только от переданных параметров. Или что-то вроде того.
То есть что-то свое, отличное от http://en.wikipedia.org/wiki/Pure_function. Ок, не буду вмешиваться.

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

КБ>Тут дело не в чистых функциях, а в том что в Qt вынесли наружу функцию рисования рамки, а в винде — не вынесли.
КБ>Очевидно что в недрах USER32 такая функция есть, вся из себя чистая и не-ООПная, а повторно использовать ее — не получится.

Если и не получится использовать, то исключительно из-за того, что эту функцию не сделали публичной. А так вполне можно. Другое дело, что из шарпа напрямую работать с WinApi не удобно, но это уже совершенно другой вопрос.

Собственно из-за того, что код WinApi это в основном чистые функции, он и через двадцать лет живей всех живых (хоть и нынче используется в основном через обертки). Фрамеворкам, в которых функциональность прибита к состоянию объектов, такая продолжительность жизни и не снилась.

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

Об автоматичности речи точно не было. Чистые функции это необходимое, но недостаточное условие реюзабельного кода.

> Что-то нетак с ООП

> 173 ответа

Ох. А я даже перестал читать и, тем более, отвечать в подобные темы, если в них нет конкретных примеров. Бессмысленный разговор ни о чём.

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

U>Собственно из-за того, что код WinApi это в основном чистые функции, он и через двадцать лет живей всех живых (хоть и нынче используется в основном через обертки). Фрамеворкам, в которых функциональность прибита к состоянию объектов, такая продолжительность жизни и не снилась.

"Ох уж эти мне сказки, ох уж эти мне сказочники..."
Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования.
Ты ничего не сделаешь с существующим окном, не указав его хэндл.
Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв.
Всё это — работа с объектами.
И WinAPI живо не от того, что там якобы нет объектов, а в том, что тебе дали возможность расширять функциональность во всех ключевых объектах. Хочешь нарисовать по-своему? Хочешь переопределить часть реакций? Пожалуйста, всё к твоим услугам (по крайней мере пока речь идёт про окна и тому подобное). Ну ладно, почти всё. Некоторые вещи менять таки не можешь.

Ну да, в WinAPI есть некоторые функции, которые по крайней мере внешне не связаны с объектами. GlobalAlloc, например (хотя там объектом является процесс), или там EnumCodePages. И как ты думаешь, если ты будешь использовать только их, далеко ли уйдёшь?

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

U>Об автоматичности речи точно не было. Чистые функции это необходимое, но недостаточное условие реюзабельного кода.

Чушь зелёная. См. выше.

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

U>>Собственно из-за того, что код WinApi это в основном чистые функции, он и через двадцать лет живей всех живых (хоть и нынче используется в основном через обертки). Фрамеворкам, в которых функциональность прибита к состоянию объектов, такая продолжительность жизни и не снилась.

N>Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования.
N>Ты ничего не сделаешь с существующим окном, не указав его хэндл.
N>Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв.
N>Всё это — работа с объектами.

Ты это к чему все? Где в перечисленном ты увидел выделенное?

N>И WinAPI живо не от того, что там якобы нет объектов, а в том, что тебе дали возможность расширять функциональность во всех ключевых объектах. Хочешь нарисовать по-своему? Хочешь переопределить часть реакций? Пожалуйста, всё к твоим услугам (по крайней мере пока речь идёт про окна и тому подобное). Ну ладно, почти всё. Некоторые вещи менять таки не можешь.

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

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

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

U>>>Собственно из-за того, что код WinApi это в основном чистые функции, он и через двадцать лет живей всех живых (хоть и нынче используется в основном через обертки). Фрамеворкам, в которых функциональность прибита к состоянию объектов, такая продолжительность жизни и не снилась.

N>>Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования.
N>>Ты ничего не сделаешь с существующим окном, не указав его хэндл.
N>>Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв.
N>>Всё это — работа с объектами.

U>Ты это к чему все? Где в перечисленном ты увидел выделенное?

И что не соответствует выделенному? Если нет объекта или объект не в том состоянии, у тебя не получится нормальной работы с ним.

N>>И WinAPI живо не от того, что там якобы нет объектов, а в том, что тебе дали возможность расширять функциональность во всех ключевых объектах. Хочешь нарисовать по-своему? Хочешь переопределить часть реакций? Пожалуйста, всё к твоим услугам (по крайней мере пока речь идёт про окна и тому подобное). Ну ладно, почти всё. Некоторые вещи менять таки не можешь.

U>И получилось это благодаря тому что функциональность представлена в виде чистых функций, а не в виде методов жирных классов.

Нет в описанном "чистых функций", не обманывай себя.

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

N>>>Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования.
N>>>Ты ничего не сделаешь с существующим окном, не указав его хэндл.
N>>>Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв.
N>>>Всё это — работа с объектами.

N>И что не соответствует выделенному? Если нет объекта или объект не в том состоянии, у тебя не получится нормальной работы с ним.

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

N>Нет в описанном "чистых функций", не обманывай себя.

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

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

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

N>>>>Ты ничего не нарисуешь в окне или на экране, не создав draw context и не передавая его хэндл в каждую функцию для рисования.
N>>>>Ты ничего не сделаешь с существующим окном, не указав его хэндл.
N>>>>Ты ничего не прочитаешь из файла, не запишешь, предварительно его не открыв.
N>>>>Всё это — работа с объектами.

N>>И что не соответствует выделенному? Если нет объекта или объект не в том состоянии, у тебя не получится нормальной работы с ним.

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

Да ну? Почему, например, DirectX не требует создания контекста окна для рисования?
И что мне мешает провести линию на экране не создавая всяких объектов? Почему-то в всяких graph.bgi это можно было делать без проблем, а тут какая-то ерунда началась — контекст создавай, ещё какую-то ерунду настраивай прежде чем сможешь хотя бы один пиксел засветить... нет чтобы всё отнять и поделить...

U> А вот, к примеру, для вывода рамки textBox'а не нужны ни текст, ни выделенный символ, ни даже хэндл самого textBox'а, но если вывод рамки прибит к textBox'у, то без всего этого рамку не выведешь.

Просто рамку — да. А какую именно рамку? Она вообще-то может быть существенно разной в зависимости от нескольких параметров. Например, text box может состоять из нескольких подполей. Как ты это передашь в функцию? Он может быть в фокусе, это будет отражаться в методе рисования рамки. Ты это будешь передавать отдельным флагом? Если рамку надо нарисовать другим цветом, будешь передавать указание на этот цвет? Там ещё с полдесятка параметров, о которых ты ещё не знаешь.

Как только ты начнёшь думать передавать в подобной среде всё, что нужно, в функцию, она или превратится в то, как сейчас выглядит CreateFile(), или начнутся извращения со списками свойств (с большой опасностью неправильной конверсии), или с полями структуры, и в результате ты придёшь к тем же объектам, но иначе покрашенным. Посмотри, например, на pthread_create(). Для расширения свойств создаваемой нити придуман отдельный объект (пусть и без явного цикла жизни) атрибутов, и функции работы с параметрами в этом объекте (get, set). Вот такое же будет и тебе для text box. И какой смысл разработчикам делать какое-то отдельное от самого text box'а средство для рисования рамки?

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

Я не смотрел в википедию для понимания этого определения, но если она говорит то же, что я, то это мне только лучше

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

Глобальный флаг стиля интерфейса (XP/Vista/etc., не говоря уж о юниксовых вариантах), параметры установленной цветовой схемы — это аргументы функции или что-то другое? Думаю, вопрос риторический.

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

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

N>>Нет в описанном "чистых функций", не обманывай себя.

U>Если пользоваться академическим и бессмысленным определением из википедии, то, да, нет.
Твое утверждение смахивает на следующее: "бессмысленно стрелять из лука, ведь он вкусен и полезен в салате". В определении из википедии в термин "чистая функция" вкладывается совершенно другой смысл, чем используешь ты. И чистые по твоему функции не обладают теми свойствами, которые требуются для чистоты по википедии. Так как ты можешь делать утврерждения о бессмысленности, если речь о совершенно разных вещах?

U>Если же пользоваться практически полезным определением
Я не мастер восстанавливать определения непротиворечивым образом из контекста, как это любит и умеет DarkGray, потому не мог бы ты дать ссылку на источник практически полезного определения, что бы я мог приобщиться к практической полезности? Ну и вообще-говоря, почему остальные должны пользоваться именно практически полезным определением без источника, если общедоступным и общеупотребимым является определение в википедии? Может википедию стоит дополнить?

U>- "чистой функцией является такая функция, которая использует только аргументы и имеет право их изменять только следующим из своего названия образом", то все это чистые функции.
Практическая польза такого определения для меня не очевидна. Кэшировать результат такой функции нельзя, т.к. нет детерминированности и возможны побочные эффекты. Менять порядок вызова тоже нельзя. Что с ней такого можно делать, что нельзя с чистой по википедии функцией?

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

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

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

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

А при чем здесь ООП то? На чистых функциях то же лишнее состояние прекрасно можно изобразить:

void drawTextBox(HGRAPHICS context, HTEXTBOX textBox)

Здесь я наивно предполагаю, что drawTextBoxBorder спрятана внутри библиотеки и пользователю недоступна. И все — приплыли. Проблема та же самая — сложно отпилить отдельные части для отдельного использования. Функция "чистая" даже в вашем определении — она только меняет context, но не трогает textBox.

Вы же сами пишете, что проблема в лишнем состоянии. Добавлю — еще в "излишней инкапсуляции" библиотек. На самом деле вы хотите, чтобы вам был предоставлен доступ ко всему "стеку" слоев. Для текстбокса это отдельно слои рендеринга ("простого"), модули измерения и раскладки (layout) текста, работы со шрифтам. Также нужно предоставлять доступ к "утилитным" функциям вроде drawTextBoxBorder. Предоставлять доступ к промежуточным слоям никто не запрещает ни ООП, ни чистые функции. Ну и в обоих случаях получится удобный API.

Только вот во всем этом есть одна проблема — проектировать "промежуточные" слои нужно специально для повторного использования. WolfHound это уже высказывал эту мысль в обсуждении. И одна из задач — учет возможных дальнейших изменений библиотеки. Это совсем не так просто, как кажется. То, что для drawTextBoxBorder сейчас не используется состояние текстбокса не значит, что в дальнейшем это состояние не будет использоваться. Например, можно у текстбоксов с фокусом и без иметь различные рамки. Или там для выделенного текста как-то особо отмечать бордер (при перетаскивании текста, например). Или другую рамочку при достижении максимальной длины текста делать (при редактируемом текстбоксе). Все это потребует менять API "чистой" функции drawTextBoxBorder. Что для "повторно используемой" библиотеки является очень плохой идеей. Правильным решением здесь является выделение функции drawCommonTextBox и вызов ее из текстбокса. Но никто не мешает делать такие функции и в ООП. А если вдруг когда-то текстбокс начнет иметь разные рамки, ваше использование drawCommonTextBox будет вести себя немного по-другому. Но здесь вам никто идентичного поведения и не обещал.

P.S. Трансляция между something.someMethod и someMethod(something, ...) вообще должна быть синтаксическим сахаром на уровне компилятора. Но во второй форме будут якобы "чистые методы", которые не имеют проблем. Ну а раз они не имеют проблем, конвертируем их в первую форму и в ООП тоже проблем не будет

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

ГВ>Например, в лучшие для ООП времена бытовала такая мифологема, что скоро программы будут собирать "из кубиков"

Ты спутал ООП и КОП.

ГВ>Как раз топикстартер говорит о прямо противоположном: о том, что элементы ОО-программ на самом деле трудны в повторном использовании.

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

... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>

Здравствуйте, мыщъх, Вы писали:

М>драматизм ситуации в том, что в си все каллбэки объявляются явно. а вот в ооп они хитро скрыты.
кто мешает испольовать воч-лист и трассировщик, что бы дойти до сути?
в делфях насколько я помню это было не просто, а очень просто

хотя я давно не программист, не знаю может в других инструментах налажили и это стало неудобно так же как и докатившаяся до нас лажа с риббонами в области гуи-строения

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

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

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

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

M>А при чем здесь ООП то? На чистых функциях то же лишнее состояние прекрасно можно изобразить:

На это я уже отвечал:

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

Об автоматичности речи точно не было. Чистые функции это необходимое, но недостаточное условие реюзабельного кода.

M>Здесь я наивно предполагаю, что drawTextBoxBorder спрятана внутри библиотеки и пользователю недоступна. И все — приплыли. Проблема та же самая — сложно отпилить отдельные части для отдельного использования. Функция "чистая" даже в вашем определении — она только меняет context, но не трогает textBox.

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

M>Добавлю — еще в "излишней инкапсуляции" библиотек.

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

M> Все это потребует менять API "чистой" функции drawTextBoxBorder. Что для "повторно используемой" библиотеки является очень плохой идеей.

В худшем случае функция drawTextBoxBorder становится obsolete, а textBox начинает использовать функцию drawTextBoxBorder2. В чем проблема-то?

M> Правильным решением здесь является выделение функции drawCommonTextBox и вызов ее из текстбокса.

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

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

S>Твое утверждение смахивает на следующее: "бессмысленно стрелять из лука, ведь он вкусен и полезен в салате". В определении из википедии в термин "чистая функция" вкладывается совершенно другой смысл, чем используешь ты. И чистые по твоему функции не обладают теми свойствами, которые требуются для чистоты по википедии. Так как ты можешь делать утврерждения о бессмысленности, если речь о совершенно разных вещах?

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

S> Ну и вообще-говоря, почему остальные должны пользоваться именно практически полезным определением без источника, если общедоступным и общеупотребимым является определение в википедии? Может википедию стоит дополнить?

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

S>По поводу "следующим из своего названия образом" тоже не совсем ясно. Т.е. получается, что есть функция чистая, меняем у нее одну буковку в названии, получаем не чистую? И наоборот, пусть есть функция, которая использует только аргументы и меняет их некоторым не вполне ясным образом. И что, если мы к ней придумаем такое название, что она будет менять свои аргументы соответствующим образом, то она станет сразу чистой?

Разумеется. Об этом во всех азбуках программирования написано, в главе о именовании функций.

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

MA>Здравствуйте, мыщъх, Вы писали:

М>>драматизм ситуации в том, что в си все каллбэки объявляются явно. а вот в ооп они хитро скрыты.
MA>кто мешает испольовать воч-лист и трассировщик, что бы дойти до сути?
ну вот смотрите:
def main():
for i in range(5):
t = Thread(queue)
t.setDaemon(True)
t.start()

class Thread(threading.Thread):
def __init__(self, queue):
threading.Thread.__init__(self)
self.queue = queue

def run(self):
while True:

в си такое невозможно в принципе. потому что 'run' нужно как-то в Thread передать. а в ооп совсем неочевидно каким образом этот run вообще вызывается. и вызывается ли.

трассировщик не предлагать.

MA>в делфях насколько я помню это было не просто, а очень просто

"очень просто" это смотреть код и читать его без средств динамического анализа.

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

MA>а есть вообще такой инструмент рефакторинга, который заменяет одинаковые классы дженериками
MA>с лексически понятными идентификаторами обобщающими ансамбль таких классов?
"рефракторинг не нужен" (с)

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

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

U>Что такое термин и в чем практический смысл его использования? Термин — это сокращение/псевдоним определения. Т.е. для того, чтобы каждый раз, когда речь заходит о некоей сущности, не писать определение вводится термин и далее используется вместо определения. Определение того, что я понимаю под чистой функцией я дал.
После того как многократно использовал.
U>Подбирать для этой сущности другой термин, на том основании, что термин "чистая функция" уже кем-то занят, я смысла не вижу никакого, т.к. в русском языке не так много слов, и соответственно какое ни возьми окажется что кто-нибудь когда-нибудь уже его использовал в качестве термина. Соответственно спор о терминах это пустая трата времени, обсуждать имеет смысл определения, а не его псевдоним.
Тебе следует использовать свое определение именно каждый раз, потому как собеседники подразумевают под чистотой нечто другое.

S>> Ну и вообще-говоря, почему остальные должны пользоваться именно практически полезным определением без источника, если общедоступным и общеупотребимым является определение в википедии? Может википедию стоит дополнить?

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

S>>По поводу "следующим из своего названия образом" тоже не совсем ясно. Т.е. получается, что есть функция чистая, меняем у нее одну буковку в названии, получаем не чистую? И наоборот, пусть есть функция, которая использует только аргументы и меняет их некоторым не вполне ясным образом. И что, если мы к ней придумаем такое название, что она будет менять свои аргументы соответствующим образом, то она станет сразу чистой?

U>Разумеется. Об этом во всех азбуках программирования написано, в главе о именовании функций.
Ты о содержательных именах? Можно ссылку хотя бы на один букварь, где бы говорилось что имя связано с чистотой функции?

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

U> При засовывании всей функциональности в функции замкнутые на внешнее состояние отпиливание отдельных частей для отдельного использования становится практически невозможным вне зависимости от квалификации проектировщика.

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

M>>Добавлю — еще в "излишней инкапсуляции" библиотек.

U> Принципиальная разница именно в проблеме лишнего состояния, которая не разрешима в рамках чистого ООП.
Кто заставляет вводить лишнее состояние? И как быть в ФП с теми случаями, когда изменяемое состояние нужно? Это практически любые "толстые" клиенты, например.

Чистые функции работают только там, где есть неизменяемое состояние. Только вот проблема в том, что обычно состояние все таки требуется изменять.

Ну например, как на "чистых функциях" будет решаться задача кэширования результатов вызова какого-нибудь сервиса? Базовый метод — callService. Ну и туда, естественно, требует солидный кусок мира — настройки этого сервиса (endpoint, например), аргументы вызова, обработчики результата и т.п. Только не говорите, что для настроек сервиса будет handle — в этом случае у меня это будет объектом с инкапсулированными настройками и сам объект будет называться сервисом. К тому же handle будет обладать той же проблемой. Далее, есть какой-то кэш с методами get/put. Как будет выглядеть "чистая функция", которая может брать значения из кэша? Ей будет передаваться сам кэш и вся та куча параметров (включая endpoint и т.п.), необходимая для работы вызова сервиса? А что будет, если мы потом захотим мониторинг добавить (количество попаданий в кэш)? Нужно будет еще и параметры мониторинга менять с изменением кода? Ну и получим в результате что-то вроде:

HResult callServiceWithPossibleCachingAndMonitoring(HCallCountContext callCountContext, HCacheHitCountContext cacheHitCountContext, HCache cache, HEndpoint endpoint, HArgs args);

Как-то многовато получилось... И при изменениях поддерживать неудобно. Принципиально здесь то, что у нас на самом деле есть 4 "грязных" состояния, которые должна менять функция (два конекста статистики, кэш и сервис). Статистику мы потом еще в базу иногда сбрасываем. Как с этим предлагает бороться ФП? Можно наделать функций-оберток с замыканием на свой "грязный" контекст. Только вот там будут "грязные" функции и без контекста они больше не работают. Ну и те же функции, кстати, будут в объектах ООП. Можно сделать монады и оставить функции "чистыми". Только вот на самом деле неявным (или явным) контекстом будет та самая монада, которая была бы в ООП объектом. Точно так же в ней будет сокрыто состояние. И точно так же, как функции doSomethingWithMonad monad, в ООП будет запись monad.doSomethingWithThis. А еще в ФП будет куча комбинаторов между различными (ведь разные контексты независимы друг от друга для возможности использовать их по-отдельности) монадами. Что-то тоже не очень хорошо получилось. Решение в "ООП" стиле:

public interface Cache<K, V> {
  public void put(K, V);
  public V get(K);
}

public interface Service {
  public HResult call(HArgs args);
}

public static function Service createService(HEndpoint endpoint);
public static function Service createCachedService(Service service, Cache<HArgs, HResult> cache);
public static function Service countCalls(Service service, Counter function);
public static function Cache<K, V> countCacheHits(Cache<K, V> cache, CacheHitCounter counter);

Фактически "те же" монады (каждый экземпляр сервиса — это монада). Только интерфейсы у них меньше и изменять код проще.

M>> Все это потребует менять API "чистой" функции drawTextBoxBorder. Что для "повторно используемой" библиотеки является очень плохой идеей.

U>В худшем случае функция drawTextBoxBorder становится obsolete, а textBox начинает использовать функцию drawTextBoxBorder2. В чем проблема-то?

В этом самом худшем случае! Изменение интерфейса библиотеки — это плохо. Оно заставляет очень долго думать над управлением версиями используемых библиотек. Вот допустим, мы использовали какую-то функциональность из библиотеки VeryCoolTextBox. Она, в свою очередь, использовала где-то drawTextBoxBorder (который и мы тоже использовали). Через полгода нам потребовалась функциональность, появившаяся во второй версии VeryCoolTextBox. Отлично, мы берем вторую версию этой библиотеки. Оказывается, для ее работы нужна еще и вторая версия библиотеки BaseTextBorders (а именно — функция drawTextBoxBorder2). Ладно, взяли библиотеку. И получили, что у половины текстбоксов стиль один (из drawTextBoxBorder), а у другой половины — другой (из VeryCoolTextBox). Ну и что теперь делать? Варианты то есть (можно использовать старую версию VeryCoolTextBox, можно весь код на новые текстбоксы поправить, можно VeryCoolTextBox пропатчить) но думать надо

Случай, когда мы контролируем всех клиентов drawTextBoxBorder, мы не рассматриваем. Этот случай — "код, не предназначенный к повторному использованию".

M>> Правильным решением здесь является выделение функции drawCommonTextBox и вызов ее из текстбокса.

U>Правильным решением будет и выделение функции drawTextBoxBorder как чистой функции нижнего уровня, и функции drawCommonTextBox как чистой функции верхнего уровня, использующей чистые функции нижних уровней. А там уже пользователь фрамеворка сам решит, какой уровень нужно использовать для его задач.

А какие аргументы будет получать drawTextBoxBorder? Это очень важный вопрос. Потому что либо он будет получать "лишнее состояние" (вдруг оно потребуется в дальнейшем), либо он будет получать кучу аргументов (выцарапанных из текстбокса) и будет плохо поддерживать дальнейшие изменения (см. выше про изменение интерфейса функции).

Здравствуйте, мыщъх, Вы писали:

М>в си такое невозможно в принципе. потому что 'run' нужно как-то в Thread передать. а в ооп совсем неочевидно каким образом этот run вообще вызывается. и вызывается ли.

Это не проблемы ООП. Это проблемы конкретного API. То, что в api передается объект у которого ищется метод — это решение данного конкретного API. Туда вполне может передаваться функция. Ну или если функции не поддерживаются (не являются полноценными объектами), то интерфейс runnable. На C что-то подобное и неочевидное изобразить тоже можно. Например, thread.start будет получать адрес функции, которая возвращает адрес структуры, у которой в третьем поле нужно взять адрес функции, которая получив структуру наконец-то вернет адрес фунции, которую нужно выполнять. Но это будут проблемы уже этого API.

P.S. И если там в примере наследование от Thread — это тоже плохое API. Thread вообще должен быть ненаследуемым.

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

M>Здравствуйте, мыщъх, Вы писали:

М>>в си такое невозможно в принципе. потому что 'run' нужно как-то в Thread передать. а в ооп совсем неочевидно каким образом этот run вообще вызывается. и вызывается ли.

M>Это не проблемы ООП. Это проблемы конкретного API.
здраствуйте, я ваша бабушка. а виртуальные функции разве не преподносятся как достижение ООП? и практически все ООП библиотеки в таком стиле написаны.

> То, что в api передается объект у которого ищется метод — это решение данного конкретного API.
> Туда вполне может передаваться функция. Ну или если функции не поддерживаются
в процедурном программировании -- да. функция передается явно. теоритически возможно передавать ее и неявно (например, стартовый код вызывает main или WinMain по имени -- на стадии линковки и, например, из кода совсем неочевидно, что main вызывается один раз, а DllMain — более одного раза), но в ООП это считается хорошим тоном.

Здравствуйте, мыщъх, Вы писали:

M>>Это не проблемы ООП. Это проблемы конкретного API.
М>здраствуйте, я ваша бабушка. а виртуальные функции разве не преподносятся как достижение ООП? и практически все ООП библиотеки в таком стиле написаны.

А кем преподносится? Вас обманули, это устаревшая информация. Я как раз считаю, что виртуальные функции практически всегда — зло! Также зло наследование реализации (а к нему и виртуальные функции приводят). Вместо них как раз делегирование должно использоваться. Т.е. в конструктор объекта передаются реализации виртуальных функций вместо наследования и переопределения функций. В этом случае все занимаются своим делом. Да и вообще любой полиморфизм лучше явно делать (заодно будет продумано, где он может что-то сломать, а где — нет). Т.е. если функция может быть заменена — получать ее явно. Ну и иметь пачку функций, которая создает объекты с "реализациями функций по умолчанию".

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

M>Здравствуйте, мыщъх, Вы писали:

M>>>Это не проблемы ООП. Это проблемы конкретного API.
М>>здраствуйте, я ваша бабушка. а виртуальные функции разве не преподносятся как достижение ООП? и практически все ООП библиотеки в таком стиле написаны.
M>А кем преподносится? Вас обманули, это устаревшая информация.
всеми библиотеками, какие только есть.

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

> Также зло наследование реализации (а к нему и виртуальные функции приводят).
наследование -- зло, но не потому что виртуальные функции, а потому что... ну вот давайте рассмотрим такой пример. у нас есть точка. это базовый класс. отрезок это совокупность точек, так? а фигура это совокупность отрезков. выходит: точка -> отрезок -> фигура. но тут выясняется, что видеокарта имеет отдельную функцию для отрисовки точек и отдельную -- для вывода отрезков. на растровом устройстве отрезок рисовать через многократный вызов "точек" крайне непроизводительно, а внешний вид его ужасен (аппаратаная функция сглаживая с отдельными точками не работает). а еще видеокарта поддерживает текстуры и спрайты, которых вообще нет в геометрической модели точка -> отрезок -> фигура.

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

> Вместо них как раз делегирование должно использоваться.
во! я тоже за делегирование.

Здравствуйте, мыщъх, Вы писали:

>> Также зло наследование реализации (а к нему и виртуальные функции приводят).
М>наследование -- зло, но не потому что виртуальные функции, а потому что... ну вот давайте рассмотрим такой пример. у нас есть точка. это базовый класс. отрезок это совокупность точек, так? а фигура это совокупность отрезков. выходит: точка -> отрезок -> фигура. но тут выясняется, что видеокарта имеет отдельную функцию для отрисовки точек и отдельную -- для вывода отрезков. на растровом устройстве отрезок рисовать через многократный вызов "точек" крайне непроизводительно, а внешний вид его ужасен (аппаратаная функция сглаживая с отдельными точками не работает). а еще видеокарта поддерживает текстуры и спрайты, которых вообще нет в геометрической модели точка -> отрезок -> фигура.
Бред просто фееричен. Чего надо курить чтобы наследовать прямую от точки? Наследование — отношение is-a. В каком смысле "прямая" is-a "точка".

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

G>Здравствуйте, мыщъх, Вы писали:

G>Бред просто фееричен. Чего надо курить чтобы наследовать прямую от точки?
G>Наследование — отношение is-a. В каком смысле "прямая" is-a "точка".
идите лесом. есть базовый класс. он выводит пиксель. производный класс расширяет функционал до отрисовки Line. если это бред, то не мой. это то, что пишут в книгах за ООП. и это то, с чем я не согласен

Здравствуйте, мыщъх, Вы писали:

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

G>>Здравствуйте, мыщъх, Вы писали:

G>>Бред просто фееричен. Чего надо курить чтобы наследовать прямую от точки?
G>>Наследование — отношение is-a. В каком смысле "прямая" is-a "точка".
М>идите лесом. есть базовый класс. он выводит пиксель. производный класс расширяет функционал до отрисовки Line. если это бред, то не мой. это то, что пишут в книгах за ООП. и это то, с чем я не согласен
Может тогда сделать строку производной от класса символа, который выводит символ в консоль, что бы расширить символ до вывода строки?

А где такое пишут?

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

S>Может тогда сделать строку производной от класса символа, который выводит символ в консоль, что бы расширить символ до вывода строки?
а это не так? ооп не заканчивается на плюсах. во многих языках даже число 1 это оъект. тем более символ. кстати, а вы уверены, что класс символа у вас есть? что у вас вообще есть символ? опять же, в мире есть не только плюсы. есть языки в которых есть только строки и 'a' === "a".

Здравствуйте, мыщъх, Вы писали:

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

S>>Может тогда сделать строку производной от класса символа, который выводит символ в консоль, что бы расширить символ до вывода строки?
М>а это не так?
Полагаю, что нет
М>ооп не заканчивается на плюсах.
и не начинается
М>во многих языках даже число 1 это оъект. тем более символ. кстати, а вы уверены, что класс символа у вас есть? что у вас вообще есть символ? опять же, в мире есть не только плюсы.
да, знаю такие языки.
М>есть языки в которых есть только строки и 'a' === "a".
Но мы говорим о случае, когда строка расширяет символ (линия рассширяет пиксель). Вот такие примеры хотелось бы посмотреть. Обобщим до случая, когда коллекция расширяет элемент

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

ГВ>>Например, в лучшие для ООП времена бытовала такая мифологема, что скоро программы будут собирать "из кубиков"
AVK>Ты спутал ООП и КОП.

Тогда, когда я это первый раз прочёл, ещё не выделяли КОП. "Компоненты программ" были, а КОП — ещё нет, или этот термин не слишком широко употреблялся.

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

ГВ>Тогда, когда я это первый раз прочёл, ещё не выделяли КОП. "Компоненты программ" были, а КОП — ещё нет, или этот термин не слишком широко употреблялся.

Это просто некоторое время многие КОП и ООП, путали, потому что подавляющее большинство реализаций КОП было поверх ООП. Для КОП нужен модуль, а не объект. Поэтому КОП прекрасно реализауетя на необъектной Модуле, но весьма скверно на объектных плюсах.

... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>

Здравствуйте, мыщъх, Вы писали:

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

G>>Здравствуйте, мыщъх, Вы писали:

G>>Бред просто фееричен. Чего надо курить чтобы наследовать прямую от точки?
G>>Наследование — отношение is-a. В каком смысле "прямая" is-a "точка".
М>идите лесом. есть базовый класс. он выводит пиксель. производный класс расширяет функционал до отрисовки Line. если это бред, то не мой. это то, что пишут в книгах за ООП. и это то, с чем я не согласен

Покажи что за книга. Это полнейший бред. Максимум что я видел — когда есть общий предок "Figure".

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

G>Сложно сказать. Все новое хорошо забытое старое. Если не верить всему что читаешь, а пытаться сопоставить с современными реалиями. Полезное можно найти и у фаулера, и у мартина, и у банды четрырех. Но надо думать головой.

видимо думать надо исключительно *вашей* головой, потому что все остальные думают неправильно, включая упомянутых Фаулера, Мартина и GoF.

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

FR>Здравствуйте, Константин Б., Вы писали:

КБ>>Тут дело не в чистых функциях, а в том что в Qt вынесли наружу функцию рисования рамки, а в винде — не вынесли.
КБ>>Очевидно что в недрах USER32 такая функция есть, вся из себя чистая и не-ООПная, а повторно использовать ее — не получится.

FR>http://msdn.microsoft.com/en-us/library/dd162480(v=vs.85).aspx

в каком месте она чистая и не-ООПшная ?
большая часть WinAPI это чистое OOP, просто this передается в виде непрозрачного хендла, в данном случае HDC

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

FR>>http://msdn.microsoft.com/en-us/library/dd162480(v=vs.85).aspx

A>в каком месте она чистая и не-ООПшная ?
A>большая часть WinAPI это чистое OOP, просто this передается в виде непрозрачного хендла, в данном случае HDC

Ни в каком ни чистая, но и не ООП'ная. ОО'шных функций в WInAPI (та же обработка сообщений, хендлы, не говоря уже
о COM) функций полно, но эту конкретно к таким только с натяжкой можно отнести.

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

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

G>>Сложно сказать. Все новое хорошо забытое старое. Если не верить всему что читаешь, а пытаться сопоставить с современными реалиями. Полезное можно найти и у фаулера, и у мартина, и у банды четрырех. Но надо думать головой.

A>видимо думать надо исключительно *вашей* головой, потому что все остальные думают неправильно, включая упомянутых Фаулера, Мартина и GoF.

Нет, думать надо своей, а некоторые предпочитают чьей-то другой. Фаулер, Мартин и GoF — они пишут красиво, но не всегда правильно, и не всегда актуально.

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

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

КБ>>>Очевидно что в недрах USER32 такая функция есть, вся из себя чистая и не-ООПная, а повторно использовать ее — не получится.

FR>>http://msdn.microsoft.com/en-us/library/dd162480(v=vs.85).aspx

A>в каком месте она чистая и не-ООПшная ?
Чистая не в плане детерминированная и без побочных эффектов, чистая по Undying'y (http://www.rsdn.ru/forum/philosophy/4592381.1.aspx).

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

U>Проблема излишней инкапсуляции может возникнуть и в чистых функциях, и в ООП. Ее разрешение также возможно и там, и там при соизмеримых усилиях.
Принципиальная разница именно в проблеме лишнего состояния, которая не разрешима в рамках чистого ООП.

Ты не мог бы подробнее рассказать про "проблему лишнего состояния". А то я не могу понять, что ты имеешь ввиду.

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

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

То есть если, например, в коболе запретить глобальные переменные, то мы получим чистый функциональный язык программирования?

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

ГВ>>Тогда, когда я это первый раз прочёл, ещё не выделяли КОП. "Компоненты программ" были, а КОП — ещё нет, или этот термин не слишком широко употреблялся.

AVK>Это просто некоторое время многие КОП и ООП, путали, потому что подавляющее большинство реализаций КОП было поверх ООП. Для КОП нужен модуль, а не объект. Поэтому КОП прекрасно реализауетя на необъектной Модуле,

Прежде всего, для КОП нужна инфраструктура, без неё компонентов просто не может существовать. Исполняющая машина Модулы, по-видимому, таковой и является.

AVK>но весьма скверно на объектных плюсах.

Если инфраструктура подразумевает runtime-компиляцию — да, с её реализацией на C++ будут проблемы (нюансы замнём для ясности). Если требования runtime-компиляции нет, то вполне можно и на C++, придерживаясь соответствующих API.

Здравствуйте, мыщъх, Вы писали:

G>>Бред просто фееричен. Чего надо курить чтобы наследовать прямую от точки?
G>>Наследование — отношение is-a. В каком смысле "прямая" is-a "точка".
М>идите лесом. есть базовый класс. он выводит пиксель. производный класс расширяет функционал до отрисовки Line. если это бред, то не мой. это то, что пишут в книгах за ООП. и это то, с чем я не согласен

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

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

A>>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания.
S>Профит в том, что повышается переиспользование кода

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

1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.
2. Переиспользование кода миф само по себе. Оно противоречит профессиональным склонностям программистов копать свой огород и не пущать туда чужаков (синдром NIH). При благих же намерениях оказывается, что затраты на обработку модуля напильником модуля для реюза больше, чем профит от реюза. Только на хорошо известные библиотеки/API можно полагаться в этом смысле, да и то всегда найдется пучок фич, которые с выбранной библиотекой/API не сделать.
3. Профит от ООП только один. Это способ организации кода. Все. Других профитов нет, но этот настолько могуч, что оправдывает ООПшный подход на все сто. Простейший пример: возьмите HWND из WinAPI и MFC-шный CWnd. В первом случае вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС. Во втором случае вы изначально понимаете, что есть некоторая оконная сущность, которая что-то "умеет делать" и обладает какими-то свойствами. А ведь это еще полуобъектное API, в котором для HWND отдельный тип завели. Чаще всего дадут int id, и вперед — разбирайся сам.
4. Наконец, ООП требует от программиста определенных навыков. Так называемого понятийного мышления. Умения отделить первичные половые признаки от вторичных, роли от исполнителей и так далее. Про девяносто с лишним процентов слышали? Это ведь и есть первичный признак, который их отделяет от меньшинства. Когда такой большевик берет в руки классы и пытается сделать реюз на несколько проектов, уж лучше бы он простые функции использовал.
5. Погнавшись за реюзом в ООПшном стиле (или просто за "чистотой ООП", без мыслей о реюзе) очень легко простейшие вещи запутать так, что появляется стойкое отвращение от ООП. У меня такие чувства вызывает Java на фоне C#.

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

SV.>Здравствуйте, supacrazypusher, Вы писали:

A>>>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания.
S>>Профит в том, что повышается переиспользование кода

SV.>По-моему, это миф, причем вредный. Типа, он еще и геморрой лечит. Человек попробует, геморрой останется неизлеченным, получит предубеждение.

SV.>1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.

Не совсем так. Да, принципиально важно в первую очередь, чтобы код был рассчитан на использование не только в исходном окружении разработки — минимум допущений о среде выполнения, разумное расширение возможностей, и так далее. Но есть принципиальные моменты, которые крайне тяжело реализуются в процедурном варианте и легко — в объектном, и в первую очередь это готовность к будущим расширениям. Я уже приводил пример, когда в следующей версии добавляется какой-то новый настроечный параметр: если у нас объект, просто добавится метод для установки этого параметра, а как там оно внутри лежит — неважно. Если функция, придётся делать новую функцию с ещё одним параметром, и так каждый раз. Объектный стиль (даже без ООП, даже в виде WinAPI) решает эту проблему.

SV.>2. Переиспользование кода миф само по себе. Оно противоречит профессиональным склонностям программистов копать свой огород и не пущать туда чужаков (синдром NIH).

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

SV.> При благих же намерениях оказывается, что затраты на обработку модуля напильником модуля для реюза больше, чем профит от реюза. Только на хорошо известные библиотеки/API можно полагаться в этом смысле, да и то всегда найдется пучок фич, которые с выбранной библиотекой/API не сделать.

Моя практика это опровергает. Ну-ка перепишите мне для каждого проекта libc, openssl и прочие. Что, времени нет?

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

SV.>3. Профит от ООП только один. Это способ организации кода. Все. Других профитов нет, но этот настолько могуч, что оправдывает ООПшный подход на все сто. Простейший пример: возьмите HWND из WinAPI и MFC-шный CWnd. В первом случае вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС.

Это уже объектный подход. Даже если не ООП в полной мере.

SV.> Во втором случае вы изначально понимаете, что есть некоторая оконная сущность, которая что-то "умеет делать" и обладает какими-то свойствами. А ведь это еще полуобъектное API, в котором для HWND отдельный тип завели. Чаще всего дадут int id, и вперед — разбирайся сам.

Да, именно способ организации кода. Но от него "профит" во множестве вопросов.

SV.>4. Наконец, ООП требует от программиста определенных навыков. Так называемого понятийного мышления. Умения отделить первичные половые признаки от вторичных, роли от исполнителей и так далее. Про девяносто с лишним процентов слышали? Это ведь и есть первичный признак, который их отделяет от меньшинства. Когда такой большевик берет в руки классы и пытается сделать реюз на несколько проектов, уж лучше бы он простые функции использовал.

Да, это очень существенный аргумент. С другой стороны, есть же и рефакторинг. В некоторых задачах мне лучше получить работающий код, пусть и с ужасным пониманием задачи, а потом его приводить в порядок, чем вообще ничего не получить. Да, у меня есть сотрудники, которым крайне тяжело осмысленно разделить сущности на классы. Но они делают своё дело, и достаточно неплохо. С другой стороны, я сам с собой натыкаюсь на это постоянно: вот тут что-то сделано в расчёте, что будет только такое отношение и только такая связь => надо срочно переделывать. Это нормально, это проблемы осознания и развития.

А к идеям таких сотрудников, о которых Вы говорите, можно и design review применить, указав на явные недостатки.

SV.>5. Погнавшись за реюзом в ООПшном стиле (или просто за "чистотой ООП", без мыслей о реюзе) очень легко простейшие вещи запутать так, что появляется стойкое отвращение от ООП. У меня такие чувства вызывает Java на фоне C#.

Ну а у меня код некоторых коллег на C++. Когда такой в первую очередь думает о том, как объекту завести iterator traits и как его сделать универсальным шаблоном, ещё не зная задач, но при этом у него в кастомном протоколе половина полей BE, а половина LE — хочется пересадить человека на бейсик, чтобы меньше вредил

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

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

И в сложной среде это делать значительно сложнее, чем при объектном подходе.
Причём достаточно удобно это оказывается делать только на динамических языках — там, где всё устроено для передачи чего угодно любого типа через словарь параметров или property list.

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

ГВ>Прежде всего, для КОП нужна инфраструктура

И эта инфраструктура называется модуль.

AVK>>но весьма скверно на объектных плюсах.

ГВ>Если инфраструктура подразумевает runtime-компиляцию — да, с её реализацией на C++ будут проблемы

В Модуле не было runtime-компиляции.

ГВ>Если требования runtime-компиляции нет, то вполне можно и на C++, придерживаясь соответствующих API.

Возможно, но на выходе монстрики типа СОМ или CORBA получаются.

... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>

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

SV.>>1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.

N>Не совсем так. ... Я уже приводил пример, когда в следующей версии добавляется какой-то новый настроечный параметр

К своему удивлению, узнал, что это тоже считается реюзом:

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

The general practice of using a prior version of an extant program as a starting point for the next version, is also a form of code reuse.

Я же полагал, что another program это именно another.

Code reuse is the idea that a partial computer program written at one time can be, should be, or is being used in another program written at a later time.

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

SV.>>2. Переиспользование кода миф само по себе. Оно противоречит профессиональным склонностям программистов копать свой огород и не пущать туда чужаков (синдром NIH).

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

Нет, я просто по жизни. Делю я уже обобщая наблюдения. Вот вы пишете "проще и легче" — когда же программисты ходили простыми и легкими путями?

Кроме того, я не согласен с оценками типа "тормозят отрасль в целом". Это же экономика. Область с неевклидовым пространством. Цели подчас достигаются через самую запутанную "жопу с закоулками", а потом оказывается, что это был кратчайший путь. Функциональное программирование как пошло в народ? В сишарпе лямбды ввели. Цеховики протолкнули, короче.

SV.>> При благих же намерениях оказывается, что затраты на обработку модуля напильником модуля для реюза больше, чем профит от реюза. Только на хорошо известные библиотеки/API можно полагаться в этом смысле, да и то всегда найдется пучок фич, которые с выбранной библиотекой/API не сделать.

N>Моя практика это опровергает. Ну-ка перепишите мне для каждого проекта libc, openssl и прочие. Что, времени нет?

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

Как раз, libc, openssl — хорошо известные библиотеки/API. Что ваша практика говорит о модуле Васи из соседнего отдела?

SV.>>3. Профит от ООП только один. Это способ организации кода. Все. Других профитов нет, но этот настолько могуч, что оправдывает ООПшный подход на все сто. Простейший пример: возьмите HWND из WinAPI и MFC-шный CWnd. В первом случае вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС.

N>Это уже объектный подход. Даже если не ООП в полной мере.

Вынужден констатировать, что мой пример остался непонятым. Да, это объектный подход. Но что мешает нам считать WinAPI "ООП в полной мере"? Есть ли какой-то признак, который позволит отделять мух от котлет? Да вот же он: "вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС".

Могу переформулировать. Берется независимая IDE общего назначения. В случае с ООП вы набиваете селектор члена (точку или стрелочку) et voila — вот вам окно как есть, целиком и полностью. Несмотря на всю "объектность" подхода, с WinAPI такого сделать нельзя. Просто потому, что IDE не может отличать HWND от других указателей. Следовательно, какая-то метаинформация теряется. А раз так, ООП объективно отличается от "просто объектного" подхода.

Вот что показывал мой пример.

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

SV.>Здравствуйте, netch80, Вы писали:

SV.>Могу переформулировать. Берется независимая IDE общего назначения. В случае с ООП вы набиваете селектор члена (точку или стрелочку) et voila — вот вам окно как есть, целиком и полностью. Несмотря на всю "объектность" подхода, с WinAPI такого сделать нельзя. Просто потому, что IDE не может отличать HWND от других указателей. Следовательно, какая-то метаинформация теряется. А раз так, ООП объективно отличается от "просто объектного" подхода.

SV.>Вот что показывал мой пример.
Т.е. по вашему объектность подхода заключается в ... IDE

Хорошо, поставим мысленный эксперимент: предположим что появился плагин к IDE, который при набирании точки за HWND типом покажет все методы, принимающие HWND первым аргументом. С такой штукой WinAPI станет окончательно объектным?

Здравствуйте, Artifact, Вы писали:
A>Почему так получается, что когда код представляет из себя набор классов, то такой код очень затрудлителен для понимания.

Дело не в ООП. Такую же ситуацию можно получить и в других парадигмах. Без разницы.
Дело вот в этом:

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

Ситуация стала такой давно, когда у ведущих менеджеров отрасли возникла идея: заменить нескольких классных (и капризных) разработчиков толпой послушных и управляемых "кодеров".
А под эту цель подтянулось и все остальное (и комплект "серебряных пуль" в частности). Масштабирование команд, "повторное использование кода" (идея мутировавшая в "использование чужого кода"), языки не запрещающие прострелить себе ногу (кодеры же...) и многое еще подобное. Я несколько сомневаюсь, что выстроенный таким образом колосс индустрии может быть изменен. Подождем пока рухнет...

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

U>Т.е. надо позвонить в Микрософт и сказать, что у них проектировщики дебилы, не догадавшиеся заюзать в textbox'е паттерн декоратор?

Они и так в курсе. Достаточно поглядеть на аналог в WPF.

... << RSDN@Home 1.2.0 alpha 5 rev. 16 on Windows 7 6.1.7601.65536>>

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

SV.>>>1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.
N>>Не совсем так. ... Я уже приводил пример, когда в следующей версии добавляется какой-то новый настроечный параметр
SV.>К своему удивлению, узнал, что это тоже считается реюзом:
SV.>Я же полагал, что another program это именно another.
SV.>Что ж, тут вы правы. Если мы рассматриваем новые версии продукта как реюз, мой тезис перестает работать.

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

SV.>Нет, я просто по жизни. Делю я уже обобщая наблюдения. Вот вы пишете "проще и легче" — когда же программисты ходили простыми и легкими путями?

Вообще-то 99% именно ими и идут. Они усложняют там, где явно хотят усложнить (и думают, что справятся с этой сложностью), в остальном же идут простым и лёгким путём. Собственно, то, где именно применён сложный путь вместо простого, хорошо показывает цели разработки (неважно, реализованы они непосредственно кодером или приказало начальство).

SV.>Кроме того, я не согласен с оценками типа "тормозят отрасль в целом". Это же экономика. Область с неевклидовым пространством. Цели подчас достигаются через самую запутанную "жопу с закоулками", а потом оказывается, что это был кратчайший путь. Функциональное программирование как пошло в народ? В сишарпе лямбды ввели. Цеховики протолкнули, короче.

C# как раз не средство цеховиков. И вообще, я не знаю, почему для Вас ФП началось с лямбд в шарпе. Я ещё в школе знал, что такое LISP.

SV.>>> При благих же намерениях оказывается, что затраты на обработку модуля напильником модуля для реюза больше, чем профит от реюза. Только на хорошо известные библиотеки/API можно полагаться в этом смысле, да и то всегда найдется пучок фич, которые с выбранной библиотекой/API не сделать.
N>>Моя практика это опровергает. Ну-ка перепишите мне для каждого проекта libc, openssl и прочие. Что, времени нет?

Лучше потерпеть отдельные недостатки, чем пытаться сдвинуть гору в одиночку.
SV.>Как раз, libc, openssl — хорошо известные библиотеки/API. Что ваша практика говорит о модуле Васи из соседнего отдела?

Говорит, что до тех пор, пока модуль Васи удовлетворяет, мы используем его. Если нет — пинаем Васю. И только если он отказывается удовлетворять наши хотелки, начинаем думать о чём-то своём особом.
Некоторое количество велосипедов есть, но в основном в мелочах и чисто от незнания.
Нам сейчас не до того, чтобы барьеры наворачивать — тематика и так безумно сложная.

SV.>>>3. Профит от ООП только один. Это способ организации кода. Все. Других профитов нет, но этот настолько могуч, что оправдывает ООПшный подход на все сто. Простейший пример: возьмите HWND из WinAPI и MFC-шный CWnd. В первом случае вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС.
N>>Это уже объектный подход. Даже если не ООП в полной мере.
SV.>Вынужден констатировать, что мой пример остался непонятым. Да, это объектный подход. Но что мешает нам считать WinAPI "ООП в полной мере"?

Я не знаю, что мешает именно Вам. Боюсь, у каждого в этой ветке своё понимание ООП. Я его считаю вполне объектным, но насколько сложно сделать его полностью соответствующим знаменитой триаде "инкапсуляция, наследование, полиморфизм" для каждого конкретного случая, я не берусь решать. Мне кажется, что это всё там реализуется без особых извращений, а если какие-то и есть, то вызваны исключительно барьером между средствами языка и средствами системы. Но, может, кто-то посчитает и иначе.

SV.> Есть ли какой-то признак, который позволит отделять мух от котлет? Да вот же он: "вы смотрите на набор функций, выискиваете те, что с HWND в первом параметре, и только тогда понимаете концепцию окна в этой ОС".

А кто это сказал и почему? Концепция окна вообще-то может быть понята и по внятному описанию, без списка функций. Если кому-то она становится ясна только по этому списку, это уже индивидуальные особенности восприятия. Возможно, в чём-то и полезные, но в данном случае — вредные.

SV.>Могу переформулировать. Берется независимая IDE общего назначения. В случае с ООП вы набиваете селектор члена (точку или стрелочку) et voila — вот вам окно как есть, целиком и полностью. Несмотря на всю "объектность" подхода, с WinAPI такого сделать нельзя. Просто потому, что IDE не может отличать HWND от других указателей.

А что ей мешает? Нарисуйте меню "что-то сделать с локальными переменными", выберите hWnd в списке, затем выберите конкретное действие, заполните аргументы... Не IDE сейчас не может, а тот, кто решил, что действие надо выбирать только после того, как кто-то нарисовал стрелочку.

SV.> Следовательно, какая-то метаинформация теряется.

Ничего не теряется.

SV.>Вот что показывал мой пример.

Сочувствую. Следующий. (tm)

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

AE>Ситуация стала такой давно, когда у ведущих менеджеров отрасли возникла идея: заменить нескольких классных (и капризных) разработчиков толпой послушных и управляемых "кодеров".

Эта "идея" существует сколько вообще существует программирование. Но реализоваться ей не дали толком до тех пор, пока не случилось первой попытки сделать суперуниверсальное средство на всё (а это была OS/360). Итого, от её выхода в мир прошло уже лет 50.

AE>А под эту цель подтянулось и все остальное (и комплект "серебряных пуль" в частности). Масштабирование команд, "повторное использование кода" (идея мутировавшая в "использование чужого кода"), языки не запрещающие прострелить себе ногу (кодеры же...) и многое еще подобное. Я несколько сомневаюсь, что выстроенный таким образом колосс индустрии может быть изменен. Подождем пока рухнет...

А нет колосса. Есть миллиарды маленьких садовых статуй. И если из них 1% в месяц рассыпается в пыль, на общем фоне это незаметно.

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

SV.>>Могу переформулировать. Берется независимая IDE общего назначения. В случае с ООП вы набиваете селектор члена (точку или стрелочку) et voila — вот вам окно как есть, целиком и полностью. Несмотря на всю "объектность" подхода, с WinAPI такого сделать нельзя. Просто потому, что IDE не может отличать HWND от других указателей. Следовательно, какая-то метаинформация теряется. А раз так, ООП объективно отличается от "просто объектного" подхода.

SV.>>Вот что показывал мой пример.
S>Т.е. по вашему объектность подхода заключается в ... IDE

Это был переформулированный пример. Пример. Иллюстрация. И он, этот пример, показывал отличие объектного, по сути, кода, но не ООП, от истинного ООП.

Отличие же в том, что в одном случае сущности в коде представлены неявно, а в другом — явно. Работу с неявными сущностями нельзя автоматизировать, и IDE — лучший способ увидеть, какие из явности/неявности проистекают последствия. Еще один пример: диаграммы сущностей и их связи. Человек, если подумает, сможет и по WinAPI такую схему построить, а машина — нет. В то же время, для MFC это делается легко.

S>Хорошо, поставим мысленный эксперимент: предположим что появился плагин к IDE, который при набирании точки за HWND типом покажет все методы, принимающие HWND первым аргументом. С такой штукой WinAPI станет окончательно объектным?

Поэтому я написал — "независимая". Имея в виду сценарии, типа, Микрософта, прикручивающего к студии возможность комбинировать функции по HWND. Нет, такой плагин будет неявно опираться на знание, что такое этот HWND, которое иначе могло бы быть явно выражено в коде. Для независимой IDE со STRICT'ом это будет просто указатель. Можно ввести соглашение, что указатели, чьи typedef'ы начинаются с H — хендлы, но есть гораздо лучшее соглашение: ключевое слово class.

Здравствуйте, мыщъх, Вы писали:

М>>>драматизм ситуации в том, что в си все каллбэки объявляются явно. а вот в ооп они хитро скрыты.
MA>>кто мешает испольовать воч-лист и трассировщик, что бы дойти до сути?
М>ну вот смотрите:
М>def main():
М> for i in range(5):
М> t = Thread(queue)
М> t.setDaemon(True)
М> t.start()

М>class Thread(threading.Thread):
М> def __init__(self, queue):
М> threading.Thread.__init__(self)
М> self.queue = queue

М> def run(self):
М> while True:

М>в си такое невозможно в принципе. потому что 'run' нужно как-то в Thread передать. а в ооп совсем неочевидно каким образом этот run вообще вызывается. и вызывается ли.
М>трассировщик не предлагать.

Ты тут основываешься только на скрытом коде в библиотеке.
Вариант с такими же последствиями на Си:

struct mythread {
  void *func(void);
};

void run(void) {
  printf("Hello world, I'm thread\n");
}

int main() {
  struct mythread t;
  memset(&t, 0, sizeof(t));
  t->func = run;
  mythread_start(&t);
  ...
}

Ты не знаешь, не прочитав документацию, вызовет ли кто-то func или нет. И как и когда вызовет. Может, это замена тела треда, а может, какая-то инициализация параметров — из показанного это не видно.

MA>>в делфях насколько я помню это было не просто, а очень просто

При куче слоёв внутренней логики? А если winapi включается то совсем ничего не понятно...

MA>>а есть вообще такой инструмент рефакторинга, который заменяет одинаковые классы дженериками
MA>>с лексически понятными идентификаторами обобщающими ансамбль таких классов?
М>"рефракторинг не нужен" (с)

А что это за новое слово в IT?

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

T>Ты не мог бы подробнее рассказать про "проблему лишнего состояния". А то я не могу понять, что ты имеешь ввиду.

http://rsdn.ru/forum/philosophy/4582636.1.aspx

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

M>>>Это не проблемы ООП. Это проблемы конкретного API.
М>>здраствуйте, я ваша бабушка. а виртуальные функции разве не преподносятся как достижение ООП? и практически все ООП библиотеки в таком стиле написаны.
M>А кем преподносится? Вас обманули, это устаревшая информация. Я как раз считаю, что виртуальные функции практически всегда — зло! Также зло наследование реализации (а к нему и виртуальные функции приводят). Вместо них как раз делегирование должно использоваться. Т.е. в конструктор объекта передаются реализации виртуальных функций вместо наследования и переопределения функций.

И что хорошего это даёт? Вместо того, чтобы переопределить, например, 2 функции, вписывать их 50? А как быть с тем, что кроме функций там ещё есть поля данных, с которыми им надо работать?

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

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

T>>Ты не мог бы подробнее рассказать про "проблему лишнего состояния". А то я не могу понять, что ты имеешь ввиду.

U>http://rsdn.ru/forum/philosophy/4582636.1.aspx

Не нашел там ни одного упоминания "лишнего состояния". Ты там говорил про лишние зависимости и лишнюю ответственность. Я правильно понимаю, что лишние зависимости и ответственности ты называешь "проблемой лишнего состояния"? Непонятно, правда, откуда берется состояние, ну да ладно, не буду придираться к твоим терминам. Далее ты сказал, что "проблема лишнего состояния" специфична для ООП. Не мог бы ты пояснить, почему ты считаешь, что проблема лишних зависимостей и ответственностей специфична для ООП? Почему "textBox.DrawBorder()" — это плохо, а "void DrawBorder(TextBox textBox)" — хорошо?

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

N>И что хорошего это даёт? Вместо того, чтобы переопределить, например, 2 функции, вписывать их 50? А как быть с тем, что кроме функций там ещё есть поля данных, с которыми им надо работать?

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

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

SV.>Здравствуйте, samius, Вы писали:

S>>Т.е. по вашему объектность подхода заключается в ... IDE

SV.>Это был переформулированный пример. Пример. Иллюстрация. И он, этот пример, показывал отличие объектного, по сути, кода, но не ООП, от истинного ООП.

SV.>Отличие же в том, что в одном случае сущности в коде представлены неявно, а в другом — явно. Работу с неявными сущностями нельзя автоматизировать, и IDE — лучший способ увидеть, какие из явности/неявности проистекают последствия. Еще один пример: диаграммы сущностей и их связи. Человек, если подумает, сможет и по WinAPI такую схему построить, а машина — нет. В то же время, для MFC это делается легко.
То есть вы настаиваете на том, что истинное ООП от неистинного отличает возможность IDE к вываливанию имен методов и построения диаграммы?

S>>Хорошо, поставим мысленный эксперимент: предположим что появился плагин к IDE, который при набирании точки за HWND типом покажет все методы, принимающие HWND первым аргументом. С такой штукой WinAPI станет окончательно объектным?

SV.>Поэтому я написал — "независимая". Имея в виду сценарии, типа, Микрософта, прикручивающего к студии возможность комбинировать функции по HWND. Нет, такой плагин будет неявно опираться на знание, что такое этот HWND, которое иначе могло бы быть явно выражено в коде. Для независимой IDE со STRICT'ом это будет просто указатель.
Не понимаю, что такое "независимая". Т.е. с одной IDE мы имеем истинный ООП код, а с другой IDE тот же самый код становится "просто объектным" но не истинным?

SV.>Можно ввести соглашение, что указатели, чьи typedef'ы начинаются с H — хендлы, но есть гораздо лучшее соглашение: ключевое слово class.
А как же языки с динамической типизацией? Пусть в них есть слово class, но там один class от другого отличается не больше чем HWND от указателя. Или истинный ООП несовместим с динамической типизацией?

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

T> Ты там говорил про лишние зависимости и лишнюю ответственность. Я правильно понимаю, что лишние зависимости и ответственности ты называешь "проблемой лишнего состояния"?

Да, правильно.

T>Далее ты сказал, что "проблема лишнего состояния" специфична для ООП.

Специфична в том плане, что в чистом ООП она не имеет хорошего решения. При выносе функциональности в чистые функции хорошее решение есть, но естественно чтобы оно получилось надо думать и прилагать усилия.

T>Не мог бы ты пояснить, почему ты считаешь, что проблема лишних зависимостей и ответственностей специфична для ООП? Почему "textBox.DrawBorder()" — это плохо, а "void DrawBorder(TextBox textBox)" — хорошо?

С точки зрения повторного использования плохо и первое, и второе. Еще раз повторяю, что вынос функциональности в чистые функции это необходимое, но недостаточное условие написания повторно используемого кода.

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

T>> Ты там говорил про лишние зависимости и лишнюю ответственность. Я правильно понимаю, что лишние зависимости и ответственности ты называешь "проблемой лишнего состояния"?

U>Да, правильно.

T>>Далее ты сказал, что "проблема лишнего состояния" специфична для ООП.

U>Специфична в том плане, что в чистом ООП она не имеет хорошего решения. При выносе функциональности в чистые функции хорошее решение есть, но естественно чтобы оно получилось надо думать и прилагать усилия.

Вообще-то имеет. Хорошее решение называется SRP.
В твоем примере с textbox'ом можно вынести ответственность по рисованию рамки в отдельную сущность — "рисователь рамки". После чего textBox, а также все, кому надо нарисовать рамку, будут для этого использовать "рисователь рамки".

Можно пойти дальше и инъектировать "рисователь рамки" в textBox через абстрактный интерфейс, получив таким образом:
а) Гибкость. Можно инъектировать какой-угодно "рисователь рамки" и получать textBox'ы с разными рамками.
b) Тестируемость. Можно проверить в автоматическом тесте, что textBox когда надо рисует какую-надо рамку.
c) Декомпозицию. В классе textBox будет находится только код, специфичный именно для textBox.

Далее, в "рисователь рамки" в свою очередь можно инъектировать средства рисования. Таким образом опять получим
а) Гибкость. Можно рисовать одну и туже рамку через GDI, OpenGL, DirectX и т.д.
b) Тестируемость. При тестировании контролов появится возможность обойтись без реального графического устройства.
c) Декомпозицию.
и т.д.

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

M>А кто заставляет проектировщика засовывать всю функциональность в функции, замкнутые на внешнее состояние?

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

M>Кто мешает создавать объекты с "чистыми" функциями?

Чистые функции могут быть только у объекта не имеющего состояния. Такой объект обычно бессмысленен (хотя как показывает Qt иногда такой подход возможен и удобен).

M>Кто заставляет вводить лишнее состояние?

Ответил в первом вопросе.

M>И как быть в ФП с теми случаями, когда изменяемое состояние нужно? Это практически любые "толстые" клиенты, например.

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

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

Мое определение чистой функции отличается от академического. Чистая функция — это такая функция, которая обращается только к переданным аргументам и не изменяет их состояния, за исключением оговоренного в названии. Например, функцию DrawCell(Graphics graphics, Rectangle cellRect, CellInfo cell) я считаю чистой, при условии, что она изменяет только состояние graphics и только внутри переданного cellRect.

M>public static function Service createService(HEndpoint endpoint);
M>public static function Service createCachedService(Service service, Cache<HArgs, HResult> cache);
M>public static function Service countCalls(Service service, Counter function);
M>public static function Cache<K, V> countCacheHits(Cache<K, V> cache, CacheHitCounter counter);
M>[/code]
M>Фактически "те же" монады (каждый экземпляр сервиса — это монада). Только интерфейсы у них меньше и изменять код проще.

Это вроде и есть чистые функции. Они уж у тебя на глобальное состояние не замкнуты? Единственное, что меня тут смущает, зачем countCalls и countCacheHits возвращают сервис и кэш? Это тот же самый кэш/сервис переданный в аргументах или новый?

M>В этом самом худшем случае! Изменение интерфейса библиотеки — это плохо.

Все равно не понял специфичности проблемы. Есть объективная проблема — увеличиваем инкапсуляцию, уменьшаем гибкость. Увеличиваем гибкость, уменьшаем инкапсуляцию и соответственно получаем проблемы с той же версионностью. Эта проблема от подхода мало зависит, в чистом ООП она точно также возникает.

M>А какие аргументы будет получать drawTextBoxBorder? Это очень важный вопрос. Потому что либо он будет получать "лишнее состояние" (вдруг оно потребуется в дальнейшем), либо он будет получать кучу аргументов (выцарапанных из текстбокса) и будет плохо поддерживать дальнейшие изменения (см. выше про изменение интерфейса функции).

Еще раз повторяю, что эта проблема объективна и возникает при любом подходе. Но если нужна высокая устойчивость к изменениям, то хорошо работает простое решение — передача аргументов в виде некоего контейнера свойств. Минусов в том случае, если свойства все равно опциональны (например, Image у textBox'а может быть, а может не быть) практически нет (типобезопасность, к примеру, в таком решении можно легко обеспечить), а устойчивость интерфейса к изменениям получается исключительная.

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

T>Вообще-то имеет. Хорошее решение называется SRP.
T>В твоем примере с textbox'ом можно вынести ответственность по рисованию рамки в отдельную сущность — "рисователь рамки". После чего textBox, а также все, кому надо нарисовать рамку, будут для этого использовать "рисователь рамки".

В общем случае это не помогает. Т.к. заведя, к примеру, рисователь и textLayout, мы через некоторое время обнаруживаем функциональность, которая требует части состояния рисователя и части состояния textLayout'а, и получаем ту же самую проблему.

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

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

T>>Вообще-то имеет. Хорошее решение называется SRP.
T>>В твоем примере с textbox'ом можно вынести ответственность по рисованию рамки в отдельную сущность — "рисователь рамки". После чего textBox, а также все, кому надо нарисовать рамку, будут для этого использовать "рисователь рамки".

U>В общем случае это не помогает.

Вообще-то помогает.

U>Т.к. заведя, к примеру, рисователь и textLayout, мы через некоторое время обнаруживаем функциональность, которая требует части состояния рисователя и части состояния textLayout'а, и получаем ту же самую проблему.

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

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

U>>В общем случае это не помогает.
T>Вообще-то помогает.

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

T>Какую именно функциональность? Давай конкретику, абстрактно тут можно все что угодно доказать, это бессмысленно.

Простой пример:

    public static void CreateTableForObjects(IDataLayer dbConnection)
    {
      ...
    }

Экземпляром какого объекта должна являться эта функция с точки зрения чистого ООП?

Пример посложнее:

    public static void PaintImageWithTextCell(Graphics graphics, Rectangle cellRectangle,
      IGridColumn column, object row, object value)
    {
      ...
    }

Тот же вопрос.

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

N>А с чего Вы решили, что речь идёт о той же программе? Я как раз говорил о возможностях библиотеки. Создаётся объект и к нему в следующей версии вводится ещё один настроечный параметр.

Я решил, что вы ссылаетесь на этот пример:

Более того, в случае организации в стиле ООП такую параметризацию делать легче, потому что можно организовать подобные специфики работы в виде объектов или объектных свойств и потом "прицепить" их к объектам основной работы. В этом плане очень показательна история развития Berkeley DB.
Версия 1: открытие базы делается 5-аргументной функцией dbopen(), 3 из которых — для open(). Дальше через полученный указатель зовутся методы — такое себе ООП с виртуальными методами, хоть и на голом C.
Версия 2: поняли, что этого недостаточно, переименовали функцию в db_open(), добавили аргументов.
Версия 3: поняли, что разных параметров типа размера страницы, методов изоляции, блокировок и т.д. будет больше, чем можно задать в одной функции, и сделали db_create(), после которой надо настроить всё, что надо (включая будущие добавки) и сделать после этого handle->open(). Теперь уже и создание/открытие базы стало делаться в объектном стиле, а не только последующая работа. (Напоминаю, что это C. Есть интерфейс и для C++, хотя он просто инкапсулирует работу с хэндлом.)

И речь идет об одной и той же программе — Berkeley DB. Если неправильно понял, поправляйте. Остальное пока отложу, с вашего позволения.

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

N>>А с чего Вы решили, что речь идёт о той же программе? Я как раз говорил о возможностях библиотеки. Создаётся объект и к нему в следующей версии вводится ещё один настроечный параметр.
SV.>Я решил, что вы ссылаетесь на этот пример:

На этот и на второй — с атрибутами треда в pthreads.

SV.>И речь идет об одной и той же программе — Berkeley DB.

Это не программа. Это именно что библиотека — key-value хранилище нескольких типов организацтт (hash, btree, recno) с произвольными (строка байт) ключом и значением. Она сама ничего не может делать, только предоставляет API.

SV.> Если неправильно понял, поправляйте.

Вот, поправил.

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

T>>Какую именно функциональность? Давай конкретику, абстрактно тут можно все что угодно доказать, это бессмысленно.

U>Простой пример:

U>

U>    public static void CreateTableForObjects(IDataLayer dbConnection)
U>    {
U>      ...
U>    }
U>

U>Экземпляром какого объекта должна являться эта функция с точки зрения чистого ООП?

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

interface IDatabaseCreator
{
    void CreateTableForObjects(IDataLayer dbConnection)
}

U>Пример посложнее:

U>

U>    public static void PaintImageWithTextCell(Graphics graphics, Rectangle cellRectangle,
U>      IGridColumn column, object row, object value)
U>    {
U>      ...
U>    }
U>

U>Тот же вопрос.

Опять таки, все зависит от ответственностей. Я не понимаю, что делает этот метод. Выглядит он как-то странно. Почему колонку он получает, как "IGridColumn", а строку как "object". Что такое row? Что такое value?

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

M>>А кем преподносится? Вас обманули, это устаревшая информация. Я как раз считаю, что виртуальные функции практически всегда — зло! Также зло наследование реализации (а к нему и виртуальные функции приводят). Вместо них как раз делегирование должно использоваться. Т.е. в конструктор объекта передаются реализации виртуальных функций вместо наследования и переопределения функций.

N>И что хорошего это даёт? Вместо того, чтобы переопределить, например, 2 функции, вписывать их 50? А как быть с тем, что кроме функций там ещё есть поля данных, с которыми им надо работать?

Это как минимум заставляет продумать и явно рассмотреть контракты расширения. Также при модификации класса заставляет осторожнее относиться к разделению ответственностей. Грубо говоря, видно, является ли функция "входным параметром" или частью внутренней реализации. Из "protected"-функции ее назначение обычно плохо видно — это утилитный метод для потомков или он все же предназначен для наследования и может быть изменен. Для абстрактных функций такой проблемы нет, но в этом случае все реализации можно передать и через интерфейс. Да и реализовывать их все придется что при наследовании, что в интерфейсе.

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

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

Проблема с 50-ю методами решается статическими утилитными методами (createSomethingBy...) с различными комбинациями аргументов. Там и заполняются "аргументы по умолчанию". Кстати, такие методы дают один существенный бонус — я в дальнейшем смогу отрефакторить большой класс и оставить его фасадом к нескольким меньшим взаимодействующим классам. При этом интерфейс клиентов менять не придется. Маленькие классы будут использовать переданные интерфейсы. При наследовании такой номер не пройдет. На самом деле и без наследования каких-то клиентов менять придется, но изменения будут меньше.

Кроме того, если в классе есть 50 функций, каждую из которых без вреда можно переопределить независимо, проблемы будут в любом случае. Вероятно, в класс слишком много всего намешано. И чтение класса будет подобно ходьбе по минному полю. Везде будут вопросы — могли ли наследники это переопределить и как они могли там нагадить.

Ну и заключение. Я наследованием реализации обычно не занимаюсь (сейчас использую только там, где должны были быть алгебраические типы (варианты)). Все остальное более-менее нормально распиливается на маленькие классы. Ну а если где-то найдется применение классу на 50+ методов, придется думать. Объективная причина за композицию выше — только стабильность интерфейса при изменениях (проще менять большой класс). Уровни абстракций, защищенности от наследников и удобство доступа к состоянию нужно будет смотреть в том конкретном случае. Может, класс с наследованием окажется лучшим решением.

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

U>ООП. А именно создав, к примеру, объект человек мы обнаруживаем, что какой-то функциональности нужны только руки и голова, какой-то кровеносная система и ноги, а какой-то руки, кровеносная система и легкие. Соответственно если эту функциональность мы записываем в виде функций человека, то далее имея состояния рук и головы мы не можем вызвать, к примеру, первую функцию, т.к. состояния человека в целом у нас нет.

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

M>>Кто мешает создавать объекты с "чистыми" функциями?
U>Чистые функции могут быть только у объекта не имеющего состояния. Такой объект обычно бессмысленен (хотя как показывает Qt иногда такой подход возможен и удобен).

А как же замыкание? Замыкание (в момент конструирования объекта) на другие "чистые" функции как раз очень полезно. На данные — действительно менее полезно, хотя тоже может иметь смысл. Что-то в голове крутятся только примеры, где на выходе у объекта всего одна функция. Ну, допустим, пусть будет NubmerFormatter.format(long number) будет. При создании он получает настройки текущей локали и преобразует их в необходимое внутреннее состояние. При форматировании эти данные используются вполне разумным способом.

С изменяемым внутренним состоянием ситуация сложнее. В целом ситуация похожа на "чистые" функции, если бы указатель this передавался явно в чистую функцию.

M>>И как быть в ФП с теми случаями, когда изменяемое состояние нужно? Это практически любые "толстые" клиенты, например.

U>Т.е. если в рамках проведенной декомпозиции сущность за время своей жизни остается одной и той же, то записываем ссылку на эту сущность как readonly, иначе как модифицируемую ссылку.

Ок. С этим согласен. Но из вашего ответа осталось не ясным, что вы делаете со всеми обнаруженными сущностями. Вы их везде явно передаете? Или где-то инкапсулируете в один объект? Если явно передавать, придется таскать много всего. Если собирать в "один объект", у этого объекта появятся "лишние" данные. Как раз здесь и возникают проблемы с декомпозицией состояния. Может быть, в некоторых случаях, и с инкапсуляцией (когда из "сложного" объекта торчит слишком много данных).

M>>public static function Service createService(HEndpoint endpoint);
M>>public static function Service createCachedService(Service service, Cache<HArgs, HResult> cache);
M>>public static function Service countCalls(Service service, Counter function);
M>>public static function Cache<K, V> countCacheHits(Cache<K, V> cache, CacheHitCounter counter);
M>>[/code]
M>>Фактически "те же" монады (каждый экземпляр сервиса — это монада). Только интерфейсы у них меньше и изменять код проще.

U>Это вроде и есть чистые функции. Они уж у тебя на глобальное состояние не замкнуты? Единственное, что меня тут смущает, зачем countCalls и countCacheHits возвращают сервис и кэш? Это тот же самый кэш/сервис переданный в аргументах или новый?

Кэш и сервис новые! Сами функции чистые даже в академическом определении. А вот результат их работы уже достаточно хитрый. Он, во-первых, "замкнут" на значения параметров функции в момент вызова. Т.е. сохраняются ссылки на сервисы и счетчики, например. А в процессе вызова функций из Service могут модифицироваться кэши (для результата createCachedService), состояние обмена с сервером (для результата createService) и т.п. Можно рассматривать это как модификация this и данных, доступных из него, для используемого сервиса.

Если честно, я плохо представляю, как можно сделать так, чтобы эти функции модифицировали только свои аргументы (и при этом возвращали void). Там, напирмер, для countCalls, в сервисе нужно будет хранить количества вызовов. А это как раз лишнее раздувание состояния.

Весь пример как раз и сводится к тому, что есть несколько "необходимых" состояний (кэш, счетчики и т.п.). Это вроде бы "essential complexity" задачи. А вот упаковать ее можно по-разному. В одном случае все эти состояния будут всегда с нами явно. В другом — инкапсулированы на каком-то уровне. И до тех пор, пока на тот уровень не нужно заходить, про те части "сложности" можно не думать. Да, здесь нужно хорошо продумывать контракты методов. Но это не специфично для OOP. Как раз таки при попытке инкапсулирвать данные, в чистом FP получится некоторое подобие OOP. Возможно — с явно везде протаскиваемыми типами (конкретные наследники вместо обобщенного интефрейса). Получится как раз гибридный поход со вполне "ООП-шными" объектами. Фактически, любое замыкание и является объектом.

U>Еще раз повторяю, что эта проблема объективна и возникает при любом подходе.
Полностью согласен! Если принять, что ООП не требует всегда разрешать ее одним и тем же способом, тогда мы получим, что никаких дополнительных сложностей по сравнению с фунциями и прочими видами API у нас нет.

Наверное, стоит различать ООП как некоторые возможности языка (может быть, как раз возможности языка стоит назвать по-другому). И ООД, как методологию написания программ на определенном языке (выделения сущностей и т.п.). Тогда с самим ООП никаких проблем нет. Можно использовать объекты там, где это удобно. Где неудобно — можно не использовать. Во многих случаях запись дизайна в виде "чистых функций" и "ооп-шная запись" будут близнецами. А вот у ООД вполне будут характерные проблемы. В том числе и "лишнее" состояние. Т.е. проблемы возникают не на уровне "функциональный/процедурный/ооп"-код, а выше, на уровне дизайна. Еще обращу внимание, что winapi и прочие упоминавшиеся примеры чистых функцию — это "функциональная" декомпозиция задачи. В виде функций она выражается так, как в API. В ООП это были бы функции, где первый аргумент был бы this. Подчеркиваю, что здесь противопоставляется не ООП vs функции, а ООД vs функциональная декомпозиция. Очень много путаницы возникает как раз из-за неточного и слишком широкого определения ООП. ООД относительно четко определяет методологию и то, что примерно получится в результате. ООП же в самом широком смысле — наличие инкапсуляции/абстракции/полиморфизма. Все это без проблем делается и в "процедурном" стиле, и в функциональном стиле, и в "чисто ООП" стиле с объектами.

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

N>И что хорошего это даёт? Вместо того, чтобы переопределить, например, 2 функции, вписывать их 50? А как быть с тем, что кроме функций там ещё есть поля данных, с которыми им надо работать?

Совсем забыл. Еще такой подход решает проблему комбинаторного взрыва. Если предусмотрено переопределение 50 функций, где-нибудь захочется переопределить какие-то две. В другом месте — другие три. А потом захочется поиметь все вместе. На явном переопределении это делается. При наследовании возникнут большие сложности. Еще хуже будет, если подобных групп несколько.

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

N>>>А с чего Вы решили, что речь идёт о той же программе? Я как раз говорил о возможностях библиотеки. Создаётся объект и к нему в следующей версии вводится ещё один настроечный параметр.
SV.>>Я решил, что вы ссылаетесь на этот пример:

N>На этот и на второй — с атрибутами треда в pthreads.

SV.>>И речь идет об одной и той же программе — Berkeley DB.

N>Это не программа. Это именно что библиотека — key-value хранилище нескольких типов организацтт (hash, btree, recno) с произвольными (строка байт) ключом и значением. Она сама ничего не может делать, только предоставляет API.

SV.>> Если неправильно понял, поправляйте.

N>Вот, поправил.

Если это библиотека, то я совсем запутался. Протокол беседы, как я ее вижу — Я: "переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками". Вы: "Не совсем так", и приводите контр(?)пример — Berkeley DB. Я: вынужденно соглашаюсь и отзываю свой тезис, заменяя его более точным — "переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками ИЛИ мы пишем новую версию программы, не являющейся библиотекой/API, на базе старой". С Berkeley DB я, конечно, не знаком, зато узнав, что понятие реюза несколько шире, чем я думал, я вспомнил известные мне проекты, новые версии которых делались на базе старых, и согласился.

По этому пункту победа за вами, но тут оказывается, что Berkeley DB — как раз-таки библиотека. Что же тогда вы имели в виду, написав "Не совсем так"?

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

SV.>Если это библиотека, то я совсем запутался. Протокол беседы, как я ее вижу — Я: "переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками". Вы: "Не совсем так", и приводите контр(?)пример — Berkeley DB.

Нет. Моё "не совсем так" было возражением не на эти слова, а на "то неважно, ООП это, процедуры, или еще что-то" (в том же абзаце). Я доказываю, что объектное построение — подход, который (по сравнению с обычным процедурным) упрощает использование кода, более того — за счёт поддерживаемых свойств является самым надёжным (в плане долговременных последствий) среди всех альтернативных подходов.

SV.>По этому пункту победа за вами, но тут оказывается, что Berkeley DB — как раз-таки библиотека. Что же тогда вы имели в виду, написав "Не совсем так"?

Повторяю: я возражал против следующего тезиса: (выделен в цитате курсивом)

1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.

Я доказываю, что выбор инфраструктуры реализации тут важен, потому что сам стиль интерфейса, когда свойства, настройки, и т.д. сосредоточены в "объекте" (чем бы он ни был), имеет существенное преимущество тем, что устраняет необходимость "таскать" за собой все необходимые параметры, свойства, уточнения того, что хотим сделать, которые чрезвычайно важны для типичной библиотеки; далее, когда это всё сосредоточено в некотором объекте, структура которого нам не важна, открывается обширное поле для оптимизации его работы. Где-то надо держать временный файл постоянно открытым, где-то — делать сложные вычисления параметров, которые лучше делать только один раз, и так далее. Есть хорошая аналогия — если вы поручаете какое-то постоянное дело подчинённому, то надо давать ему задания и требовать отчёта о выполнении, а не руководить каждым взмахом его руки. (Разумеется, есть и отрицательные стороны — он может сделать что-то не так; и функциональность в объекте может требовать лишнего; но какой подход без недостатков?) Чем сложнее задача, тем важнее логическое её представление в виде отдельных сущностей со своим поведением, и тем вероятнее её выигрыш от объектного подхода.

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

S>То есть вы настаиваете на том, что истинное ООП от неистинного отличает возможность IDE к вываливанию имен методов и построения диаграммы?

Вернемся к началу и попробуем еще раз. Хорошо известное определение:

http://en.wikipedia.org/wiki/Object-oriented_programming

Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Соответствует ли этому определению парадигма MFC? Да, несомненно.

Соответствует ли этому определению парадигма WinAPI? Я считаю, что нет, но другие выражают сомнение: "Это уже объектный подход. Даже если не ООП в полной мере."

Почему нет? Просто по определению. HWND не "data structures consisting of data fields and methods". Откуда же тогда сомнения? Вот откуда: может быть, функции, у которых HWND — первый параметр, мы можем считать за методы?

Так вот, нет, не можем. Машина не может их сгруппировать в общем случае, основываясь только на коде. Не может построить диаграммы отношений. Даже человек, вооруженный знанием, что HWND — не просто указатель, а ручка от окна, не может это сделать однозначно (выбор пера в контекст можно представить двояко — перо использует контекст или наоборот).

S>Не понимаю, что такое "независимая".

Независимая от Микрософта. Я же написал: имелись в виду сценарии, типа, Микрософта, прикручивающего к студии возможность комбинировать функции по HWND.

> Т.е. с одной IDE мы имеем истинный ООП код, а с другой IDE тот же самый код становится "просто объектным" но не истинным?

Слово "истинный" можете игнорировать, оно избыточно. Все, что попадает под определение ООП — ООП, а остальное — нет. Разумеется, использование какой бы то ни было IDE не сделает из ООП-кода не-ООП, или ООП-код из не-ООП. Но IDE можно подкрутить так, что различие станет неочевидным. Поэтому я предложил подкрученные IDE не рассматривать.

SV.>>Можно ввести соглашение, что указатели, чьи typedef'ы начинаются с H — хендлы, но есть гораздо лучшее соглашение: ключевое слово class.
S>А как же языки с динамической типизацией? Пусть в них есть слово class, но там один class от другого отличается не больше чем HWND от указателя. Или истинный ООП несовместим с динамической типизацией?

Для языков с динамической типизацией этот пример (пример того, что следует из неООПности WinAPI!) не работает. И что с того?

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

SV.>Здравствуйте, samius, Вы писали:

S>>То есть вы настаиваете на том, что истинное ООП от неистинного отличает возможность IDE к вываливанию имен методов и построения диаграммы?

SV.>Вернемся к началу и попробуем еще раз. Хорошо известное определение:

SV.>http://en.wikipedia.org/wiki/Object-oriented_programming

SV.>

SV.>Object-oriented programming (OOP) is a programming paradigm using "objects" – data structures consisting of data fields and methods together with their interactions – to design applications and computer programs.

Если мы аппелируем к этому определению и в частности к структуре, содержащей поля и "методы" в их ООП трактовке, то мы вынуждены признать что ООП парадигма может существовать лишь в рамках ООП языков. И то возникают вопросы. Так, оказывается что COM не ООП по причине того что интерфейсы не содержат полей данных.
Однако, фундаментальные концепции ООП не требуют полей и методов.

SV.>Соответствует ли этому определению парадигма MFC? Да, несомненно.
Не очень понятно, что такое парадигма MFC. Подход, в котором выполнено MFC? Да, можно считать что MFC тяготеет к OOP. Но сами по себе структуры с полями и методами не являются достаточным условием принадлежности подхода к ООП.

SV.>Соответствует ли этому определению парадигма WinAPI? Я считаю, что нет, но другие выражают сомнение: "Это уже объектный подход. Даже если не ООП в полной мере."
Несомненно объектный подход, судя по перечню фундаментальных концепций ООП.

SV.>Почему нет? Просто по определению. HWND не "data structures consisting of data fields and methods". Откуда же тогда сомнения? Вот откуда: может быть, функции, у которых HWND — первый параметр, мы можем считать за методы?
За методы — не знаю, но за способ отправить сообщение окну — можем. В фундаментальных концепциях описаны минимальные признаки. Методов, полей и структур в них нет.

SV.>Так вот, нет, не можем. Машина не может их сгруппировать в общем случае, основываясь только на коде. Не может построить диаграммы отношений. Даже человек, вооруженный знанием, что HWND — не просто указатель, а ручка от окна, не может это сделать однозначно (выбор пера в контекст можно представить двояко — перо использует контекст или наоборот).
Вот то чего может машина с кодом в отношении диаграмм отношений — это совершенно не относится к ООП. Просто абсолютно.

S>>Не понимаю, что такое "независимая".

SV.>Независимая от Микрософта. Я же написал: имелись в виду сценарии, типа, Микрософта, прикручивающего к студии возможность комбинировать функции по HWND.
А причем тут микрософт? Еще раз отошлю к фундаментальным концепциям ООП. В них нет ничего о возможностях создания диаграмм, плагинов IDE и прочего.

SV.>Слово "истинный" можете игнорировать, оно избыточно. Все, что попадает под определение ООП — ООП, а остальное — нет. Разумеется, использование какой бы то ни было IDE не сделает из ООП-кода не-ООП, или ООП-код из не-ООП. Но IDE можно подкрутить так, что различие станет неочевидным. Поэтому я предложил подкрученные IDE не рассматривать.
А я предлагаю IDE не рассматривать совершенно.

S>>А как же языки с динамической типизацией? Пусть в них есть слово class, но там один class от другого отличается не больше чем HWND от указателя. Или истинный ООП несовместим с динамической типизацией?

SV.>Для языков с динамической типизацией этот пример (пример того, что следует из неООПности WinAPI!) не работает. И что с того?
Можно конкретнее? Что там не работает?

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

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

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

T>>>Вообще-то имеет. Хорошее решение называется SRP.
T>>>В твоем примере с textbox'ом можно вынести ответственность по рисованию рамки в отдельную сущность — "рисователь рамки". После чего textBox, а также все, кому надо нарисовать рамку, будут для этого использовать "рисователь рамки".

U>>В общем случае это не помогает.

T>Вообще-то помогает.

Еще добавить IoC и получим классическое чистое ФП, натянутое на кривое ООП. Вместо функций у нас объект "делатель" и вместо ФВП — передача кучи делателей через параметры.

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

T>Ответ на этот вопрос зависит от ответственностей, которые покрываются данным методом. Я не знаю, что он делаю, и могу только гадать. Предположим, что во время инсталляции он создает базу данных с таблицами. Тогда можно сделать абстракцию:

T>

T>interface IDatabaseCreator
T>{
T>    void CreateTableForObjects(IDataLayer dbConnection)
T>}
T>

Я могу дать сразу идеальный ответ:

interface ITableCreatorForObjects

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

VE>Еще добавить IoC и получим классическое чистое ФП, натянутое на кривое ООП. Вместо функций у нас объект "делатель" и вместо ФВП — передача кучи делателей через параметры.

Это не функции, а именно объекты (абстракции), в которых может быть состояние и несколько методов. С какого боку тут ФП?

Письмо из будущего. Предположительно из 2021 года.

Почему так получается, что когда код представляет из себя набор метаклассов и метафункций, то такой код очень затруднен для понимания. Точнее трудно понять не столько код, сколько что же это всё вместе генерит и в каком порядке. И это даже при отсутствии злоупотребления препроцессором. С кодом написанным, что называется классически с иерархиями классов, таких проблем нет, и, что характерно, его объём в разы меньше. Я сильно начинаю сомневаться в полезности метапрограммирования. Складывается впечатление, что метапрограммирование это такое хорошо замаскированные современные макросы. И ещё я не понимаю, почему как только люди берутся за проект, то тут же как грибы после дождя начинают появляться метаклассы. На самую простую функциональность количество новых порождённых типов порой приближается к сотни. И почему такая уверенность, что так и надо делать? Как им вдолбить простую истину, высказанную Artifact'ом, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

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

N>И что хорошего это даёт? Вместо того, чтобы переопределить, например, 2 функции, вписывать их 50? А как быть с тем, что кроме функций там ещё есть поля данных, с которыми им надо работать?
1. Если вам нужны "поля данных", с которыми нужно работать — тогда это повод рассмотреть наследование реализации. Но это бывает значительно реже, чем кажется после прочтения овноучебников.
2. Если у вас в оборачиваемом объекте 50 функций, то стоит задуматься о single responsibility principle. Зачем вам такой интерфейс?

Вот пример простого вопроса: http://stackoverflow.com/questions/829568/how-to-know-positionlinenumber-of-a-streamreader-in-a-textfile/
Вот пример идиотского ответа на этот вопрос:

I guess one should inherit from StreamReader, and then add the extra method to the special class along with some properties (_lineLength + _bytesRead)

Обратите внимание на то, как быстро отвечатель утонул в коде.
Вот вариант с делегированием: http://stackoverflow.com/questions/829568/how-to-know-positionlinenumber-of-a-streamreader-in-a-textfile/8876819#8876819
Как видите, этот вариант
1. Значительно короче
2. Действительно работает
3. Работает с любым TextReader, независимо от его реального типа, а не требует наследования непременно от StreamReader.

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

T>Это не функции, а именно объекты (абстракции), в которых может быть состояние и несколько методов. С какого боку тут ФП?

Рисователь рамки-то?

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

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

T>>Это не функции, а именно объекты (абстракции), в которых может быть состояние и несколько методов. С какого боку тут ФП?

VE>Рисователь рамки-то?

— Даже если в одном месте будет реализация интерфейса с одним методом и без состояния, это сразу делает всю программу функциональной?
— Если сейчас в интерфейсе один метод и в реализации нет состояния, это еще не значит, что в будущем ничего не изменится. ООП в данном случае предоставит удобную возможность расширения функционала.
— Кроме рисователя рамок задач больше нет?
— "рисователь рамки" — это не просто сигнатура функции, это абстракция, которая олицетворяет собой некоторую ответственность. Вводится разделение между названием абстракции и названием конкретной реализации этой абстракции. С таким кодом проще работать. Например, IDE может по нажатию клавиши предоставить список всех реализаций заданного интерфейса и мне просто надо выбрать из предложенного.

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

S>Если мы аппелируем к этому определению и в частности к структуре, содержащей поля и "методы" в их ООП трактовке, то мы вынуждены признать что ООП парадигма может существовать лишь в рамках ООП языков. И то возникают вопросы. Так, оказывается что COM не ООП по причине того что интерфейсы не содержат полей данных.

Я не очень понимаю, что такое "ап(п)еллировать к определению". Вы хотите сказать "если мы его примем"? А что, есть основания не принимать?

Утверждение "мы вынуждены признать что ООП парадигма может существовать лишь в рамках ООП языков" таким основанием не является по причине неверности. Есть грязные хаки, которые позволяют работать с объектами на языках типа C. Например, такова технология COM. Объекты от этого не перестают быть объектами, поскольку описаны в явном виде в библиотеке типов, которая считается неотъемлемой частью кода. Все методы и все свойства каждого объекта, исчерпывающе и неизбыточно. К WinAPI, напомню, ничего подобного не прилагается.

Отсюда и все остальное. Зачем переусложнять? Наличие объектов — то есть, полей и методов, объединенных в одно целое — которые взаимодействуют между собой — необходимое и единственное условие ООП.

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

VE>>Рисователь рамки-то?

T>- Даже если в одном месте будет реализация интерфейса с одним методом и без состояния, это сразу делает всю программу функциональной?
T>- Если сейчас в интерфейсе один метод и в реализации нет состояния, это еще не значит, что в будущем ничего не изменится. ООП в данном случае предоставит удобную возможность расширения функционала.
T>- Кроме рисователя рамок задач больше нет?
T>- "рисователь рамки" — это не просто сигнатура функции, это абстракция, которая олицетворяет собой некоторую ответственность. Вводится разделение между названием абстракции и названием конкретной реализации этой абстракции. С таким кодом проще работать. Например, IDE может по нажатию клавиши предоставить список всех реализаций заданного интерфейса и мне просто надо выбрать из предложенного.

Я вам про фому, а вы мне про ерёму. Я вроде процитировал фразу, на которую отвечал, чо с темы-то съезжать?

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

T>- Даже если в одном месте будет реализация интерфейса с одним методом и без состояния, это сразу делает всю программу функциональной?
Нет, но это шаг в нужную сторону.
T>- Если сейчас в интерфейсе один метод и в реализации нет состояния, это еще не значит, что в будущем ничего не изменится. ООП в данном случае предоставит удобную возможность расширения функционала.
1. Изменение количества методов в ФП достигается очень просто. Нужно два метода — делаем "структуру" из f1() и f2().
2. А вот если рисователю рамок потребуется состояние, то это очень крутая смена сигнатуры у функции "рисуйРамку". У этого решения есть крайне тяжёлые последствия — например, теперь мы не можем быть уверены, что перестановка порядка рисования рамок останется корректной.

T>- "рисователь рамки" — это не просто сигнатура функции, это абстракция, которая олицетворяет собой некоторую ответственность. Вводится разделение между названием абстракции и названием конкретной реализации этой абстракции. С таким кодом проще работать. Например, IDE может по нажатию клавиши предоставить список всех реализаций заданного интерфейса и мне просто надо выбрать из предложенного.
А зачем смешивать IDE и семантику языка? Описанное преимущество — это заслуга статической типизации. Если она же есть в ФП, то теоретически ничто не мешает мне "по нажатию клавиши" получить список всех функций с заданной сигнатурой.

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

SV.>Утверждение "мы вынуждены признать что ООП парадигма может существовать лишь в рамках ООП языков" таким основанием не является по причине неверности. Есть грязные хаки, которые позволяют работать с объектами на языках типа C. Например, такова технология COM. Объекты от этого не перестают быть объектами, поскольку описаны в явном виде в библиотеке типов, которая считается неотъемлемой частью кода. Все методы и все свойства каждого объекта, исчерпывающе и неизбыточно. К WinAPI, напомню, ничего подобного не прилагается.

SV.>Отсюда и все остальное. Зачем переусложнять? Наличие объектов — то есть, полей и методов, объединенных в одно целое — которые взаимодействуют между собой — необходимое и единственное условие ООП.
Никаких полей в COM нет. Посмотрите повнимательнее в IDL — там только методы.
Переусложнением на самом деле является вот эта "вывернутая наизнанку" трактовка ООП, где к данным начинают приделывать методы.

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

S>2. А вот если ~~сменил тип переменной~~рисователю рамок потребуется состояние, то это очень крутая смена сигнатуры у функции "рисуйРамку". У этого решения есть крайне тяжёлые последствия — например, теперь мы не можем быть уверены, что перестановка порядка рисования рамок останется корректной.

Поэтому компилятор тыкнет в места, где это надо исправить. И именно поэтому чистое ФП и рулит.
Добавил зависимость от порядка, изволь указать.
А то добавил состояние, теперь переставлять нельзя, а код молча компилируется, но не работает.

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

S>Никаких полей в COM нет. Посмотрите повнимательнее в IDL — там только методы.

IDL — Interface Definition Language, а не Programming Language. Этот язык описывает интерфейс, ООП-маску, которую можно натянуть на что угодно, в том числе на абсолютно не-ООП язык, типа C. Как я понимаю, это и была одна из задач COM'а — создать объектно-ориентированный общий знаменатель самых разных языков. Поэтому, "метод" в IDL может на языке имплементации быть вовсе не методом, а самой обычной глобальной функцией. "Поле" — не полем, а значением в памяти по адресу или на диске в каком-то секторе. Получается этакий виртуальный ООП (не в дебильном новорусском смысле "то, чего не может быть", а в исходном английском — "the quality of having the attributes of something without sharing its (real or imagined) physical form"). И в этом виртуальном ООП'е, описанном на IDL'е, поля, конечно же, есть. С одной стороны, синтаксис их объявления очень похож на синтаксис объявления методов, но нас, компьютерных инженеров, эта похожесть не должна вводить в заблуждение. С другой стороны, он допускает несколько отдельных записей (очень похожих на методы!) на одно поле. В чистом итоге, вы абсолютно однозначно можете отделить метод от поля, а, кроме того, можете написать для этого очень простую программу.

В реальности, конечно, создатели COM'а все сделали для того, чтобы вы виртуальные "поля" реализовывали через методы ООП-языков (в первую очередь — C++), отсюда и синтаксис, но это, извините, не обязательно.

S>Переусложнением на самом деле является вот эта "вывернутая наизнанку" трактовка ООП, где к данным начинают приделывать методы.

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

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

VE>>>Рисователь рамки-то?

T>>- Даже если в одном месте будет реализация интерфейса с одним методом и без состояния, это сразу делает всю программу функциональной?
T>>- Если сейчас в интерфейсе один метод и в реализации нет состояния, это еще не значит, что в будущем ничего не изменится. ООП в данном случае предоставит удобную возможность расширения функционала.
T>>- Кроме рисователя рамок задач больше нет?
T>>- "рисователь рамки" — это не просто сигнатура функции, это абстракция, которая олицетворяет собой некоторую ответственность. Вводится разделение между названием абстракции и названием конкретной реализации этой абстракции. С таким кодом проще работать. Например, IDE может по нажатию клавиши предоставить список всех реализаций заданного интерфейса и мне просто надо выбрать из предложенного.

VE>Я вам про фому, а вы мне про ерёму. Я вроде процитировал фразу, на которую отвечал, чо с темы-то съезжать?

А почему ты решил, что я съехал с темы?

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

T>>- Даже если в одном месте будет реализация интерфейса с одним методом и без состояния, это сразу делает всю программу функциональной?
S>Нет, но это шаг в нужную сторону.

T>>- Если сейчас в интерфейсе один метод и в реализации нет состояния, это еще не значит, что в будущем ничего не изменится. ООП в данном случае предоставит удобную возможность расширения функционала.
S>1. Изменение количества методов в ФП достигается очень просто. Нужно два метода — делаем "структуру" из f1() и f2().

"структура" из f1() и f2() — это тоже шаг в сторону ООП. Чем такая структура принципиально отличается от объекта?

S>2. А вот если рисователю рамок потребуется состояние, то это очень крутая смена сигнатуры у функции "рисуйРамку". У этого решения есть крайне тяжёлые последствия — например, теперь мы не можем быть уверены, что перестановка порядка рисования рамок останется корректной.
Мы и раньше не были в этом уверены, так как операция "нарисовать рамку" по определению имеет побочные эффекты.

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

А почему нет?

S>Описанное преимущество — это заслуга статической типизации.

Не только.

S>Если она же есть в ФП, то теоретически ничто не мешает мне "по нажатию клавиши" получить список всех функций с заданной сигнатурой.

Какая мне польза от тысяч функций с сигнатурой "void f()", когда я ищу, например, реализацию ITransaction, членом которого (интерфейса) является "void Rollback()"?

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

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

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

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

VE>>Поэтому компилятор тыкнет в места, где это надо исправить. И именно поэтому чистое ФП и рулит.
T>А ты про какое такое чистое ФП говоришь? А то в этой теме уже было несколько их трактовок

http://lmgtfy.com/?q=Pure+functional+programming

Первые две можно почитать. Не стоит собеседника с ходу подозревать в чём-то, даже если ты уже свой максимум этики уже спустил на других.

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

T>"структура" из f1() и f2() — это тоже шаг в сторону ООП. Чем такая структура принципиально отличается от объекта?

А чем она вообще на него похожа, кроме того, что это кортеж двух чистых функции?
Может, State? Identity?

S>>Если она же есть в ФП, то теоретически ничто не мешает мне "по нажатию клавиши" получить список всех функций с заданной сигнатурой.

T>Какая мне польза от тысяч функций с сигнатурой "void f()", когда я ищу, например, реализацию ITransaction, членом которого (интерфейса) является "void Rollback()"?

А вы напишите "transaction |>" и IDE будет знать первый аргумент. Это лишь вопрос синтаксиса. А заслуга всё-таки статической типизации. "Чего вы тень на плетень наводите?"

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

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

T>>"структура" из f1() и f2() — это тоже шаг в сторону ООП. Чем такая структура принципиально отличается от объекта?

VE>А чем она вообще на него похожа, кроме того, что это кортеж двух чистых функции?
VE>Может, State?

Да, state. Набор функций и их замыкания являются состоянием.

VE>Identity?

Я не понимаю, почему identity является чем-то, характеризующим ООП. Если мы туда добавим "bool Equals()", это сразу все поменяет?

S>>>Если она же есть в ФП, то теоретически ничто не мешает мне "по нажатию клавиши" получить список всех функций с заданной сигнатурой.

T>>Какая мне польза от тысяч функций с сигнатурой "void f()", когда я ищу, например, реализацию ITransaction, членом которого (интерфейса) является "void Rollback()"?

VE>А вы напишите "transaction |>" и IDE будет знать первый аргумент. Это лишь вопрос синтаксиса. А заслуга всё-таки статической типизации. "Чего вы тень на плетень наводите?"

И получу в общем списке "commit(transaction)", "log(transaction)", "createTables(transaction)", "backupDatabase(transaction)" и еще 100500 нерелевантных вариантов.

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

SV.>Здравствуйте, samius, Вы писали:

S>>Если мы аппелируем к этому определению и в частности к структуре, содержащей поля и "методы" в их ООП трактовке, то мы вынуждены признать что ООП парадигма может существовать лишь в рамках ООП языков. И то возникают вопросы. Так, оказывается что COM не ООП по причине того что интерфейсы не содержат полей данных.

SV.>Я не очень понимаю, что такое "ап(п)еллировать к определению". Вы хотите сказать "если мы его примем"? А что, есть основания не принимать?
Да, каюсь. Слово вспомнилось, а как пишется и используется не освежил. Мне стыдно.

По поводу оснований не принимать такое определение: ИМХО, это не определение, а пояснение. Что-то вроде "коромысло — это то чем носят воду". Что бы определять, уместно ли говорить об ООП в конкретном коде/технологии, нужно смотреть на присутствие фундаментальных концепций ООП. Ссылку я давал в предыдущем посте (на той же странице википедии, откуда вы взяли "определение"), вы ее проигнорировали.

SV.>Утверждение "мы вынуждены признать что ООП парадигма может существовать лишь в рамках ООП языков" таким основанием не является по причине неверности.
Это мое утверждение. Это я утверждаю что если судить о наличии ООП по полям и методам, то мы придем к тому что ООП взможно лишь в языках с поддержкой ООП, что не верно.
SV.>Есть грязные хаки, которые позволяют работать с объектами на языках типа C.
Ничего грязного в них не вижу.
SV.> Например, такова технология COM.
Согласно "определению" о полях и методах COM не является объектной по причине отсутствия полей. Я читал ответ Синклеру, то что вы называете полями в виртуальном ООП, полями не является.
Предлагаю не продолжать тему COM, вместо этого отклонить определение о полях и методах.

SV.>Объекты от этого не перестают быть объектами, поскольку описаны в явном виде в библиотеке типов, которая считается неотъемлемой частью кода. Все методы и все свойства каждого объекта, исчерпывающе и неизбыточно. К WinAPI, напомню, ничего подобного не прилагается.
Библиотека типов не является неотъемлемой частью кода. Она опциональна.
А к ВинАПИ прилагается документация, книги, заголовки.

SV.>Отсюда и все остальное. Зачем переусложнять? Наличие объектов — то есть, полей и методов, объединенных в одно целое — которые взаимодействуют между собой — необходимое и единственное условие ООП.
Это вы переусложняете полями. Поля и методы не являются чем-то необходимым для ООП. Объект может хранить свое состояние в файле, облаке, или за кулисами HWND.

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

VE>http://lmgtfy.com/?q=Pure+functional+programming

VE>Первые две можно почитать. Не стоит собеседника с ходу подозревать в чём-то, даже если ты уже свой максимум этики уже спустил на других.

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

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

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

VE>>А чем она вообще на него похожа, кроме того, что это кортеж двух чистых функции?
VE>>Может, State?

T>Да, state. Набор функций и их замыкания являются состоянием.

VE>>Identity?

T>Я не понимаю, почему identity является чем-то, характеризующим ООП. Если мы туда добавим "bool Equals()", это сразу все поменяет?

Началось!

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

T>Да, state. Набор функций и их замыкания являются состоянием.

И как мы это состояние можем поменять?

VE>>Identity?

T>Я не понимаю, почему identity является чем-то, характеризующим ООП. Если мы туда добавим "bool Equals()", это сразу все поменяет?

Ну добавь в ФП такое equals, вперёд.

VE>>А вы напишите "transaction |>" и IDE будет знать первый аргумент. Это лишь вопрос синтаксиса. А заслуга всё-таки статической типизации. "Чего вы тень на плетень наводите?"

T>И получу в общем списке "commit(transaction)", "log(transaction)", "createTables(transaction)", "backupDatabase(transaction)" и еще 100500 нерелевантных вариантов.

Ну сделай data This a = This a. и пиши This transaction |>
Тоже мне, бином Ньютона.

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

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

VE>>http://lmgtfy.com/?q=Pure+functional+programming

VE>>Первые две можно почитать. Не стоит собеседника с ходу подозревать в чём-то, даже если ты уже свой максимум этики уже спустил на других.

T>Вместо того, чтобы ехидничать не по делу, лучше бы ветку почитал и понял, о чем шел разговор. Было обсуждение с Undying его собственной трактовки ФП, отличающейся от общепринятой, когда ты влез в середину разговора.

Сам бы почитал.
Процитирую:
[quote]Поэтому компилятор тыкнет в места, где это надо исправить. И именно поэтому чистое ФП и рулит.[/quote]

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

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

AM>В последнее время замечаю что, чем на большее число элементов(функций, интерфейсов) разбита логика, тем легче писать юнит тесты. То есть разбивать (если есть время и желание) нужно хотя бы для целей тестирования.
По-моему, это настолько мощное премущество композиции, что... ну вы поняли. Да хотя бы ради читабильного call-stack при ошибках...

Здравствуйте, SV., Вы писали:
SV.>IDL — Interface Definition Language, а не Programming Language.
Ну, так в COM ничего другого и нет.

SV.>И в этом виртуальном ООП'е, описанном на IDL'е, поля, конечно же, есть.
Не вижу никаких таких полей в ООПе, описанном на IDL. Может, я чего-то простого не замечаю?
SV.>В реальности, конечно, создатели COM'а все сделали для того, чтобы вы виртуальные "поля" реализовывали через методы ООП-языков (в первую очередь — C++), отсюда и синтаксис, но это, извините, не обязательно.
Вы, похоже, придумываете неортодоксальную трактовку property. Я вас разочарую — никаким "полем" эта штука не является. Это всего лишь удобный способ записи к тому, что издали выглядит как состояние. На самом деле, это такой способ записи контракта на поведение. Полей там по-прежнему нет.

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

T>"структура" из f1() и f2() — это тоже шаг в сторону ООП. Чем такая структура принципиально отличается от объекта?
Ну, начинается.
Принципиально эта структура отличается иммутабельностью, благодаря которой мы можем иметь повышенную понятность. Ибо все зависимости по состоянию придётся обозначать в явном виде.
Понятно, что можно эмулировать недо-ФП на ООП (см. тж. "функторы" или, скажем, замыкания из C#), и можно эмулировать недо-ООП на ФП.

T>Мы и раньше не были в этом уверены, так как операция "нарисовать рамку" по определению имеет побочные эффекты.
Ну-ну-ну. Откуда же вдруг взялись побочные эффекты для самого рисователя? Побочные эффекты в рисователе рамки были у нас сведены к канвасу, по которому он рисует. А в самом рисователе состояние — это всего лишь результат творческого применения конструкторов.
То есть, жизненный цикл рисователя таков:
1. Конфигурируем рисователь. Это может быть оформлено как один шаг — вызов new, или как последовательность шагов — вызовы SetBorderWidth, SetBorderColor, и т.д. Важно нам вот что: в результате всех этих манипуляций мы получаем 1 (одну) функцию, которая отображает канвас до рисования в канвас после рисования.
2. Собственно, рисуем: скармливаем в эту функцию канвас и, скажем, параметры конкретной рамки, т.е. структуру Rect.
3. Всё. На этом шаге у нас рисователь никак не изменяется, и гарантированно ничего, кроме канваса, не меняет.

T>А почему нет?
Потому что мухи — отдельно, котлеты — отдельно. Вы ещё скажите, что ООП лучше потому, что в нём есть раскраска синтаксиса.

S>>Описанное преимущество — это заслуга статической типизации.
T>Не только.
Только.
S>>Если она же есть в ФП, то теоретически ничто не мешает мне "по нажатию клавиши" получить список всех функций с заданной сигнатурой.
T>Какая мне польза от тысяч функций с сигнатурой "void f()", когда я ищу, например, реализацию ITransaction, членом которого (интерфейса) является "void Rollback()"?
В огороде бузина, в киеве — дядька. В ФП у вас не будет ни ITransaction, ни его реализации, чтобы её поискать. Вы будете искать другие вещи — и будете их успешно находить. Какие проблемы-то?

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

SV.>>В реальности, конечно, создатели COM'а все сделали для того, чтобы вы виртуальные "поля" реализовывали через методы ООП-языков (в первую очередь — C++), отсюда и синтаксис, но это, извините, не обязательно.
S>Вы, похоже, придумываете неортодоксальную трактовку property. Я вас разочарую — никаким "полем" эта штука не является. Это всего лишь удобный способ записи к тому, что издали выглядит как состояние. На самом деле, это такой способ записи контракта на поведение. Полей там по-прежнему нет.

Трактовки самые что ни на есть ортодоксальные. Другие из Wikipedia удаляют, потому и цитирую:

http://en.wikipedia.org/wiki/Property_%28programming%29

A property, in some object-oriented programming languages, is a special sort of class member, intermediate between a field (or data member) and a method. Properties are read and written like fields, but property reads and writes are (usually) translated to get and set method calls. The field-like syntax is said to be easier to read and write than lots of method calls, yet the interposition of method calls allows for data validation, active updating (as of GUI visuals), or read-only 'fields'. That is, properties are intermediate between member code (methods) and member data (instance variables) of the class, and properties provide a higher level of encapsulation than public fields.

http://en.wikipedia.org/wiki/Virtuality_%28disambiguation%29

Virtuality is the quality of having the attributes of something without sharing its (real or imagined) physical form.

Силлогизм такой. 1. Свойство должно выглядеть как поле (the field-like syntax is said to be easier to read and write than lots of method calls), но не быть им. 2. Когда что-то имеет характеристики чего-то другого (выглядит как что-то другое), но не является им физически, это называется виртуальностью. В. Свойство — виртуальное поле. Будете спорить?

Про "издали". Я не настолько хорошо знаю COM, но, по-моему, даже в нем это "издали" можно сильно приблизить. Как VB6-программисту отличить в чужом объекте свойство от поля? Судя по тому, как часто люди задают этот вопрос, в упор не видят. Хорошо виртуализировано, значит.

Теперь вернемся к IDL'ю. Я попытался обратить ваше внимание на то, что это вообще не язык программирования, а язык описания интерфейса. Он и придуман-то специально для описания того, как модуль должен выглядеть, а не быть (реализованным). Глядя в IDL какого-нибудь модуля, вы не знаете даже, есть ли в этом модуле методы на уровне языка программирования, не говоря уж про поля. О каком "разочаровании" может идти речь? Такая виртуализация делает честь этой технологии, а не разочаровывает пользователей.

Если мы закончили с IDL'ем, предлагаю перейти к полям в языках программирования. Судя по реплике про "вывернутую наизнанку" ортодоксальную трактовку ООП, вы с ней несогласны. Хотелось бы послушать.

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

SV.>>Я не очень понимаю, что такое "ап(п)еллировать к определению". Вы хотите сказать "если мы его примем"? А что, есть основания не принимать?
S>Да, каюсь. Слово вспомнилось, а как пишется и используется не освежил. Мне стыдно.

По-моему, вы поспешили с устыжением. Я не имел в виду наехать, а просто не понял (без фиги в кармане).

Как пишется. Я вот вообще не уверен, что общепринятое русское написание этого слова корректно. Как мне объяснили, в словах латинского происхождения согласная в приставке после "а" должна удваиваться, если мы не хотим путать такие слова со словами греческого происхождения, где "а" — отрицательный префикс. Типа, атеист — антитеист, а аккумулятор — накопитель, а не антинакопитель. По этому правилу, "аффилиированный" и "аппелировать" должны писаться с двумя "ф" и "п" соответственно. У нас их пишут не так. Видимо, хотят путать, или, по крайней мере, не создают препятствий к путанице. Короче говоря, я бы не стал стыдиться написания "аппелировать". Откуда там должно быть две "п" как раз понятно, а откуда две "л" — нет. Потому и написал со скобками.

Как используется. "Ап(п)ел(л)ировать к определению" в самом деле используется, но что это значит? Калька "обратимся к определению"? Тоже неглупо, вроде бы. Я лишь уточнил.

К счастью, все это не имеет отношения к ООП. Если модераторам не лень, они могут (?) сдублировать этот постинг в более подходящий форум.

S>По поводу оснований не принимать такое определение: ИМХО, это не определение, а пояснение. Что-то вроде "коромысло — это то чем носят воду". Что бы определять, уместно ли говорить об ООП в конкретном коде/технологии, нужно смотреть на присутствие фундаментальных концепций ООП. Ссылку я давал в предыдущем посте (на той же странице википедии, откуда вы взяли "определение"), вы ее проигнорировали.

"То чем носят воду" — определение коромысла, но неполное. Воду и в клюве носят, но клюв — не коромысло. Если уточнить "...состоящее из двух крюков для подвешивания ведер и перекладины для наплечного ношения", будет полное.

Определение ООП, приведенное в Википедии и процитированное мною — и определение, и полное. Проверим.

1. Определение — предикат, формула, в которую можно подставить что угодно (хоть бы и коромысло) и посмотреть, подходит ли это что угодно. Википедийная формула является таким предикатом, чисто по форме? Да, нет?
2. Если да, то полное ли оно? Можете вы привести пример чего-то, что укладывается в эту формулу, но не является ООП, как клюв в примере с определением коромысла?

Что касается концепций, это же не толковый словарь, а энциклопедия. Дав определение, авторы рассматривают концепции, почему нет?

S>Согласно "определению" о полях и методах COM не является объектной по причине отсутствия полей. Я читал ответ Синклеру, то что вы называете полями в виртуальном ООП, полями не является.
S>Предлагаю не продолжать тему COM, вместо этого отклонить определение о полях и методах.

COM, как следует из названия, объектная модель компонентов (модулей). В свою очередь, модель — что угодно, используемое для представления чего угодно другого (я не шучу, http://en.wikipedia.org/wiki/Conceptual_model: In the most general sense, a model is anything used in any way to represent anything else.) Чисто из названия получается, что мы берем компонент, который, может быть, внутри даже не объектный, но представляем его как объектный.

С моей точки зрения, при этом поля появляются аж дважды: как настоящие поля и как свойства (нечто, что должно выглядеть как поля). В разговоре с Синклером дискуссия пошла по второму, более сложному, направлению. Нам с вами можно ограничиться первым. Вот те данные, которые инкапусированы в COM-объекты, и будут полями. Настоящими, без всякой виртуальности.

SV.>>Объекты от этого не перестают быть объектами, поскольку описаны в явном виде в библиотеке типов, которая считается неотъемлемой частью кода. Все методы и все свойства каждого объекта, исчерпывающе и неизбыточно. К WinAPI, напомню, ничего подобного не прилагается.
S>Библиотека типов не является неотъемлемой частью кода. Она опциональна.
S>А к ВинАПИ прилагается документация, книги, заголовки.

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

Черт с ней, с машиной — я как человек человека вас спрошу: кто кого использует, контекст перо, или перо контекст?

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

SV.>>Если это библиотека, то я совсем запутался. Протокол беседы, как я ее вижу — Я: "переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками". Вы: "Не совсем так", и приводите контр(?)пример — Berkeley DB.

N>Нет. Моё "не совсем так" было возражением не на эти слова, а на "то неважно, ООП это, процедуры, или еще что-то" (в том же абзаце). Я доказываю, что объектное построение — подход, который (по сравнению с обычным процедурным) упрощает использование кода, более того — за счёт поддерживаемых свойств является самым надёжным (в плане долговременных последствий) среди всех альтернативных подходов.

SV.>>По этому пункту победа за вами, но тут оказывается, что Berkeley DB — как раз-таки библиотека. Что же тогда вы имели в виду, написав "Не совсем так"?

N>Повторяю: я возражал против следующего тезиса: (выделен в цитате курсивом)

N>

1. Переиспользование кода становится возможным тогда, когда это библиотека/API, которая изначально задумывалась как библиотека/API и делалась прямыми руками. Если это так, то неважно, ООП это, процедуры, или еще что-то. Грамотный ООПщик легко обернет не-ОО библиотеку/API в свои классы.

N>Я доказываю, что выбор инфраструктуры реализации тут важен, потому что сам стиль интерфейса, когда свойства, настройки, и т.д. сосредоточены в "объекте" (чем бы он ни был), имеет существенное преимущество тем, что устраняет необходимость "таскать" за собой все необходимые параметры, свойства, уточнения того, что хотим сделать, которые чрезвычайно важны для типичной библиотеки; далее, когда это всё сосредоточено в некотором объекте, структура которого нам не важна, открывается обширное поле для оптимизации его работы. Где-то надо держать временный файл постоянно открытым, где-то — делать сложные вычисления параметров, которые лучше делать только один раз, и так далее. Есть хорошая аналогия — если вы поручаете какое-то постоянное дело подчинённому, то надо давать ему задания и требовать отчёта о выполнении, а не руководить каждым взмахом его руки. (Разумеется, есть и отрицательные стороны — он может сделать что-то не так; и функциональность в объекте может требовать лишнего; но какой подход без недостатков?) Чем сложнее задача, тем важнее логическое её представление в виде отдельных сущностей со своим поведением, и тем вероятнее её выигрыш от объектного подхода.

Теперь понял.

"Если это так" включало в себя "задумывалась как библиотека/API". Последнее же неявно предполагало, что интерфейс уже продуман, и его не придется менять. Ну, в крайнем случае, сделать одну обратно-совместимую major-ревизию с Ex-методами. Знаете шутку про функцию вычисления факториала на WinAPI с lpReserved? Это оно.

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

SV.>Здравствуйте, samius, Вы писали:

S>>Да, каюсь. Слово вспомнилось, а как пишется и используется не освежил. Мне стыдно.

SV.>По-моему, вы поспешили с устыжением. Я не имел в виду наехать, а просто не понял (без фиги в кармане).
Дело собственно в том, что я в этой ветке тем и занимался что пристыживал по поводу употребления терминов не в их общеупотребимом смысле. Потому и не грех самому устыдиться.

SV.>Как пишется. Я вот вообще не уверен, что общепринятое русское написание этого слова корректно. Как мне объяснили, в словах латинского происхождения согласная в приставке после "а" должна удваиваться, если мы не хотим путать такие слова со словами греческого происхождения, где "а" — отрицательный префикс. Типа, атеист — антитеист, а аккумулятор — накопитель, а не антинакопитель. По этому правилу, "аффилиированный" и "аппелировать" должны писаться с двумя "ф" и "п" соответственно. У нас их пишут не так. Видимо, хотят путать, или, по крайней мере, не создают препятствий к путанице. Короче говоря, я бы не стал стыдиться написания "аппелировать". Откуда там должно быть две "п" как раз понятно, а откуда две "л" — нет. Потому и написал со скобками.
Очень интересно про букву "а" и удваивание согласной. Не знал.

SV.>Как используется. "Ап(п)ел(л)ировать к определению" в самом деле используется, но что это значит? Калька "обратимся к определению"? Тоже неглупо, вроде бы. Я лишь уточнил.
Вот здесь второе толкование сверху (в смысле ссылаться).

S>>По поводу оснований не принимать такое определение: ИМХО, это не определение, а пояснение. Что-то вроде "коромысло — это то чем носят воду". Что бы определять, уместно ли говорить об ООП в конкретном коде/технологии, нужно смотреть на присутствие фундаментальных концепций ООП. Ссылку я давал в предыдущем посте (на той же странице википедии, откуда вы взяли "определение"), вы ее проигнорировали.

SV.>"То чем носят воду" — определение коромысла, но неполное. Воду и в клюве носят, но клюв — не коромысло. Если уточнить "...состоящее из двух крюков для подвешивания ведер и перекладины для наплечного ношения", будет полное.
Вот так же структура и методы работы с ней не являются еще ООП. Причем, наоборот, есть примеры ООП где нет структуры и методов, либо они не связаны между собой отношением "together".

SV.>Определение ООП, приведенное в Википедии и процитированное мною — и определение, и полное. Проверим.

SV.>1. Определение — предикат, формула, в которую можно подставить что угодно (хоть бы и коромысло) и посмотреть, подходит ли это что угодно. Википедийная формула является таким предикатом, чисто по форме? Да, нет?
Нет.
SV.>2. Если да, то полное ли оно? Можете вы привести пример чего-то, что укладывается в эту формулу, но не является ООП, как клюв в примере с определением коромысла?

struct CurrentLocation
{
   static int x = 0;
   static int y = 0;
   static bool IsEqual(int x1, int y1) { return x == x1 && y == y1; };
};

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

SV.>Что касается концепций, это же не толковый словарь, а энциклопедия. Дав определение, авторы рассматривают концепции, почему нет?
Рассмотренные концепции не имеют отношения к примеру, который я привел. Из этого можно сделать вывод, что либо определение не точное, либо концепции имеют слабое отношение к определению. Я склоняюсь к первому.

SV.>COM, как следует из названия, объектная модель компонентов (модулей). В свою очередь, модель — что угодно, используемое для представления чего угодно другого (я не шучу, http://en.wikipedia.org/wiki/Conceptual_model: In the most general sense, a model is anything used in any way to represent anything else.) Чисто из названия получается, что мы берем компонент, который, может быть, внутри даже не объектный, но представляем его как объектный.
Уточню, что COM это прежде всего инструмент для представления чего угодно в объектную модель. Но само по себе использование COM не гарантирует объектность того что мы оборачиваем в COM, даже через призму COM.

SV.>С моей точки зрения, при этом поля появляются аж дважды: как настоящие поля и как свойства (нечто, что должно выглядеть как поля). В разговоре с Синклером дискуссия пошла по второму, более сложному, направлению. Нам с вами можно ограничиться первым. Вот те данные, которые инкапусированы в COM-объекты, и будут полями. Настоящими, без всякой виртуальности.
Можем взять определение поля в ООП и показать что COM может инкапсулировать данные, хранящиеся совершенно другим способом, или даже вычислимые.

S>>Библиотека типов не является неотъемлемой частью кода. Она опциональна.
S>>А к ВинАПИ прилагается документация, книги, заголовки.

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

SV.>Черт с ней, с машиной — я как человек человека вас спрошу: кто кого использует, контекст перо, или перо контекст?
Имхо, и перо и контекст пассивны. Когда я зашруровываю ботинки, считается ли что шнурки используют ботинки? А если чай мешаю ложкой, то использует ли ложка чай?

Если серьезнее, то типично контекст инкапсулирует элементарные операции с ним. Перо по отношению к этим операциям является таким же атрибутом, как координаты в context.MoveTo(x,y). Но вот однозначности это не добавляет в отношении того, кто кого использует. Мы можем смотреть на это как на DrawLine(dc,...), так и на dc.DrawLine(...). В ООП языках принята вторая запись, а суть от этого не меняется.

S>Понятно, что можно эмулировать недо-ФП на ООП (см. тж. "функторы" или, скажем, замыкания из C#), и можно эмулировать недо-ООП на ФП.

что значить "недо"? принципиально нельзя что-то сэмулировать полностью, или требуются нелокальные преобразования, или... ?

Здравствуйте, m e, Вы писали:
ME>что значить "недо"? принципиально нельзя что-то сэмулировать полностью, или требуются нелокальные преобразования, или... ?
Значит у вас а) не будет поддержки компилятора, и б) код будет получаться излишне многословным.

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

SV.>>1. Определение — предикат, формула, в которую можно подставить что угодно (хоть бы и коромысло) и посмотреть, подходит ли это что угодно. Википедийная формула является таким предикатом, чисто по форме? Да, нет?
S>Нет.
SV.>>2. Если да, то полное ли оно? Можете вы привести пример чего-то, что укладывается в эту формулу, но не является ООП, как клюв в примере с определением коромысла?
S>

S>struct CurrentLocation
S>{
S>   static int x = 0;
S>   static int y = 0;
S>   static bool IsEqual(int x1, int y1) { return x == x1 && y == y1; };
S>};
S>

S>Структура есть, метод тоже. Но к ООП я бы это относить не стал, даже учитывая то, что оно могло бы быть написано на ООП языке.

Во-первых, не могло быть, а было написано на ООП-языке. Почему? Потому, что static (применительно к членам) специально служит в ООПных языках для обозначения неООПных мест в (преимущественно) ООПном коде.

Во-вторых, структуры-то ведь в вашем примере НЕТ. Если вы щелкните по гиперссылке в определении из Wikipedia, вы увидите, что data structure, о котором речь, и C++ structure — разные вещи. У вас приведена как раз последняя, но НЕ первая. В кривых языках слово struct в особо извращенных случаях (как у вас) может описывать то, что структурой не является. Поэтому, ваш пример принять не могу. Нет ли у вас более другого?

S>Уточню, что COM это прежде всего инструмент для представления чего угодно в объектную модель. Но само по себе использование COM не гарантирует объектность того что мы оборачиваем в COM, даже через призму COM.

Честно скажу: не понял.

Во-первых, с моей точки зрения, "инструмент для представления чего угодно в объектную модель" — масло масляное. Модель — сама по себе инструмент для представления чего угодно. Имеет смысл утверждение: "COM это прежде всего инструмент для представления чего угодно в виде объектов".

Во-вторых, уточнение это сужение. Я написал достаточно точно: компонентов (модулей). Вы заменили их на "чего угодно". Это (по форме) не уточнение, а обобщение. А по сути ваше обобщение я принять не могу. Что угодно как объекты вам COM представить не поможет. Только программные компоненты (модули).

В-третьих, "через призму COM" объектность гарантирована. На то она и модель.

S>Можем взять определение поля в ООП и показать что COM может инкапсулировать данные, хранящиеся совершенно другим способом, или даже вычислимые.

А другим это каким, например?

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

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

Опять не понял. Есть определение. Оно делит все на две части — определяемое и все остальное. Между определяемым и всем остальным есть разница, отраженная в определении (наличие объектов, состоящих из методов и полей). Эта разница порождает другую разницу, как следствие (невозможность кластерного анализа, особеннно машинного).

Почему эта разница вообще должна влиять на определение? По-моему, не должна.

SV.>>Черт с ней, с машиной — я как человек человека вас спрошу: кто кого использует, контекст перо, или перо контекст?
S>Имхо, и перо и контекст пассивны. Когда я зашруровываю ботинки, считается ли что шнурки используют ботинки? А если чай мешаю ложкой, то использует ли ложка чай?

Ну вот, по-вашему они пассивны, а в разных библиотеках то перо использует контекст, то контекст — перо. Неустранимая неоднозначность. Которая устраняется ручным проведением границ.

S>Если серьезнее, то типично контекст инкапсулирует элементарные операции с ним. Перо по отношению к этим операциям является таким же атрибутом, как координаты в context.MoveTo(x,y). Но вот однозначности это не добавляет в отношении того, кто кого использует. Мы можем смотреть на это как на DrawLine(dc,...), так и на dc.DrawLine(...). В ООП языках принята вторая запись, а суть от этого не меняется.

ГВ>>в известном смысле ООП приближено к образным структурам мышления обычного человека
K>В известном смысле, ООП приближено к представлениям подкатегории необычных людей об образных структурах мышления обычного человека. Вот так будет вернее.

Думаю еще хуже. Объекты появляются лишь в конечном представлении программы, а думать о программе и об объектах из которых состоит программа нужно чем то другим. Иначе объекты были бы неизменяемы на всем протяжении жизненного цикла, прямо как правила логики. Так что объекты мы проектируем, а не думаем ими

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

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

SV.>Здравствуйте, samius, Вы писали:

S>>Структура есть, метод тоже. Но к ООП я бы это относить не стал, даже учитывая то, что оно могло бы быть написано на ООП языке.

SV.>Во-первых, не могло быть, а было написано на ООП-языке. Почему? Потому, что static (применительно к членам) специально служит в ООПных языках для обозначения неООПных мест в (преимущественно) ООПном коде.
Не канает. По поводу static и не ООПшных мест в вашем определении нет ровно ничего.

SV.>Во-вторых, структуры-то ведь в вашем примере НЕТ. Если вы щелкните по гиперссылке в определении из Wikipedia, вы увидите, что data structure, о котором речь, и C++ structure — разные вещи. У вас приведена как раз последняя, но НЕ первая.
Это надо формально показать. По мне так очень эффективная структура данных. Пользоваться я такой вряд ли бы стал, но для определенных сценариев что-либо эффективнее сложно придумать.

SV.>В кривых языках слово struct в особо извращенных случаях (как у вас) может описывать то, что структурой не является. Поэтому, ваш пример принять не могу. Нет ли у вас более другого?
Вас смущает отсутствие экземплярных полей? Давайте добавим парочку фиктивных.

S>>Уточню, что COM это прежде всего инструмент для представления чего угодно в объектную модель. Но само по себе использование COM не гарантирует объектность того что мы оборачиваем в COM, даже через призму COM.

SV.>Честно скажу: не понял.

SV.>Во-первых, с моей точки зрения, "инструмент для представления чего угодно в объектную модель" — масло масляное. Модель — сама по себе инструмент для представления чего угодно. Имеет смысл утверждение: "COM это прежде всего инструмент для представления чего угодно в виде объектов".
Пусть будет в виде объектов. Но имхо, это уже игра словами.

SV.>Во-вторых, уточнение это сужение. Я написал достаточно точно: компонентов (модулей). Вы заменили их на "чего угодно". Это (по форме) не уточнение, а обобщение. А по сути ваше обобщение я принять не могу. Что угодно как объекты вам COM представить не поможет. Только программные компоненты (модули).
Это вы же и написали "модель — что угодно". Я только воспользовался вашей терминологией (если я ее правильно понял).

SV.>В-третьих, "через призму COM" объектность гарантирована. На то она и модель.
Объектность в COM гарантируется лишь при тщательном соблюдении спецификации. А т.к. вся объектная обвязка остается на совести разработчика, то сломать ненароком там что-нибудь можно очень легко. При том что работать код как-то будет, объектным он совсем запросто может и не являться. При желании могу открыть спецификацию COM и указать подробнее.

S>>Можем взять определение поля в ООП и показать что COM может инкапсулировать данные, хранящиеся совершенно другим способом, или даже вычислимые.

SV.>А другим это каким, например?
В файле, в БД, в облаке, в почтовом ящике, в неком сервисе и т.п.

SV.>Что касается вычислимых, это направление дискуссии с Синклером. Прошу в ту подветку.
Мне в той подветке к позиции Синклера нечего добавить.

SV.>Опять не понял. Есть определение. Оно делит все на две части — определяемое и все остальное. Между определяемым и всем остальным есть разница, отраженная в определении (наличие объектов, состоящих из методов и полей). Эта разница порождает другую разницу, как следствие (невозможность кластерного анализа, особеннно машинного).
Вам же демонстируют пример (COM), где объекты могут быть в полный рост без полей. Тут вам (как мне кажется) либо придется признать "несовершенство" того определения, либо то что объекты COM без полей не являются объектами. Но тогда придется согласиться с тем что COM не гарантирует объектность. Ваш ход.

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

S>>Имхо, и перо и контекст пассивны. Когда я зашруровываю ботинки, считается ли что шнурки используют ботинки? А если чай мешаю ложкой, то использует ли ложка чай?

SV.>Ну вот, по-вашему они пассивны, а в разных библиотеках то перо использует контекст, то контекст — перо. Неустранимая неоднозначность. Которая устраняется ручным проведением границ.
Если будут конкретные примеры, то я могу конкретнее высказаться по поводу тех или иных решений (как одобрить, так и подвергнуть критике). Не собираюсь обсуждать что-либо в контексте разных библиотек.

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

VE>>А вы напишите "transaction |>" и IDE будет знать первый аргумент. Это лишь вопрос синтаксиса. А заслуга всё-таки статической типизации. "Чего вы тень на плетень наводите?"

T>И получу в общем списке "commit(transaction)", "log(transaction)", "createTables(transaction)", "backupDatabase(transaction)" и еще 100500 нерелевантных вариантов.

С транзакциями понятно. А вот если нужно выполнить некоторую операцию над объектом... Внезапно оказалось, что ИДЕ уже не помогает, т.к. над объектом этого типа могут выполнять операции самые разные классы.

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

N>>И что хорошего это даёт? Вместо того, чтобы переопределить, например, 2 функции, вписывать их 50? А как быть с тем, что кроме функций там ещё есть поля данных, с которыми им надо работать?
S>1. Если вам нужны "поля данных", с которыми нужно работать — тогда это повод рассмотреть наследование реализации. Но это бывает значительно реже, чем кажется после прочтения овноучебников.
S>2. Если у вас в оборачиваемом объекте 50 функций, то стоит задуматься о single responsibility principle. Зачем вам такой интерфейс?

А вот интересно. Вот в самом толстом классе одного из наших продуктов 130 функций (включая вложенные). И single responsibility principle выполняется — в том смысле, что это действительно один объект с чётко определённой ролью. Попытки разрезания пока что провалились из-за сверхвысокой связанности. Есть какие-то реальные подсказки, как это лечить? Варианты типа сменить работу не предлагать

S>Вот вариант с делегированием: http://stackoverflow.com/questions/829568/how-to-know-positionlinenumber-of-a-streamreader-in-a-textfile/8876819#8876819

Я не так хорошо знаю C#, поэтому задам пару вопросов:
1. А чем мешало бы, если бы это было наследовано от другого TextReader-based класса, но именно наследовано (и были бы вызваны методы предка)?
2. Как поступить с другими методами предка? В данном примере, насколько я понял, они все банально игнорируются. Если нужна какая-то ещё функциональность от inner, то как синхронизировать работу напрямую и через этот PositioningReader?

S>Как видите, этот вариант
S>1. Значительно короче

Только из-за того, что необходимых методов мало — в пределах поддерживаемого интерфейса. И то — для нескольких пришлось сделать прямолинейные обёртки. Всё остальное было похерено.

S>2. Действительно работает

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

S>3. Работает с любым TextReader, независимо от его реального типа, а не требует наследования непременно от StreamReader.

Так можно ли в C# явно вызвать методы в реализации предка, а не потомка?
Если нет, то делегирование в этом случае фактически навязано ограничениями языка.

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

BFE>Как им вдолбить простую истину, высказанную Artifact'ом, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

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

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

Здравствуйте, Artifact, Вы писали:
Как им вдолбить простую истину, высказанную к сожалению не помню кем, что хороший код, это не тот код, в который нечего добавить, а код, из которого нечего выкинуть?

Мне кажется, вы не равильно цитируете.
Я в своей интерпретации сформулирую. "Хороший код из которого ничего нельзя выбросить без потери задуманной функциональности в области применения." Если вы не в состоянии представить общность области применения, то классы, несомненно, вам ни к чему.

Здравствуйте, netch80, Вы писали:
N>А вот интересно. Вот в самом толстом классе одного из наших продуктов 130 функций (включая вложенные). И single responsibility principle выполняется — в том смысле, что это действительно один объект с чётко определённой ролью.
Наверняка бывает и такое, хотя мне это тяжело себе представить.
Попытки разрезания пока что провалились из-за сверхвысокой связанности. Есть какие-то реальные подсказки, как это лечить?
К сожалению, я не Алан Чумак, и лечить по фотографии не способен. Мне нужно посмотреть в код, чтобы понять, действительно ли там одна такая обязанность, которая копец-копец как неразделима. Вот, скажем, сигнатура класса string в дотнете — это просто кунсткамера. Но большая часть кода оттуда выносится.

N>Я не так хорошо знаю C#, поэтому задам пару вопросов:
N>1. А чем мешало бы, если бы это было наследовано от другого TextReader-based класса, но именно наследовано (и были бы вызваны методы предка)?
Тем, что это не работало бы ни с каким другим классом TextReader-а. Например, не работало бы со StreamReader.

N>2. Как поступить с другими методами предка? В данном примере, насколько я понял, они все банально игнорируются. Если нужна какая-то ещё функциональность от inner, то как синхронизировать работу напрямую и через этот PositioningReader?
Нет никакой работы напрямую. Есть только через PositioningReader. Если нужна какая-то ещё функциональность — она должна так же делегироваться через PositioningReader.
В данном примере всё построено на том, что коробочная реализация TextReader все утилитные методы строит на основе ровно одного — того, который перекрыт. Поэтому можно не задуряться ручными оверрайдами всех методов — до тех пор, пока нас устраивает производительность посимвольного чтения.

N>Только из-за того, что необходимых методов мало — в пределах поддерживаемого интерфейса. И то — для нескольких пришлось сделать прямолинейные обёртки. Всё остальное было похерено.
Не похерено ровно ничего.

N>Это уже вопрос качества написания первого, плохого примера. По-моему, это можно было сделать проще.
Попробуйте.

N>Так можно ли в C# явно вызвать методы в реализации предка, а не потомка?
Не понял — какие методы вы хотите вызывать в реализации предка?

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

S>>2. Если у вас в оборачиваемом объекте 50 функций, то стоит задуматься о single responsibility principle. Зачем вам такой интерфейс?

N>А вот интересно. Вот в самом толстом классе одного из наших продуктов 130 функций (включая вложенные). И single responsibility principle выполняется — в том смысле, что это действительно один объект с чётко определённой ролью. Попытки разрезания пока что провалились из-за сверхвысокой связанности. Есть какие-то реальные подсказки, как это лечить? Варианты типа сменить работу не предлагать

Это интересная задача. Если этот класс является фасадом, то все в порядке, вон в Enumerable вагон методов и никого это не расстраивает. Но вообще хотелось бы больше деталей, что за функции, и как они используются. Есть возможность посмотреть в код ?

Вообще не ясно, почему тебя это беспокоит. Пока класс майнтейнится и используется легко, без разницы, сколько в ём методов, 1 или 100. srp говорит не о количестве методов, а, грубо говоря, о количестве поддерживаемы протоколах.

Здравствуйте, мыщъх, Вы писали:

E>> где проблема?
М>проблем две.
М>первая -- при итерировании вызывается ff/fn и возвращается актуальный контент. при сохранении контента внутри класса -- увы.

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

.

М>впрочем, перечитывание тоже имеет проблемы. результат возвращенный len может быть иным, чем кол-во интрированных элементов, т.к. ось живет своей жизнью и абстракция типа "директория" очень кривая абстракция. и чтобы она работала правильно -- нужно еще api для перехвата событий в файловой системе. но даже в этом случае остается проблема, что делать с len. если возвращать счетчик итератора то мы получаем неактуальный результат. если возвращать кол-во элементов на момент вызова len -- оно может не совпадать с тем, что мы получили ранее при итерации.

Всё это означает лишь то, что Directory, не является ни перечислимым объектом, ни, тем более, списком. Посмотри как это сделано в дотнете, там DirectoryInfo не IEnumerable.

public IEnumerable<FileSystemInfo> EnumerateFileSystemInfos()
public FileSystemInfo[] GetFileSystemInfos()

М>другими словами, реализовать правильно работающую абстракцию нельзя. ну потому что нельзя и все тут. и оно либо работает в 99 из 100, либо размеры кода поражают воображение, а размер спецификации рвет крышу.

Это означает, что абстракция неверна. Директория — независимый объект файловой системы,
т.е. мы не можем сделать так: using (dir.AcquireLock()) {/*считать объект неизменным*/}.

М>наиболее правильным решением будет модель, реализующая копирование при записи. т.е. мы пишем: for a in b: res.append(a); а при изменении содержимого директории res меняется автоматом. но мне страшно представить объем кода. как минимум нужно переписать весь RTL и все стандартные либы.

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

М>в этом и заключается проблема ооп. примитивы FindFirst/FindNext работают надежно и возвращают ожидаемый результат. абстрактные обертки работают не так, как ожидалось. а заставить их работать правильно практически нереально...

Это не проблема ОО парадигмы, это проблема неправильно выбранных абстракций.
В ООП эта проблема очень быстро становится видна невооружённым глазом, поэтому мне нравится эта парадигма.

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

S>>>2. Если у вас в оборачиваемом объекте 50 функций, то стоит задуматься о single responsibility principle. Зачем вам такой интерфейс?
N>>А вот интересно. Вот в самом толстом классе одного из наших продуктов 130 функций (включая вложенные). И single responsibility principle выполняется — в том смысле, что это действительно один объект с чётко определённой ролью. Попытки разрезания пока что провалились из-за сверхвысокой связанности. Есть какие-то реальные подсказки, как это лечить? Варианты типа сменить работу не предлагать

I>Это интересная задача. Если этот класс является фасадом, то все в порядке, вон в Enumerable вагон методов и никого это не расстраивает. Но вообще хотелось бы больше деталей, что за функции, и как они используются. Есть возможность посмотреть в код ?

Только в частном порядке и осторожно, ибо стандартный NDA, но я уверен, что без глубокого практического знания задачи тут никто ничего не поймёт

а в целом это класс "звонок" в софтсвиче. Методы — старт/стоп/зачистка, обработка сообщений, формирование акаунтинга, отработка специфических сценариев (пикап, анпаркинг, трансферы, etc.), прямых хуков связанных соседей типа "я должен на это послать сообщение или забить болт?" и т.д. Переменные — очереди сообщений, привязанные UA'шки, объекты акаунтинга, списки раутов, общие параметры идентификации сторон, фильтры кодеков и т.п. — ещё штук 70.
Это при том, что разные извраты типа "заморозки обработки на время запроса удалённого приёмника для attended transfer" давно вынесены в отдельные классы (потому что у них свой цикл состояния).

I>Вообще не ясно, почему тебя это беспокоит. Пока класс майнтейнится и используется легко, без разницы, сколько в ём методов, 1 или 100. srp говорит не о количестве методов, а, грубо говоря, о количестве поддерживаемы протоколах.

Меня это беспокоит именно потому, что майнтейнится уже на пределе. Если бы не тесты и взаимные ревью, то даже опытные разработчики, помнящие все детали с основания продукта, лажались бы на элементарнейших мелочах. Но все идеи это разрезать каким-то естественным образом (а не насильно в произвольных сечениях) пока что провалились...

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

I>>Это интересная задача. Если этот класс является фасадом, то все в порядке, вон в Enumerable вагон методов и никого это не расстраивает. Но вообще хотелось бы больше деталей, что за функции, и как они используются. Есть возможность посмотреть в код ?

N>Только в частном порядке и осторожно, ибо стандартный NDA, но я уверен, что без глубокого практического знания задачи тут никто ничего не поймёт

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

Нужно четко оформить свое представление,
1 что мешает (долго менять, много мест менять, вырожденые кейсы, трудно читать и тд и тд)
2 в каком направлении искать решение
3 определиться приблизительно с внешним, т.е. вызываемым кодом

Как только ты определился с п.3, т.е. знаешь, примерно, как будет вызываться твой код, нужно пробовать изолировать некоторую часть класса и проверить, какое состояние будет использоваться. Взять несколько задач которые затрагивают это состояние, например формирование аккаунтина, и попробовать накидать желаемый код.

Сразу это не заработает, т.к. депенденсы унутре не дадут сделать.
Далее следующее — изоляция этого аккаунтинга снаружи, переделывание кода в лоб шоб работало, далее изоляция унутре, далее нужно выкосить дублирование. Теперь будет ясно, стоит овчинка выделки или, как вариант, появится более глубокое представление о том, что это за класс и как его готовить.
Тут все с начала — п 1 2 3 выше

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

Есть разные другие вещи. Например делаешь полную копию класса, но используешь её только для аккаунтинга. Весь лишний код удаляешь. Теперь будет мешать дублирование состояния. Это вобще говоря решаемо — или окажется, что путь тупиковый, или нарисуется представление, как устранить это дублирование.

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

Если совсем нет никаких идей, тоже есть подход — вносишь минорные изменения, как переименование методов, переменных и следишь за тем, что именно происходит. Особенно должны интересовать методы, которые содержат Update, Refresh, Notify, Fire, Raize и тд. Это обычно взаимодействие. вот его нужно организовать правильным образом.

I>>Вообще не ясно, почему тебя это беспокоит. Пока класс майнтейнится и используется легко, без разницы, сколько в ём методов, 1 или 100. srp говорит не о количестве методов, а, грубо говоря, о количестве поддерживаемы протоколах.

N>Меня это беспокоит именно потому, что майнтейнится уже на пределе. Если бы не тесты и взаимные ревью, то даже опытные разработчики, помнящие все детали с основания продукта, лажались бы на элементарнейших мелочах. Но все идеи это разрезать каким-то естественным образом (а не насильно в произвольных сечениях) пока что провалились...

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

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

N>Только в частном порядке и осторожно, ибо стандартный NDA, но я уверен, что без глубокого практического знания задачи тут никто ничего не поймёт

а в целом это класс "звонок" в софтсвиче.

Сколько кб в этом классе ?

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

N>>Только в частном порядке и осторожно, ибо стандартный NDA, но я уверен, что без глубокого практического знания задачи тут никто ничего не поймёт

а в целом это класс "звонок" в софтсвиче.
I>Сколько кб в этом классе ?

194652 байта, 4242 строки, Python2.

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

N>>>Только в частном порядке и осторожно, ибо стандартный NDA, но я уверен, что без глубокого практического знания задачи тут никто ничего не поймёт

а в целом это класс "звонок" в софтсвиче.
I>>Сколько кб в этом классе ?

N>194652 байта, 4242 строки, Python2.

На питоне бесформенный код в примерно втрое меньше я рефакторил гдето 2 недели

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

S>>Профит в том, что повышается переиспользование кода и снижается необходимость вникания в код для использования.

A>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

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

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

A>Вот ты и сам ответил в чём проблема классов. Фактически это некий механизм, который позволяет оградить некоторую функциональность от внешнего мира, та самая инкапсуляция, при этом члены класса доступны только ему, а не всей программы. Но так же и механизм, с пом. которого добавляют кучу зависимостей, вместо того, чтобы просто передать параметр в функцию, добавляют новый член класса.
Если тащить все внутрь класса, то это ужасно. В моем текущем проекте есть такой класс. Точнее почти был. Он выродился из всемогущего в фабрику объектов. Остальной функционал разнес в другие места. И проблема проекта как раз была в том, что люди боялись переписывать код, основная отмазка: нам не дают на это время. Хотя чтобы "попить чайку" время всегда находилось.

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

A>>К сожалению повторное использование классов затруднительно из-за большого количества завсимостей между оными. Вы можете использовать либо всё, либо ничего. Без понимания внутренних зависимостей классов (какой класс из какого когда и что вызывает) не обойтись.

A>Вот ты и сам ответил в чём проблема классов. Фактически это некий механизм, который позволяет оградить некоторую функциональность от внешнего мира, та самая инкапсуляция, при этом члены класса доступны только ему, а не всей программы.

Не классов, а наследования.

Скажем, есть иерархия A->B Сколько тут связей ? Ровно одна — простое наследование. Теперь, фокус, A->B->C. Кажется, что здесь 2 связи. На самом деле 3 связи из за наследования — C зависит от B и C зависит от A и B зависит от A. Теперь A->B->C->D . Получается не три связи, а 6. Собтсвенно очевидно — переопределяем один метод, он переопределяется для каждого из дочерних классов и отследить такое далеко не всегда просто.

Если заменить такое наследование на одиночное и широкое, то будет A->B, C->A, D->A + композиция, где надо. В сумме же получается меньше связей. Скажем общие вещи можно вынести в свободные функции и это дает около нуля дополнительных связей из за композиции при сохранении функционала.

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

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

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

A>>Вот ты и сам ответил в чём проблема классов. Фактически это некий механизм, который позволяет оградить некоторую функциональность от внешнего мира, та самая инкапсуляция, при этом члены класса доступны только ему, а не всей программы. Но так же и механизм, с пом. которого добавляют кучу зависимостей, вместо того, чтобы просто передать параметр в функцию, добавляют новый член класса.
_A_>Если тащить все внутрь класса, то это ужасно. В моем текущем проекте есть такой класс. Точнее почти был. Он выродился из всемогущего в фабрику объектов. Остальной функционал разнес в другие места. И проблема проекта как раз была в том, что люди боялись переписывать код, основная отмазка: нам не дают на это время. Хотя чтобы "попить чайку" время всегда находилось.

Да, виноваты вроде бы и люди, зачем микроскопом гвозди забивать? Но насколько я знаю это распространённая проблема.
Спагетти код в программе, написанной в процедурном стиле, выглядит лучше, чем при активном использовании ООП.
Может в этом и проблема. Все эти классы надо очень аккуратно использовать. Если же не следить вовремя за тем, что происходит, то появляется новый источник зависимостей "члены и функции класса", которых не было бы при простом использовании функций.

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

A>>Вот ты и сам ответил в чём проблема классов. Фактически это некий механизм, который позволяет оградить некоторую функциональность от внешнего мира, та самая инкапсуляция, при этом члены класса доступны только ему, а не всей программы.

I>Не классов, а наследования.

I>Скажем, есть иерархия A->B Сколько тут связей ? Ровно одна — простое наследование. Теперь, фокус, A->B->C. Кажется, что здесь 2 связи. На самом деле 3 связи из за наследования — C зависит от B и C зависит от A и B зависит от A. Теперь A->B->C->D . Получается не три связи, а 6.

Собственно зависимостей ещё больше. Если в классе A есть protected члены или функции, то добавляем зависимости по их количеству. Некоторые функции должны вызываться в определённом порядке, ещё зависимость. Public-члены, всё совсем приплыли.

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

A>Собственно зависимостей ещё больше. Если в классе A есть protected члены или функции, то добавляем зависимости по их количеству. Некоторые функции должны вызываться в определённом порядке, ещё зависимость. Public-члены, всё совсем приплыли.

Я только про наследование, крупным планом, так сказать.

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

M>>>А кем преподносится? Вас обманули, это устаревшая информация. Я как раз считаю, что виртуальные функции практически всегда — зло! Также зло наследование реализации (а к нему и виртуальные функции приводят). Вместо них как раз делегирование должно использоваться. Т.е. в конструктор объекта передаются реализации виртуальных функций вместо наследования и переопределения функций.
N>>И что хорошего это даёт? Вместо того, чтобы переопределить, например, 2 функции, вписывать их 50? А как быть с тем, что кроме функций там ещё есть поля данных, с которыми им надо работать?
M>Это как минимум заставляет продумать и явно рассмотреть контракты расширения. Также при модификации класса заставляет осторожнее относиться к разделению ответственностей. Грубо говоря, видно, является ли функция "входным параметром" или частью внутренней реализации. Из "protected"-функции ее назначение обычно плохо видно — это утилитный метод для потомков или он все же предназначен для наследования и может быть изменен.

Это можно просто задокументировать. А ещё есть final в некоторых языках.
Вы же пытаетесь решить универсальными административными запретами технические вопросы, создавая массовое неудобство. Вот я пытаюсь понять: есть ли универсальный смысл в создании такого неудобства? Например, есть ли смысл каждый раз в каждом случае "рассматривать контракты расширения", или всё-таки для >90% случаев можно положиться на умолчание в виде "наследуем всё"?
В конце концов, при явной необходимости сделать делегирование — оно делается. "Tools, not policy" (tm)

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

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

И почему решение вопроса "что менять" в случае наследования реализации не требует таких суровых методов?

M>Проблема с 50-ю методами решается статическими утилитными методами (createSomethingBy...) с различными комбинациями аргументов. Там и заполняются "аргументы по умолчанию". Кстати, такие методы дают один существенный бонус — я в дальнейшем смогу отрефакторить большой класс и оставить его фасадом к нескольким меньшим взаимодействующим классам. При этом интерфейс клиентов менять не придется. Маленькие классы будут использовать переданные интерфейсы. При наследовании такой номер не пройдет. На самом деле и без наследования каких-то клиентов менять придется, но изменения будут меньше.

Хочется увидеть какой-то жизненный пример. На сейчас я не вижу никакой причины получить "большой класс" фасадом к чему-либо в принципе, и рефакторить это без проблем.

M>Кроме того, если в классе есть 50 функций, каждую из которых без вреда можно переопределить независимо, проблемы будут в любом случае. Вероятно, в класс слишком много всего намешано. И чтение класса будет подобно ходьбе по минному полю. Везде будут вопросы — могли ли наследники это переопределить и как они могли там нагадить.

Такие вопросы возникают при применении конкретного наследника, не так ли? И от количества методов они не зависят, и с одним "виртуальным" методом можно получить такое.
Как уже сказано, если где-то не хочется пускать наследника переопределять, следует применять final (ну да, в некоторых языках его нет, увы), можно переименовать реализацию и сделать её private... ну, в общем, методы решения есть.

Кстати, про createSomethingBy — я не понял, что имелось в виду, но если в базовом классе вызывается нечто, что может меняться в зависимости от экземпляра, это надо знать по-любому; и если в 99% применений оно не переопределяется, то есть шанс ложного предположения, что оно не переопределено. Опять-таки никакой разницы с наследованием реализации.

M>Ну и заключение. Я наследованием реализации обычно не занимаюсь (сейчас использую только там, где должны были быть алгебраические типы (варианты)). Все остальное более-менее нормально распиливается на маленькие классы.

Тут хорошо бы услышать конкретную рабочую область.

M> Ну а если где-то найдется применение классу на 50+ методов, придется думать.

Я рядом писал, что в работе есть, грубо говоря, класс на 200 методов, и их количество обусловлено количеством логических связей одной сущности. Хотя мы от него не наследуем

	От:	Artifact
	Дата:	18.01.12 11:20
	Оценка:	21 (3) +9 -1

	От:	HrorH
	Дата:	18.01.12 11:37
	Оценка:	11 (3) +10 -6

	От:	supacrazypusher
	Дата:	18.01.12 11:56
	Оценка:

	От:	Artifact
	Дата:	18.01.12 12:03
	Оценка:	+2

	От:	Son of Northern Darkness
	Дата:	18.01.12 12:13
	Оценка:

	От:	LaptevVV
	Дата:	18.01.12 12:15
	Оценка:	1 (1) +3 -4

От:	netch80	http://netch80.dreamwidth.org/
Дата:	18.01.12 12:48
Оценка:	+3

	От:	WolfHound
	Дата:	18.01.12 13:07
	Оценка:	63 (7) +8

От:	IT	linq2db.com
Дата:	18.01.12 17:11
Оценка:	9 (3) +1

От:	Skynin	skynin.blogspot.com
Дата:	18.01.12 17:36
Оценка:	1 (1) +1

	От:	Enomay
	Дата:	18.01.12 19:51
	Оценка:	1 (1) +1 -3

	От:	Lorenzo_LAMAS
	Дата:	19.01.12 06:20
	Оценка:	6 (1)

От:	мыщъх	http://nezumi-lab.org
Дата:	19.01.12 07:36
Оценка:	2 (2)

От:	Eye of Hell	eyeofhell.habr.ru
Дата:	19.01.12 12:51
Оценка:

От:	Mystic	http://mystic2000.newmail.ru
Дата:	20.01.12 10:50
Оценка:

От:	samius	http://sams-tricks.blogspot.com
Дата:	20.01.12 11:01
Оценка:

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	20.01.12 12:26
Оценка:	+2

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	21.01.12 00:05
Оценка:	38 (4)

От:	Sinclair	https://github.com/evilguest/
Дата:	22.01.12 14:00
Оценка:	1 (1) +2

	От:	Константин Б.
	Дата:	23.01.12 05:20
	Оценка:

От:	Andrei N.Sobchuck	www.smalltalk.ru
Дата:	23.01.12 12:53
Оценка:	-1

	От:	mrTwister
	Дата:	23.01.12 20:02
	Оценка:	1 (1) +1

	От:	Klapaucius
	Дата:	24.01.12 10:25
	Оценка:	1 (1)

От:	AndrewVK	http://blogs.rsdn.org/avk
Дата:	27.01.12 09:44
Оценка:

От:	Alex EXO	http://aleksandr-zubarev.moikrug.ru/
Дата:	29.01.12 11:26
Оценка:	3 (1)

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	24.12.13 11:25
Оценка:

От:	Философ	http://vk.com/id10256428
Дата:	24.12.13 13:56
Оценка: