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

I>>Конечно, не у каждого есть видение самого конечного дизайна. Скажем если потратил на ООП-решение год, то это вовсе не означает, что на ФП ты сходу выдашь точно такое же или лучшее.

V>Конечно не выдашь. Я лишь делюсь, как удается использовать большее кол-во наработок без переделки.

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

Соответсвенно если ты имел ввиду SOLID, то хватило бы и пяти букв а не пространных изречений

I>>Это так кажется. Код всегда можно улучшить. Хоть ФП, хоть ООП. Рефакторинг это один из способов улучшения кода, инструмент решения проблем.

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

Один из путей достижения этой цели — рефакторинг.

V>Но ведь не факт, что в первой итерации будет удачно, правильно? Почему бы начинать не с максимально закрытой инкапсуляции, а местами с открытой, закрывая потом частности по мере устаканивания собственного видения происходящего?

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

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

>Еще раз, объектная декомпозиция — это практически всегда разделение состояния, т.е. ухудшение инкапсуляции,

Что значит разделение состояния ? На примере.

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

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

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

I>>Ты вероятно Фаулера читал Рефакторинг это реорганизация обязанностей и зависимостий при сохранении НАБЛЮДАЕМОГО поведения программы.

V>Фаулера терпеть ненавижу.
V>Пройдись по формальному описанию методов рефакторинга для C#.

Это слабенькая литература. Про рефакторинг тот же лучше отрыть Майлка Физерса http://www.ozon.ru/context/detail/id/4311012/

V>Если заметно меняются данные, то изменения будут во всех задевающих их ф-иях, независимо от того, свободные они, или являются методами объектов. А вот при доработке функциональности по имеющимся данным — картинка уже совсем другая.

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

V>Обрати внимание, как неплохо вписались методы-расширения в C# и с каким удовольствием народ это использует. Потребуется ли тебе рефакторинг таких методов расширения из нейспейса, например, Linq?

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

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

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

То что ты называешь тут ООП на самом деле является SOA. Это просто взяли ООП и выкинули оттуда наследование реализации и идентичность объектов. Остались только сервисы (интерфейсы) и их эндпоинты. А внутри них может быть как ООП (с наследованием реализации), так и ФП, и actor model.

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

AVK>>КОП и ООП в мейнстриме тесно связаны.

V>В плюсах КОП в чистом виде накладен.

Это личные проблемы плюсов.

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

V>Тем не менее, полиморфизм в КОП так же доступен и используется так же.

Но не является обязательной частью, в отличие от.

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

Редко. В основном в местах, где вероятен подключаемый сторонний код.

AVK>>Вот так вот прям всегда и везде? Однако.

V>Угу, "всегда и везде" это конечно сильно, не возразишь. Тем не менее, "полу-абстрактные" классы (в которых не все методы абстрактны) по-прежнему эффективны и активно используются в заметных по размеру иерархиях того же дотнета.

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

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

V>От количества связей проблемность больше зависит.

Количество связей есть функция от качества дизайна. А качество дизайна завист в том числе и от количества и качества рефакторингов.

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

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


AVK>>Т.е. ты считаешь, что если хорошо проанализировать, то можно с первой итерации создать финальный детальный дизайн приложения?

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

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

V>Тяжелые изменяемые состояния, да еще транзакционно изменяемые, могут быть частью предметной области.

Вот поэтому архитекторам и платят денежку. Есть целая куча способов минимизировать вред от подобного. Начиная от простейших вещей типа паттерна state и заканчивая сложными системами типа современных СУБД и систем поддержки long running transactions.

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

Функциональности обычно всегда много. Надо уметь ее хорошо декомпозировать. Это все банальности.

V>Я пока не увидел, насчет "неверны". Тяжелые состояния, низкое качество кода и т.д. — требует определения.

Если хочешь поговорить о терминах, то я пас. Не интересно.

AVK>>И да, на практике я замечаю прямо противоположное — чем меньше связность кода, тем проще, легче и безболезненнее рефакторинг.

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

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

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

КО? Это все здорово, но это только декларация. Примитив. А на практике есть огромная куча деталей.
Не, ты всерьез веришь, что для борьбы со связностью достаточно такого простенького правила?

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

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

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

V>Еще раз, объектная декомпозиция — это практически всегда разделение состояния, т.е. ухудшение инкапсуляции, т.е. всё больше подробностей реализации начинает торчать наружу

Глупость ты написал. Такое ощущение, что ты пытаешься своими терминами и не очень понятными образами выразить азбучные истины. Любой дизайн стремится к минимизации связности (coupling) и максимизации зацепления (cohesion). Соотв. любая декомпозиция в идеале должна уменьшать первое, сохраняя на приемлемом уровне второе. Любая. Хоть объектная, хоть функциональная. А вот если это правило не соблюдается, то и получаем те страшилки, о которых ты пишешь. Хоть в ООП, хоть в ФП, хоть в чистой структурщине.

Скажи честно, ты Буча давно перечитывал?

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

G>То что ты называешь тут ООП на самом деле является SOA. Это просто взяли ООП и выкинули оттуда наследование реализации и идентичность объектов. Остались только сервисы (интерфейсы) и их эндпоинты. А внутри них может быть как ООП (с наследованием реализации), так и ФП, и actor model.

То о чем я говорю, это просто ООП.

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

I>Из твоих слов не совсем ясно, как должны выглять свободные функции, а хаос можно на раз воплотить с абсолютно любым подходом.
I>Соответсвенно если ты имел ввиду SOLID, то хватило бы и пяти букв а не пространных изречений

Э нет, хаос можно наворотить, даже применяя все подходы, парадигмы и эти, как их, паттерны. Поэтому требуется некая почва под ногами: например степень соответствия функциональным и нефункциональным требованиям и стоимость по ее обеспечению, если где-то есть расхождения. Кстати, глобальные ф-ии и ф-ии высших порядков — это друзъя сервисов, близких по духу к stateless, т.е. в них твое DI работает тоже на ура. Собсно, только оно нормально и работает при глубокой декомпозиции функциональности. Пример алгоритмов STL когда-то уже обсуждали. Ну и еще реактивный подход, к которому тяготеет дизайн от данных, тоже способствует разделению не по участникам, а по шагам обработки данных, и здесь DI тоже удобно для абстрагирования от конкретной реализации каждого шага.

I>Один из путей достижения этой цели — рефакторинг.

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

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

Если действительно не сможешь закрыть, то поверь, на это же выйдешь с "другой стороны" — постепенно уменьшая инкапсуляцию. А если принципиальная возможность согласно функциональности есть — то она достижима в одну итерацию рефакторинга. Но! мы уже будем видеть зависимости, по крайней мере для текущей версии софта. Я уже приводил пример взгляда на состояние как на контекст. Я выделяю объект-контекст из просто структур/объектов, представляющих данные тем, что в в контексте не всё состояние доступно извне, он может содержать инкапсулированное состояние. Но, в отличие от самодостаточного объекта, его цель — предоставлять безопасный интерфейс другим объектам для работы, то бишь он служит сервисом/инфраструктурой, не исполняя самостоятельно прикладных задач. Ну и нужен для того, чтобы его передавали друг-другу в процессе вычисления. Иногда такие контексты можно выносить даже в паблик. Например, в дотнете хватает объектов без публичных конструкторов и даже без публичных методов. Сценарий работы с этими объектами таков: его выдают клиентскому коду как результат работы некоей функциональности, но клиент должен использовать сии объекты для использования "потом". Конечно, инкапсуляция страдает, но это всегда, когда многошаговые операции приходится выполнять не нам, а клиентскому коду. Выход есть в DI, согласен, но не очень будет удобно, если наша либа будет требовать DI от клиента, ведь это лишнее идущее с либой ограничение. Могут не понять и взглянуть на решение конкурента.

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


>>Еще раз, объектная декомпозиция — это практически всегда разделение состояния, т.е. ухудшение инкапсуляции,

I>Что значит разделение состояния ? На примере.

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

А в более прикладном уровне таких случаев вообще вагон и маленькая тележка. Имеем некие поля в прикладной области. Потом можем обнаружить, что некоторые сочетания полей встречаются не только в этой прикладной структуре, но и еще во многих, и по ним идут одинаковые/похожие операции. Конечно, выносим эти поля в одну внешнюю структуру или легковесный объект. Например, пара полей: "дата начала"/"дата конца" чего-либо. Можно создать легковесный тип Period, который либо сам содержит необходимые операции, либо, если этих операций много и они добавляются относительно децентрализовано, использовать его как ATD с минимумом собственных св-в, наращивая свободный хелперный функционал вокруг.

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

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

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

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


I>Устранять дублирование кода, реорганизовывать зависимости, обязанности все равно надо, независимо от того, что у тебя меняется функции или данные

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

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

I>>Один из путей достижения этой цели — рефакторинг.

V>Рефакторинг по определению такие изменения, которые не меняют функционал. А когда надо именно менять функционал? Тогда приходится сначала рефакторить, потом уже менять функционал.

Рефакторинг это про наблюдаемое поведение,а не про функционал.

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

>Рефакторинг тоже имеет свою трудоемкость, и если его надобность однозначно определяется самим фактом развития функциональности, то что-то здесь не так.

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

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

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

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


I>>Что значит разделение состояния ? На примере.

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

Ты кажется изобрел зависимости и обязанности

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

I>>Устранять дублирование кода, реорганизовывать зависимости, обязанности все равно надо, независимо от того, что у тебя меняется функции или данные

>В одном из проектов насчитывал до 11 внутренних методов, не самых тривиальных, делающих ровно одно и тоже. А предоставь первый же из них в публичный доступ, не завязанный на конкретную специфику использующего объекта, не было бы 10-ти клонов.

Без конкретного примера этих нетривиальных методов говорить не о чем.

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

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

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

I>Ты кажется изобрел зависимости и обязанности

Опять не туда смотришь. Это как чтение журнала "Здоровье" в советские годы. Читать не рекомендовалось, або каждый начинал находить у себя те или иные симптомы. Так и ты, видать начитался намедни.

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

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

I>>Ты кажется изобрел зависимости и обязанности

V>Опять не туда смотришь. Это как чтение журнала "Здоровье" в советские годы. Читать не рекомендовалось, або каждый начинал находить у себя те или иные симптомы. Так и ты, видать начитался намедни.

Ты бы писал не простынями, а короткими понятными фразами

V>Прочисть сознание, плиз.

<> — сестра таланта ?

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

И таки ты изобрел зависимости и обязанности и назвал это "разделением состояния".

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

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

Z>>А в чем, де-факто, по-твоему, выражается этот вред?

AVK>Неоправданное повышение связности, уменьшение гибкости API.

Ясно. Значит можно не волноваться и продолжать использовать наследование реализации.

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

Z>Ясно. Значит можно не волноваться и продолжать использовать наследование реализации.

А это уж каждый для себя решает сам.

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

AVK>Глупость ты написал. Такое ощущение, что ты пытаешься своими терминами и не очень понятными образами выразить азбучные истины.

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


AVK>Любой дизайн стремится к минимизации связности (coupling) и максимизации зацепления (cohesion). Соотв. любая декомпозиция в идеале должна уменьшать первое, сохраняя на приемлемом уровне второе. Любая.

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

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


AVK>Скажи честно, ты Буча давно перечитывал?

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

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

Коллега, стоило ли так торопиться, путая причины проведения некоей декомпозиции с критериями оценки её удачности?

Ну и главное, связанность это относительная метрика. Фактически, сложность системы при декомпозиции повышается, за счет снижения сложности составных частей и уменьшения этой относительной метрики связанности. А эффект снижения сложности при декомпозиции происходит лишь в клинических случаях, например при обнаружении несвязанного функционала, механически объединенного через объединение состояний в некоем элементе/объекте. Сорри, конечно, но я позволил себе исходить из того, что сии ошибки дизайна мы рассматривать не будем. Хотя бы чтобы не предполагать, что читатель обязательно идиот.

Ну и "гвоздевой" рассматриваемый случай по всей ветке, когда состояние невозможно декомпозировать, но со сложностью функционала побороться охота, ты старательно избегаешь, комментируя частности и вырезки из контекста. Более того, предлагалось намеренно ухудшать инкапсуляцию, и сей момент обговаривается особо. Да и ссылку знакомую уже давали: http://www.softcraft.ru/coding/sm/sm01.shtml Хотя много лет назад мы это уже обсуждали, при участии Павла Кузнецова, и я твое мнение на этот счет помню. Похоже, все остались при своих.

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

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

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

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

Не с целью, а с учетом.

V>Коллега, стоило ли так торопиться, путая причины проведения некоей декомпозиции с критериями оценки её удачности?

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

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

I>Без конкретного примера этих нетривиальных методов говорить не о чем.

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


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

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

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

V>>В плюсах КОП в чистом виде накладен.

AVK>Это личные проблемы плюсов.

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


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

V>>Тем не менее, полиморфизм в КОП так же доступен и используется так же.

AVK>Но не является обязательной частью, в отличие от.

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


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

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


AVK>Количество связей есть функция от качества дизайна. А качество дизайна завист в том числе и от количества и качества рефакторингов.

Это если предположить, что простое применение рефакторинга само по себе обеспечивает качество дизайна. А это зависит от.

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


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

AVK>Это именно то, о чем я и говорю — если забить на рефакторинг, то связность будет расти, и, как следствие, любое изменение кода, не только рефакторинг, будет обходится все дороже и дороже.

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


AVK>Только какое это имеет отношение к тому, что ООП приводит к усложнению рефакторинга? Ты считаешь, что ООП решения всегда более связные, нежели чисто структурные?

Нет, я считаю, что в ООП первоначальное решение обычно дальше всех от конечного, чем в какой-либо другой технике. Т.е. путь трансформации кода заведомо больше. Полезный исполняемый код некоего функционала может поменять много классов-владельцев до релиза. Каждый раз "немного" модифицируясь. Потому как современное ООП тяготеет к проектированию "сверху" статической архитектуры. И популярные ООП-метрики по большей части — статические. И про чисто структурные решения никто не говорил. Просто предлагается техника, согласно которой, всё, что можно сделать вне объекта — лучше делать вне объекта. А в особом, упомянутом не раз в этой ветке случае, я даже настаиваю, что это самая хорошая идея. Характерно, что речь не только о свободном функционале как таковом, но и о проектировании АПИ объектов под ф-ии и функторы. Т.е. под "DI с одним методом". В классическом ООП нам нужно приседать, чтобы получить DI, т.е. разрабатывать дополнительные DI-интерфейсы, увеличивая суммарную сложность проекта. А тут вместо расписывания иерархии и интерфейсов — отгородились сигнатурой функционального объекта, на этом вся абстракция и закончилась. Ты же сам охотно используешь делегаты и лямбды там, где в их отсутствие потребовалось бы городить уникальный интерфейс "по месту"? Просто утверждение, что ФП рулит только на маленьких задачах — неверное. Хорошие практики рулят на любом уровне сколь угодно большой иерархии. В данном случае, ориентирование дизайна на DI с интерфейсами в один-пару методов позволяет уйти от россыпи интерфейсов и их классов-реализаций (пусть простейших), т.е. обойти искуственно вводимое в статически-типизированных языках ограничение на конкретный применимый тип интерфейса, использовав вместо него сигнатуру нужного функтора, ну или небольшой тупл из оных. В подобных сценариях, если брать метрику связанности, то классическое ООП, мягко говоря, сосет на нагибаясь. Хотя "все остальное" может быть выполнено с использованием ООП, но описанная вещь за рамки ООП выходит. Зато экономит кол-во разрабатываемых/оперируемых типов в несколько раз.


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

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

Крайность — это предварительное написание системы на "кончике пера". От этого давно отказались даже в IBM. Я пока вижу противоположную крайность — сразу разработку высокоуровневых иерархий и выход на список сценариев лишь в процессе. А такое "в процессе" может потребить само по себе прилично трудоемкости, и автоматическим рефакторингом с помощью даже современных утилит не всегда разруливается, приходится ручками приседать. Можно сказать, что я хитрю: предлагая бенефит, в виде экономии на необходимом рефакторинге, предлагаю посмотреть на программу с т.з. потоков обрабатываемых данных. То бишь, продвинуться всего на один шаг дальше проектирования статической архитектуры. По сравнению с культурой проектирования хотя бы 15-летней давности, это просто уровень "0" предварительного анализа.


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

AVK>Функциональности обычно всегда много. Надо уметь ее хорошо декомпозировать. Это все банальности.

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


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

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


AVK>И именно поэтому сия область состоит чуть более чем полностью из эвристик и представлений о правильном.

Сие тоже упоминалось, справедливости ради. Как и то, что эвристики не всегда уникальны, а иногда очень неплохо воспроизводимы, особенно на похожих по характеру проектах. Например, там где упор на обработку/трансформацию информации, надо приоритеты "эвристики" расставлять соответственно. Т.е. смотреть на проблему с соотв. точки зрения. Например, строить модель ПО, отталкиваясь от динамики, и выходя на его статическую архитектуру как следствие удовлетворения нужд динамики. Чем не хорошая "эвристика"?

А высказался столь пространно по теме (уже завязываю тут, сорри), потому как чуть менее, чем всегда (С) вижу ОО-проектирование, пляшущее исключительно от статической архитектуры. И даже деплой заранее расписывается, до первой строчки кода, угу. ИМХО, такая "эвристика" только вредит. И... требует больше рефакторинга.

V>> Выделяя некое состояние как "данные", мы фиксируем безопасный "интерфейс" доступа к данным, оставляя на свободе функционал вокруг них.
AVK>КО? Это все здорово, но это только декларация. Примитив. А на практике есть огромная куча деталей.

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


AVK>Не, ты всерьез веришь, что для борьбы со связностью достаточно такого простенького правила?

Через единицы лет нам будет по 20 лет рабочего стажа. Фигли тут спрашивать заведомую ерунду? Тем паче, что сложность — величина абсолютная, а связанность — относительная. Не ты ли делал замечание насчет понимания, что не всегда O(n) хуже чем O(n^2)? Из той же оперы, всегда зависит от частностей.

Не верю ничему, если вопрос был про веру.


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

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

Обсуждались пути кратчайшего выхода на эту наименьшую связанность. А насчет очевидностей и прочего. Или как ты говорил "дизайн управляется тем-то и тем-то, идите читайте классиков". Он не управляется метриками, по справедливости говоря, а оценивается. Это немаловажный момент, механически применимых правил нет, и даже ты в этом согласился. ИМХО, степень этого "управления" зависит от кол-ва шагов (грубо), на которые разработчик способен заглянуть вперед. Вот обсуждается возможность саму последовательность работ построить так, чтобы заглядывание вперед происходило на большее число шагов "само", лишь как следствие перетасовки последовательности работ. Это окупается, если над проектом одновременно работает заметное число людей, бо изменения архитектуры не бесплатны. У людей копится багаж знаний о собственном проекте, а после очередного "глобального" рефаторинга все оказывается "черти где" на их взгляд. Начиная от самих файлов с кодом, над которыми они работали накануне, и которые теперь перименовались вместе с типами и даже лежат в другом проекте. Повторюсь, это всегда при совместной разработке болезненно, поэтому такой рефакторинг стоит планировать и делать его эффективным, т.е. делать большее кол-во полезных изменений за меньшее число подходов. А так же использовать любые пособы для снижения надобности в нем. И уж тем более, постараться избавиться от надобности оного просто в ответ на рост сложности. Не обратил внимание, что чем больше людей участвует в каких-нить открытых проектах, тем более скупые идут диффы минорных версий? Не от хорошей жизни.

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

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

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

За сим позволю себе закруглиться, або 5-й раз по кругу.

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

I>И таки ты изобрел зависимости и обязанности и назвал это "разделением состояния".

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

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

AVK>Ну понятно, проблема во мне.

В словарном запасе и манерах — это в тебе? Впрочем, это происходит не первый десяток раз.


AVK>Тебе, правда, другие то же самое пишут, но это тоже в них проблема.

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


AVK>Истинный гуру здесь, понятно, один.

Вот оно что.


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

AVK>Не с целью, а с учетом.

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


V>>Коллега, стоило ли так торопиться, путая причины проведения некоей декомпозиции с критериями оценки её удачности?

AVK>Я как раз ничего ен путаю. Но то, что ты начал цеплятся к словам — показательно.

Ну так даешь повод.

Соотв. любая декомпозиция в идеале должна уменьшать первое, сохраняя на приемлемом уровне второе. Любая.

"В идеале" или "любая"? Если бы не пытался столь усилить двойным повторением, в глаза не бросалось бы.

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

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

Кстати, первоначальный рецепт все еще в силе. Он простой как три копейки (в грубом описании), но не имеет отношение к твоему замечанию. Достаточно делать любую полезную добавляемую внутреннюю функциональность видимой всем внутренним типам. Угу, смелое начало. Требует незначительных приседаний по обеспечению безопасности такого доступа. Но почему нет? Мы же в других случаях тоже на 100% знаем, что с первого раза взяли не разработаем идеальный дизайн. Дык, почему бы это знание не использовать? В каждом конкретном случае берется максимально высокоуровневый функционал (чтобы самому меньше писать), если он уже есть, или же делается для этих уникальных нужд. И ложится в "общий котел". Удовлетворив основные функциональные требования, мы получаем готовую схему связанности. Ой, так мы уже не должны "стремиться" или "пытаться" сделать дизайн с наилучшими показателями связанности, мы можем произвести точную наилучшую группировку функциональности для построения высокоуровневой архитектуры? (с целью формирования публичного АПИ, например) Коль у нас уже есть полный список всего. И мы уже воочио сталкивались с теми случаями, где нужна абстракция, и уже отличаем от тех случаев, где вовсе нет. Построение архитектуры фактически за один шаг? А почему нет? У всех тоже архитектура стабилизируется примерно к половине проекта, я лишь исключил промежуточные итерации, бо не обладаю полнотой информации. И не делаю вид, что обладаю. И что мне теперь делать с твоими "истинами"? Характерно, что рамки сего подхода тоже были очерчены с самого начала, оставив для самого верха КОП, т.е. рассматривался уровень ниже — это реализация компонент. И библиотек для них в т.ч.

Описанное XP? Вовсе нет, хотя кое-какие ее практики используются, план покрытия целевой функциональности известен заранее, как и прикинута его трудоемкость. Это всего-навсего функциональная декомпозиция. Да, банальность во всем этом была с самого начала, но не с того конца ее искали. Угу, та самая декомпозиция, неплохо работающая для сценариев, ориентированных на данные. И в рамках ООП-языков, что характерно, тоже. Буч, кстати, прошелся там по алгоритмической композиции в уничижительной форме, но это вовсе не то же, что функциональная. Последняя предлагает ср-ва абстрагирования через сигнатуры ф-ий, плюс мы это все приправляем легкостью связи с ООП, в С++ от рождения, в дотнете уже несколько лет как, и картинка выходит совсем другая. Про избавление от тонны лишних внутренних интерфейсов уже упоминал в пред. сообщении. В общем, как же он тут не прав:

Свободная подпрограмма, в терминологии C++, — это функция, не являющаяся элементом класса. Свободные подпрограммы не могут переопределяться подобно обычным методам, в них нет такой общности.

В общем, я уже не знаю, на каких пальцах объяснять очевидные вещи, чтобы не нарываться на глупые "ты изобрел отвественности" или "декомпозиция должна вестись так-то и так-то". А если не только ДЕкомпозиция, но и КОмпозиция? А если даже и это не суть, а упор на принятие важных решений ПОСЛЕ накопления информации? А если и это не было сутью, в обсуждении способов уменьшения необходимого кол-во итераций рефакторинга для достижения того же по качеству кода? Чем не полезная эвристика?