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

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

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

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

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

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

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

V>Таки нет. Декомпозиция состояния — это и есть декомпозиция в стиле классического ООП.

Ну тогда напримере паттернов враппер, адаптер, прокси, суррогат, декоратор поясни, где тут разделение состояния.

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

V>>Таки нет. Декомпозиция состояния — это и есть декомпозиция в стиле классического ООП.

I>Ну тогда напримере паттернов враппер, адаптер, прокси, суррогат, декоратор поясни, где тут разделение состояния.

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

Состоянием оперируют, например, поведенческие паттерны. Там наблюдается та самая декомпозиция внутреннего состояния по объектам. Самый яркий представитель сего семейства — паттерн state, посмотри его. Другие поведенческие паттерны через него легко выражаются.

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

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

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

I>>Ну тогда напримере паттернов враппер, адаптер, прокси, суррогат, декоратор поясни, где тут разделение состояния.

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

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

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


V>>Так и запишем. Примера программы, не являющейся моделью, нет.
G>
G>Не сливай так откровенно. Ты задавал вопрос, ты не захотел искать хотя я ответ давал.

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


G>Ну хватит уже выкручиваться. Нету определения абстрактного интерфейса.

Все-таки, посмотреть когда и как упоминается точное совпрадение по фразе мы не хотим?
В общем, дабы закрыть эту бодягу, хоть я и надеялся на озарение и даже дал все подсказки...
Есть определение "абстрактного метода" и "интерфейса класса". Последнее, если обратил внимание, не есть нечто неделимое, это — совокупность публичных членов класса. Члены интерфейса класса могут быть абстрактными, а могут быть и нет. Когда кто-то говорит об абстрактном интерфейсе класса, имеется ввиду его публичный интерфейс или его часть, представленная абстрактными членами. Но это же длинно в написании, согласись? ИМХО, для коллег понятен и более короткий вариант.


V>>Ты уже 10-й пост демонстрируешь, что путаешь понятие "интерфейс" с особым типом и ключевым словом конкретного языка. Воистину, вот и выросло next generation. ИМХО, остальное обсуждать бессмысленно, пока не сдвинемся с этой мертвой точки.
G>Так я и говорю, ты приведи в порядок терминологию, чтобы я или кто-то другой не путал твои понятия интерфейсов.

Т.е., ты противишься термину "интерфейс класса"? Даже сейчас? Сколько тебе еще надо итераций?


V>>Я писал для случая больших иерархий. Т.е. пример с небольшими иерархиями ничего не подтверждает, а всего-лишь неподходит.
G>Так приведи пример, который подтверждает твои слова.

Приводил, AWT в Java.


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

Полностью абстрактные классы им эквивалентны с т.з. ООП.


G>Ты пытался увести тему разговора. Что бы ты не забыл напомню твое утверждение: что имеют смысл большие иерархии интерфейсов.
G>Это утверждение с практикой расходится, никто не создает такие иерархии, они никому не нужны.

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

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

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

Примеры из дотнета? — мильон. Бери интерфейсы из System.Linq: IGrouping<>, ILookup<>. Глубина иерархии наследования — 3, наследников членов иерархии — не счесть. И это еще глубоко, бо на интерфейсах как раз в 1 уровень выписывать все связи обычно получается.


G>Я все видел много раз. А ты мог бы привести пример "показательного использования", а не писать пустые слова.

Коллега, ты просто образец лени. Были же даны все ключевые слова, по которым в гугле за два клика оказываемся тут: java.awt.peer diagram
На случай, если и там нужной иерархии интерфейсов не найдешь, вот одна из первых ссылок: http://www.webbasedprogramming.com/Java-Unleashed-Second-Edition/fb-12.gif Ну и на случай, если опять что-то не понятно, это именно интерфейсы. В Java не принято начинать идентификаторы интерфейсов через I.

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

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

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

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

Если не получится — не беда:

Структурные паттерны решают вопрос о том, как из уже имеющихся классов и объектов оптимально получить более крупные структуры и образования.

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

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

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

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

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

код ниже, покажи, где там разделение состояния.

interface IDoer
{
  void Do(); 
}

class Doer : IDoer
{

void Do()
{
  PreDo();
  DoInternal();
  PostDo();
}

}

декомпозируем

interface IDoer
{
  void Do(); 
}

class Doer : IDoer
{

void Do()
{
  DoInternal();
}

}


class PreAndPostDoerDecorator : IDoer
{
  PreAndPostDoerDecorator(IDoer doer){  _doer = doer;} 

void Do()
{
  PreDo();
  _doer.Do();
  PostDo();
}


}

и используем

someMethod.AcceptDoer(new PreAndPostDoerDecorator(doer));

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

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

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

Дык, ты спросил про структурные паттерны, я ответил.

I>код ниже, покажи, где там разделение состояния.

Никто пока не увиливает, ты лишь сумбурно задаешь вопросы.

Давай разберем твой пример. Итак, для начала введем состояние в первоначальный объект, прежде чем делать выводы. Это поможет понять происходящее, выявить связи. Вот есть твои методы PreDo() и PostDo(). Они требовали для своей работы каких-то внутренних полей первоначального класса Doer? Если требовали, то тебе надо обеспечить доступ к этим полям в новом объекте PreAndPostDoerDecorator, ЧТД. Если не требовали, то что они делали в этом классе? Если же подразумевалось некое "внешнее глобальное состояние", то нам его надо ввести в модель в виде некоего объекта в одном экземпляре и сослаться на него из использующих классов. Но ЧТД остается при этом в силе, потому как после декомпозиции этой ссылкой будет владеть PreAndPostDoerDecorator.

В общем, давай попытку №2, это будет полезно.

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

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

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

V>Дык, ты спросил про структурные паттерны, я ответил.

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

I>>код ниже, покажи, где там разделение состояния.

V>Никто пока не увиливает, ты лишь сумбурно задаешь вопросы.

V>Давай разберем твой пример. Итак, для начала введем состояние в первоначальный объект, прежде чем делать выводы.

Не надо ничего вводить State+Flyweight тоже состояние требуют ?

>Это поможет понять происходящее, выявить связи. Вот есть твои методы PreDo() и PostDo(). Они требовали для своей работы каких-то внутренних полей первоначального класса Doer?

Разумеется не требовали и это элементарно.

>Если требовали, то тебе надо обеспечить доступ к этим полям в новом объекте PreAndPostDoerDecorator, ЧТД.

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

>Если не требовали, то что они делали в этом классе?

Это ж элементарно — мне надо изменить поведение некоторый реализаций не переписывая все разновидности и клиенты IDoer

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

I>Т.е. под объектной декомпозицией ты имел ввиду все случаи декомпозиции кроме использования структурных паттернов ?

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

I>Не надо ничего вводить State+Flyweight тоже состояние требуют ?

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

Flyweight вообще к структуре объекта не имеет отношение, это просто техника кеширования экземпляров.


>>Это поможет понять происходящее, выявить связи. Вот есть твои методы PreDo() и PostDo(). Они требовали для своей работы каких-то внутренних полей первоначального класса Doer?

I>Разумеется не требовали и это элементарно.

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


>>Если требовали, то тебе надо обеспечить доступ к этим полям в новом объекте PreAndPostDoerDecorator, ЧТД.

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

Тогда нам придется рассматривать и состояние базового класса тоже и необходимость его декомпозиции в т.ч. Все эти ООП-наработки работают до любой глубины иерархии.
ОК, пусть будет базовый класс DoerBase и мы имеем такую иерархию до:
Doer <= DoerBase

после:
Doer <= DoerBase
PreAndPostDoerDecorator <= DoerBase

В приведенном примере так или иначе придется обосновать наличие методов PreDo()/PostDo(), пусть даже через зависимости в базовом классе. Я лишь хочу показать, что эти зависимости рано или поздно должны выйти на состояние объекта. Мы же не можем в этих методах брать данные ниоткуда или ничего не делать (иначе такие методы были бы не нужны).

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


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

Здравствуйте, Игорь САВЧУК, Вы писали:
ИС>Попробуем разобраться и ответить на главный вопрос, почему всё же объектно-ориентированное программирование провалилось?

а ты точно знаешь, что оно уже провалилось?

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

I>>Т.е. под объектной декомпозицией ты имел ввиду все случаи декомпозиции кроме использования структурных паттернов ?

V>Согласно определению, структурные паттерны осуществляют композицию.

То есть когда один объект был разделен на две части это композиция ?

А когда один объект с разделяется на две части с разделением состояния, это декомпозиция ?



Ну и дела

I>>Не надо ничего вводить State+Flyweight тоже состояние требуют ?

V>Да, паттерн State требует введения нового поля, хранящего объект-state как минимум.

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

I>>Разумеется не требовали и это элементарно.

V>Нет, не элементарно. Если не было зависимостей прямых или косвенность от состояния, то им нечего было делать в объекте.

Опаньки — сначала было состояние, а теперь уже зависимости

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

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

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

V>В приведенном примере так или иначе придется обосновать наличие методов PreDo()/PostDo(),

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

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

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

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

I>Ты по моему сравниваешь плохое vs хорошее

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


I>При чем здесь по месту ?

Попробуй прочесть еще раз.


I>Как ты будешь тестировать свой нетривиальный метод ?

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


I>Повторное использование это круто, но не тогда когда это монолит.

Можно по-русски?

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

AVK>Но, если разнести наследование интерфейсов и реализаций по независимым механизмам, языки от этого только выиграют.

Как это может выглядеть? Наподобие приватного наследования в C++?

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

V>Как это может выглядеть? Наподобие приватного наследования в C++?

Думать надо, экспериментировать. В реализованном виде есть несколько вариаций на тему миксинов, есть автоматическое делегирование реализаций.

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

V>>Да, паттерн State требует введения нового поля, хранящего объект-state как минимум.

I>Необязательно.

Обязательно, или это будет уже другой паттерн.

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

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

V>>Нет, не элементарно. Если не было зависимостей прямых или косвенность от состояния, то им нечего было делать в объекте.

I>Опаньки — сначала было состояние, а теперь уже зависимости

Гм... Вообще-то зависимости как раз и вычисляются м/у состоянием и методами. Если методы класса не связанны прямо или коссвенно с его собственным состоянием, то "тут что-то не так". По крайней мере, популярные метрики показывают наихудшее/вырожденное значение для этого случая.

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

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

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

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

Попробуем итерацию №3? Или уже и так ясно?

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

Вдогонку, для указанных ограничений будет такое итоговое решение

// тут наследуем, т.к. PreDo()/PostDo() требуют особого доступа к базе по условию,
class PreAndPostDecorator : ThirdPartyClass
{
  public void PreDo() {}
  public void PostDo() {}
}

// структурная композиция
class PreAndPostDoerDecorator : IDoer
{
  private PreAndPostDecorator _decorator = new PreAndPostDecorator();
 
  PreAndPostDoerDecorator(IDoer doer){  _doer = doer;} 

  void Do() {
    _decorator.PreDo();
    _doer.Do();
    _decorator.PostDo();
  }
}

interface IDoer
{
  void Do(); 
}

Но оно не интересно. Ибо, чем больше ограничений, тем меньше надо думать.

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

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

S>>У меня возникает обратный вопрос. Разве нельзя оставаясь в рамках ООП выполнить это разделение обладая достаточно подробным списком связей? ООП по Кею — это "все есть объект", а не руководство по декомпозиции на модули.

V>А это вообще больное место. Не существует формальных способов ООП-дизайна. Во всех примерах ООП-анализа в литературе столько творчества, что единственный полезный совет тут — это потщательнее грызть карандаш.

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

V>На самом деле, достаточно помнить, что ООП-не серебрянная пуля, т.е. сам по себе не самодостаточный инструмент. Поэтому стоит использовать (хотя бы очень поверхностно) наработки современных процессов по организации разработки ПО. Тем более, что те индифферентны к выбранной технологии. Я вот всем 19-е и 34-е госты рекомендую. Хотя бы раз в жизни прочесть их стоит (с конспектированием интересного). Ну или RUP, который близок по духу.

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

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

V> Ну и если есть опыт по созданию/использованию делегатов в том же C#, то еще одним "китом" ФП ты уже владеешь.
Я бы сказал что знаком с китом, а не владею.

V>Прочие ленивости и замыкания — это лишь доп. выразительные ср-ва инструмента, т.е. те, которые не критичны, т.к. в случае надобности реализуются "в лоб". Хотя со вторым упомянутым в шарпе тоже порядок.
В шарпе — да. Куда сложнее на C++ без 0x, с которым приходится иметь дело.

V>Ну и плюс, ФП в "чистом" виде не совсем удобно (лично мне, например).
Мне довольно удобно. неудобно как раз видеть решение в ФП виде и адаптировать его к ООП.

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

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

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

V>Практика комментирования коммитов и щедрость на TODO помогает упорядочивать. Главное, чтобы команда преследовала общие цели, и если кто-то видит, что образуется потенциально слабое место — поставил сигнальный флажок на нем.

V>>>Они и так сами получаются. Деление на слои процесс как бы автоматический, управляется сложностью единичного элемента, которую может обозреть человек. Какое там правило для ф-ий и методов — не больше 1-2 экранов кода? Примерно так.
S>>Автоматический для тех кто уделяет этому достаточно внимания

V>Всё-равно автоматически по достижении некоторого порога. Однажды становится трудно просто прочесть код, даже если он хорош. И единственно правильное решение — декомпозировать, передокументировать и прочесть заново. Это может сэкономить часы и это дополнительный review кода. Оно как эффект катастрофы в природе, во вменяемой команде выполняется на автомате всеми участниками.
(выделил чуть выше)
Дело в том, что код становится плохочитаемым не сам по себе, а в процессе изменений. И тут все-таки нужен рефакторинг, желательно в тот момент, когда код модифицирован, т.к. он только что прочитан и детали свежи. TODO здесь поможет только в том случае, когда видно что плохо, но цель не ясна, т.к. связано с кодом, который в другом владении, либо неясна общая концепция.
В моей практике TODO имеют меньшие приоритеты чем issue в трэкере, потому плодятся как кролики. Стараюсь рефакторить сразу.

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

I>>Как ты будешь тестировать свой нетривиальный метод ?

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

Выделить и сделать тестируемой это разные вещи и бывает между собой никак не связаные.


I>>Повторное использование это круто, но не тогда когда это монолит.

V>Можно по-русски?

Это по русски.

ИС>Среди множества идей, которые звучат красиво скорее в теории, чем на практике, объектно-ориентированное программирование занимает особое место.

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