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

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

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

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

S>> Похоже нет.

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

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

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

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

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

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

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

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

S>Давай каждый свои мысли будет продолжать
Тогда не останавливайся на пол-пути.. =)

S>Так ведь то что ты предлагаешь (b.foo()) это и есть "accessing local data of another module", т.е. самый сильный тип связности.
Ты не отличаешь local от public contract или просто прикидываешься?

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

S>Relational cohesion: average number of internal relationships per type:
Ты ошибаешься, мы говорим именно о связности, я тебе даже определение привел.

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

S>Ну, хотелось чтоб и авторитетное и аргументированное, шоб просто пригвоздило меня и все
Не пригвоздило еще?

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

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

S>Четкий это критерий или не четкий, решай сам.
Совершенно не четкий.

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

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

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

S> зависимости класса В от класса А теперь нет.
Ее и раньше не было, точнее была контролируемая между A и B, а стала не контролируемая между A и foo().

S>Может повлиять а может не повлиять, что с того.
О, как ты заговорил.. Хорошо уже что признаешь проблему.

S>В любом случае, если изменения семантики существенные будет ошибка компилятора.
В том-то и дело, что совсем не факт, что будет.

S> Если изменения не в семантике, на то модульные тесты есть.
Модульные тесты не являюются панацеей и нельзя наличием модульных тестов оправдывать кривую архитектуру.

S>Твой вариант от этого тоже не застрахован.
Он застрахован от этого в большей степени.

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

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

MC>Я попросил показать реальный пример про String раз вы утверждаете что он реализован неправильно и эти функции надо было вынести в отдельные классы.
Мне сложно судить занятие чем, мешает тебе экстраполировать мой пример на класс String. =)

MC>Так и думал что вы так напишите. Как достойно с вашей стороны было прокомментировать это мое замечание.
Было бы недостойно оставить такое замечание без внимания..

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

Z>Между тем мне лично ими удобнее пользоваться.
Лично мне все равно. У тебя же пользование DI дискомфорта не вызывает?
Но дело не в этом.

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

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

MC>>Я попросил показать реальный пример про String раз вы утверждаете что он реализован неправильно и эти функции надо было вынести в отдельные классы.
IB>Мне сложно судить занятие чем, мешает тебе экстраполировать мой пример на класс String. =)
Понял, реальных примеров привести не можете. Только голая теория.
— Ну вот надо все эти методы надо было вынести в отдельные классы, потому что в противном случае это косяк.
— Почему косяк?
— Ну вот связность, и все такое, и Мейерс заявил что "они ошибаются"
— На практике в чем косяк?
— Ну я же писал.. что косяк..
— Так в чем косяк на практие?
— Ну связность.. и Мейерс говорил..

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

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

S>>Давай каждый свои мысли будет продолжать
IB>Тогда не останавливайся на пол-пути.. =)
Ага...

S>>Так ведь то что ты предлагаешь (b.foo()) это и есть "accessing local data of another module", т.е. самый сильный тип связности.
IB>Ты не отличаешь local от public contract или просто прикидываешься?
foo() использует локальные данные класса А, то что ты заставил ее работать через паблик интерфейс не меняет сути.

S>> Что с того что он все эти данные тягает через паблик интерфейс класса A, от этого все эти данные не перестают быть локальными данными класса А.
IB>Перестают. Local — это именно приватные данные класса, его внутреннее состояние не доступное из вне.
Т.е. данные класса, опубликованные через паблик интерфейс перестают быть данными класса. Оч интересно.

S>>Relational cohesion: average number of internal relationships per type:
IB>Ты ошибаешься, мы говорим именно о связности, я тебе даже определение привел.
Это не я ошибаюсь. Это была цитата.

S>>Тут все зависит от сценария применения DI.
IB>Это ни коим образом не зависит от "сценария применения DI", уменьшение связности — это свойство DI вынесенное в его определение.
IB>Он применяется, когда уже есть связь (внутренняя), чтобы вынести ее во внешний контракт и тем самым ослабить связность. То есть, сделать ровно то, о чем мы тут говорим.
Разница в трактовке роли внутренних связей. Но против этого мне нечего возразить, убедил.

S>>Ну, хотелось чтоб и авторитетное и аргументированное, шоб просто пригвоздило меня и все
IB>Не пригвоздило еще?
Неа..

S>>Смотри, это проектирование. Ты сначала определяешь область ответственности и потом под нее делаешь класс. Все что не входит в эту область отвественности — гэть долой из класса.
IB>О, прикольно. То есть, запихнули все в класс, что влезно и назвали это одной ответственностью...
Опять начинаешь... Черным по зеленому написано сначала определяешь ответственность, потом на этом критерии принимаешь решение что включать, а что нет.

S>>Вот ты даже не заметил, что я определил область ответственности для калсса как "представление данных", а ты как "хранение данных".
IB>Я как раз заметил, и совершенно сознательно поправил на хранение. То есть, твоя ошибка в том, что ты не правильно определил область ответственности класса?
Не ошибка, а точка знения, не "неправильно" а по-другому. Тут в другой ветке обсуждали дизайн System.String (http://www.rsdn.ru/Forum/message/3031451.aspx

Автор: Ziaw
Дата: 22.07.08

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


S>>Но ведь все, что можно получить через паблик интерфейс, можно получить и через внутреннее состояние. И четкий критерий уже начинает размываться.
IB>Не начинает. Любая реализация должна пытаться обойтись публичным контрактом, если удалось — значит снаружи, если же по каким-то причинам (не важно по каким, производительность ли это или в публичном контракте чего-то не хватает), контрактом обойтись не удалось — значит внутри. Все очень просто и никаких неоднозначностей.


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

S>> Функция стала частью интерфейса класса. Те классы что зависят от этой функции так же под контролем как и были.
IB>Нет. Ты больше не контролируешь связь между функцией и классом внутрь которого ее поместил.
Почему это. Ты эту фразу уже раз шесть повторил как заклинание и не разу не объяснил, где же там конкретно контроль теряется? Компилятор соответствие типов или наличие членов престает там контролировать?
S>> зависимости класса В от класса А теперь нет.
IB>Ее и раньше не было, точнее была контролируемая между A и B, а стала не контролируемая между A и foo().
Ну вот опять. Контролируемая — неконтролируемая. Чем неконтролируемая связь отличается от контролируемой. В каких конкретно аспектах теряется контроль

S>>Может повлиять а может не повлиять, что с того.
IB>О, как ты заговорил.. Хорошо уже что признаешь проблему.
Хорошо что ты заметил. Я не ортодокс.

S>>В любом случае, если изменения семантики существенные будет ошибка компилятора.
IB>В том-то и дело, что совсем не факт, что будет.
Че за компилятор такой?

S>> Если изменения не в семантике, на то модульные тесты есть.
IB>Модульные тесты не являюются панацеей и нельзя наличием модульных тестов оправдывать кривую архитектуру.
Конечно. Вот отсутствие модульных тесов можно оправдывать кривой архитектурой В-общем это офтоп.

S>>Твой вариант от этого тоже не застрахован.
IB>Он застрахован от этого в большей степени.

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

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

AVK>>Приходило. Только вот наличие двух методов в публичном контракте, делающих одно и то же — это точно неправильное решение.
S>Это методы разных классов, и не факт что они делают одно и то-же

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

S>, да и моя реплика этого не касалась.

Ты отвечал на мое сообщение, в котором была ровно одна фраза.

AVK>>Переходим на личности?
S>Вовсе нет

Вовсе да. Я тебя уже просил не делать выводов о квалификации собеседников.

S>, еще держусь, хотя некоторые по мне тут уже потоптались.

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

S>Просто в твоем ответе сквозит такая уверенность в существовании "правильной архитектуры"

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

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

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

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

A>Ага, в Строке нужно использовть внутренние более эффективные механизмы нахождения сисла символов (детей), а в точно такой-же задаче (топикстартера) нужен дополнительный класс; IndexOf() для Строки -- внутренний метод (из соображений производительности), а GetUniqChildName() (c тем же принципом) внешний.

A>Ну-ну.

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

AVK>>Никаких оговорок. Приемлемая производительность не может быть реализована толькопубличным контрактом — метод нельзя помещать во внешний класс.
A>Что-то я этого предложения в правиле не заметил.

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

AVK>>По тому, который в этом треде обсуждается.
A>Извините, но я как-то выпал из дискуссии (многабукаф -- ниасилил

Придется осилить. Работать аннотатором у меня никакого желания нет. И за падоначью лексику здесь банят.

AVK>>Для удобства умные люди придумали extension methods.
A>Ну как-бы так сказать -- пока у меня к ним негативное отношение.

Это, уж извини, твои личные проблемы.

A>Чего стоит только мозгоразрывательный этюд:

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

A>И после этого вы хотите сказать, что экстеншен методы это хорошо?

Да.

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

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

Z>>Между тем мне лично ими удобнее пользоваться.
IB>Лично мне все равно. У тебя же пользование DI дискомфорта не вызывает?
Вызывает, но по совокупности воздействий добавляет больше комфорта.
Да и прямой аналогии DI с сабжем я не вижу.

Z>> Может быть это и есть причина по которой МС пошли на удорожание поддержки?
IB>Вряд ли. Удобство весьма сомнительное, а проблем можно огрести достаточно.

Т.е. все архиекторы библиотек работы со строками .net, java, python, ruby допустили одну и ту же ошибку дизайна?

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

AVK>А оно там не нужно. В правиле не конкретизируется вообще, по какой причине не получается пользоваться только внешним контрактом. А если не конкретизируется — значит причина может быть любой.
А вы спросили топикстартера о том, что для него критично, а что нет? Нет, не спросили. Вы сразу стали гнуть свою линию.
О том что в этой линии есть исключения (ну как бы даже не исключения, а уточнения к самому определению, и даже не к определению, а к некоторым словам, ...) стало известно много ниже.

AVK>>>По тому, который в этом треде обсуждается.
A>>Извините, но я как-то выпал из дискуссии (многабукаф -- ниасилил

AVK>Придется осилить. Работать аннотатором у меня никакого желания нет.
Извините, но вышеозначенную "грызню" читать и выкапывать оттуда здравые мысли не имею никакого желания.
Если это необходимое условие продолжения ветвии. Давайте на этом закончим

AVK> И за падоначью лексику здесь банят.
Хочется нехорошее сказать, но промолчу.

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

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

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

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

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

AVK>> И за падоначью лексику здесь банят.
A>Хочется нехорошее сказать, но промолчу.

Промолчи.

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

S>foo() использует локальные данные класса А, то что ты заставил ее работать через паблик интерфейс не меняет сути.
Меняет. В одном случае все взаимодействие проходит через публичный контракт, а в другом нет, как следствие, в одном случае метод защищен от внутренних изменений класса (и наоборот), а в другом не защищен.

S>Т.е. данные класса, опубликованные через паблик интерфейс перестают быть данными класса.
Если доступ к локальным данным осуществляется через публичный интерфейс, то это доступ к публичному интерфейсу, а не к локальным данным.

S>Это не я ошибаюсь. Это была цитата.
Просто она была не к месту. =)

S>Разница в трактовке роли внутренних связей. Но против этого мне нечего возразить, убедил.
То есть, за DI ты признаешь право уменьшить звязность путем вынесения внутренней связи во внешний контракт, а за просто выносом метода — нет?

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

S> Тут в другой ветке обсуждали дизайн System.String (http://www.rsdn.ru/Forum/message/3031451.aspx

Автор: Ziaw
Дата: 22.07.08

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

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

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

S>Это была твоя проблема, что ты не можешь себя сдерживать в рамках приличий.
Что я такого неприличного написал?!

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

A>А вы спросили топикстартера о том, что для него критично, а что нет? Нет, не спросили.
У "топикпастера" все очевидно.

A>О том что в этой линии есть исключения
Нету там исключений.

A> (ну как бы даже не исключения, а уточнения к самому определению, и даже не к определению, а к некоторым словам, ...) стало известно много ниже.
Что именно стало известно?

A>Извините, но вышеозначенную "грызню" читать и выкапывать оттуда здравые мысли не имею никакого желания.
Тогда зачем вообще вмешиваешься?

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

MC>Понял, реальных примеров привести не можете.
Я привел вполне реальный пример, много примеров. Я не виноват, что они тебе не нравятся. =)


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

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

Z>Да и прямой аналогии DI с сабжем я не вижу.
Да прямее уже и не найдешь. Обсуждаемые хелперы — DI сервисы в чистом виде.

Z>Т.е. все архиекторы библиотек работы со строками .net, java, python, ruby допустили одну и ту же ошибку дизайна?
Не знаю, всех не смотрел, но в .Net ошибки дизайна присутствуют в количестве.

Z>Меня больше устраивает другая версия:
Да байта ради..

Z>они все проектировали так, чтобы людям было удобнее ее использовать.
То есть, единственное возражение "не удобно использовать"?
Ок.

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

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

S>>foo() использует локальные данные класса А, то что ты заставил ее работать через паблик интерфейс не меняет сути.
IB>Меняет. В одном случае все взаимодействие проходит через публичный контракт, а в другом нет, как следствие, в одном случае метод защищен от внутренних изменений класса (и наоборот), а в другом не защищен.
Его не надо защищать от этого. Он имеет полное право обращаться к этим данным.

S>>Это не я ошибаюсь. Это была цитата.
IB>Просто она была не к месту. =)
Значит ты ее не прочел.

S>>Разница в трактовке роли внутренних связей. Но против этого мне нечего возразить, убедил.
IB>То есть, за DI ты признаешь право уменьшить звязность путем вынесения внутренней связи во внешний контракт, а за просто выносом метода — нет?
Я признал то что твоя трактовка непротиворичива. Однако она не соответствует тому, как трактуют связность инструменты разработчика Visual Studio, Corillian. Внутренние связи, которых ты так сильно боишся там не учитываются. И это выглядит логично, связность не влияет на рантайм, эта характеристика важна при внесении изменений в код и для использования этого кодв. Вносить изменения в класс, большая часть логики которого раскидана по хелперам в соответствии с твоим принципом неудобно. Пользоваться — тоже.

S>>Черным по зеленому написано сначала определяешь ответственность, потом на этом критерии принимаешь решение что включать, а что нет.
IB>Что мешает определить ответственность как "все что делает эта программа"?
Мне? Здравый смысл.

S>> Тут в другой ветке обсуждали дизайн System.String (http://www.rsdn.ru/Forum/message/3031451.aspx

Автор: Ziaw
Дата: 22.07.08

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

S>>Почему это. Ты эту фразу уже раз шесть повторил как заклинание и не разу не объяснил, где же там конкретно контроль теряется? Компилятор соответствие типов или наличие членов престает там контролировать?
IB>Компилятор перестает следить за доступом к приватным переменным.
Неубедительно. У тебя есть заклинание "только через публичный контракт" — поэтому для тебя доступ к приватным переменным, это трагедия. У меня такого заклинания нет, я все проверяю на критерии "нельзя ли все это сделать еще проще", и "удобно ли этим пользоваться".

S>>Это была твоя проблема, что ты не можешь себя сдерживать в рамках приличий.
IB>Что я такого неприличного написал?!
Даже не заметил...

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

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

S>Его не надо защищать от этого.
Надо.

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

S>Я признал то что твоя трактовка непротиворичива.
Это не моя трактовка, это общепринятая, из википедии.

S>Однако она не соответствует тому, как трактуют связность инструменты разработчика Visual Studio, Corillian.
Очень даже соответствует. На твоем же примере VS показала, что Maintainability Index у класса с вкряченным методом хуже. Какие тебе еще доказательства нужны?

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

S>Пользоваться — тоже.
На вкус и цвет. Для ярых приверженцев определенного стиля есть методы расширения.

S>Мне? Здравый смысл.
Ну, собственно, с чего начали — наш формальный критерий называется "здравый смысл". Я не отрицаю, штука полезная, но на формальный критерий не тянет никак.

S>А на мой взгляд — нет.
То есть, все возражения свелись к мелкому неудобству при использовании.

S>У тебя есть заклинание "только через публичный контракт"
Это не заклинание, это фактор который ты упорно игнорируешь. За всю дискуссию ты не привел ни одного возражения, просто молча пропускал, поэтому я вынужден был повторять это снова и снова.

S>Считаю дискуссию исчерпаной. Спасибо.
Заходите еще..