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

S>У строки нет обязанности хранить строки. Строка хранит в себе данные (символы) из которых она состоит, если она не пуста. Копирование, сравнение строк, поиск подстрок — совершенно логичные операции для строки, как для владельца данных (символов) с которыми фактически происходят манипуляции, потому что строка в данном случае является информационным экспертом для выполнения этих операций.

На мой взгляд "хранение строки", естественно, подразумевает "хранение символов", а также, исходя из определения "информационного эксперта"*, то, что ты описал, и есть концепция "объект — есть данные + методы для их обработки", как, собственно, я и говорил. Хорошо, а при чем тут SRP? Как его ввернуть в эту простую и понятную концепцию? Где тут "единственная обязанность (ответственность), которая есть причина для изменения"? Вот что мне непонятно.

________________________________
* Определение из "Википедии", откуда ж еще: "Using the principle of Information Expert a general approach to assigning responsibilities is to look at a given responsibility, determine the information (выделение — мое) needed to fulfill it, and then determine where that information is stored". GRASP_(object-oriented_design) // Wikipedia, English. Информация — и есть данные. Согласно этому определению обязанности определяются исходя из данных объекта.

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

S>...Лучше держать такие вещи в отдельных внешних классах. SRP в полный рост.

Не очень понял, ты предлагаешь определить строку просто как перечисляемое множество символов, а все операции вынести в отдельные классы? Тогда и будет SRP?

Здравствуйте, Аноним, Вы писали:

А>На мой взгляд "хранение строки", естественно, подразумевает "хранение символов", а также, исходя из определения "информационного эксперта"*, то, что ты описал, и есть концепция "объект — есть данные + методы для их обработки", как, собственно, я и говорил. Хорошо, а при чем тут SRP? Как его ввернуть в эту простую и понятную концепцию? Где тут "единственная обязанность (ответственность), которая есть причина для изменения"? Вот что мне непонятно.

Чтобы это понять нужно ответить на вопрос: какая обязанность у строки. Быть строкой, должно быть. Не знаю как лучше это сказать. А что значит быть строкой? Что умеет строка? А ЧЕРТ ЕГО ЗНАЕТ! У объекта должно быть поведение, поэтому давайте поручим строке выполнять базовые строковые операции. А что? Эксперт? Эксперт. Строка в себе хранит символы из которых состоит вот пусть с ними и работает. Сущность "строка" искусственная, поэтому вызывает дискомфорт. А вот примеры из книжек по ООП про Автомобиль или Лампочку не вызывают, потому что они настоящие и автомобиль совершенно точно имеет скорость и может ездить, а лампочка включаться и светить, а где вы видели строки, которые умеют сравнивать себя с другими или парсить? о_О Может в этом всё дело.

Здравствуйте, Аноним, Вы писали:
А>Не очень понял, ты предлагаешь определить строку просто как перечисляемое множество символов, а все операции вынести в отдельные классы? Тогда и будет SRP?
Ага. Ну, то есть всегда есть вопрос об оформлении бинарных операторов, но в целом идея именно такая.

Здравствуйте, Аноним, Вы писали:

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

S>>...Лучше держать такие вещи в отдельных внешних классах. SRP в полный рост.

А>Не очень понял, ты предлагаешь определить строку просто как перечисляемое множество символов, а все операции вынести в отдельные классы? Тогда и будет SRP?

Например сейчас во фреймворке сравнение строк реализует класс StringComparer. В классе String есть методы Equals, CompareTo и пр, думаю (сейчас проверить к сожалению не могу) внутри этих методов используется StringComparer.

Тут мы имеем с одной стороны принципы хорошего дизайна, с другой — удобство использования. Идеальный код должен учитывать и то и другое.
Класс String, реализуя интерфейсы IComparable<string> и IEquatable<string>, берёт на себя дополнительную ответственность (по сравнению строк), но так как эта ответственность делегируется классу StringComparer, то это можно считать небольшим нарушением SRP в пользу удобства использования.

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

V>>Что не понятно? В таких случаях для выделения памяти под переменную "i" обычно фабрику не применяют, хотя теоретически это вполне возможно. По твоим словам раз фабрика полезна, значит и в таких случаях должна применятся.
G>Ты передергиваешь. Любой паттерн нужен для решения конкретной задачи. Нету задачи — использование паттерна бессмысленно. Ты приводишь пример, в котром нету задачи, которая решается конкретным паттерном.
G>То что у тебя не такая задача — не проблема паттерна.
Если проблемы применения паттерна не связывать с паттерном, то с чем тогда свзязывать? С кривыми руками программиста? Сформируй объективно причины почему в моей примере применять паттерн фабрика для переменной i неразумно, может тогда начнешь с логикой дружить. Может даже до тебя дойдет, что четкой границы нет ни не может быть, так чтоб вот в этой сложной ситуации нужно применять фабрику, а для всех более простых ситуаций фабрику применять нельзя. Всё программирование состоит из компромиссов, у всякого проектного решения есть свои + и -. А если читать только книжки то действительно, нет недостатков у паттернов. Продолжай читать книжки.

G>Ну приведи пример, где паттерн приносит вред. То есть есть походящая для паттерна задача и его применение реально что-то ухудшает. Только не визитор, у визитора проблема не в самом патетрне.
Ага, у тебя "подходящая" уже неявно предполагает что ничего плохого нету
Пример с фабрикой для переменной i тебя не удовлетворил? Ты не знаешь как туда прикрутить фабрику? Надеюсь это для тебя посильно в принципе иначе просто нет смысла продолжать. Рассматривая паттерны мы не имеем права игнорировать визитор. Твоя трактовка проблем визитора меня просто шокирует.

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

G>У меня-то как раз опыт есть, а у тебя видимо нет. Ты приводишь пример для фабрики, даже не понимая зачем фабрика нужна.
Так всё таки есть у паттернов цели, преимущества и недостатки? А то я с дуру подумал что просто проблемы с созданием переменной i в рантайме при помощи фабрики. Сам же настаиваешь на рассмотрении паттерна не более чем приема программирования. Запихиваешь ее в класс, а класс возвращает фабрика , еще прикрутить итератор на всякий случай и вообще супер пример для вредного применения паттерна фабрика получится. Если ты с этим не согласен то дальнейшие обсуждения бесполезны, с точки зрения твоей любимой формальной логики. В приведенном мной примере паттерн фабрика может быть применен. Точка. Никаких других точек зрения не рассматривается. Все нюансы и недостатки такого проектного решения в качестве самостоятельного домашнего задания. Удачи.

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

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

V>>>Что не понятно? В таких случаях для выделения памяти под переменную "i" обычно фабрику не применяют, хотя теоретически это вполне возможно. По твоим словам раз фабрика полезна, значит и в таких случаях должна применятся.
G>>Ты передергиваешь. Любой паттерн нужен для решения конкретной задачи. Нету задачи — использование паттерна бессмысленно. Ты приводишь пример, в котром нету задачи, которая решается конкретным паттерном.
G>>То что у тебя не такая задача — не проблема паттерна.
V>Если проблемы применения паттерна не связывать с паттерном, то с чем тогда свзязывать? С кривыми руками программиста?
Именно

V>Сформируй объективно причины почему в моей примере применять паттерн фабрика для переменной i неразумно, может тогда начнешь с логикой дружить.
Я дружу с логикой, а у тебя с этим проблемы. Ты написал код, вот ты и обосновывай.

V>Может даже до тебя дойдет, что четкой границы нет ни не может быть, так чтоб вот в этой сложной ситуации нужно применять фабрику, а для всех более простых ситуаций фабрику применять нельзя. Всё программирование состоит из компромиссов, у всякого проектного решения есть свои + и -. А если читать только книжки то действительно, нет недостатков у паттернов. Продолжай читать книжки.
Я уже прочитал нужные книги. Решения знаешь почему так называются? Потому что они решают определенную задачу. Если нет задачи, то типовое решение применять незачем.

G>>Ну приведи пример, где паттерн приносит вред. То есть есть походящая для паттерна задача и его применение реально что-то ухудшает. Только не визитор, у визитора проблема не в самом патетрне.
V>Ага, у тебя "подходящая" уже неявно предполагает что ничего плохого нету
Именно, см выше про "решение".

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

V>Твоя трактовка проблем визитора меня просто шокирует.
Это не моя трактовка. Expression problem существует объективно, паттерн visitor существует именно из-за нее. То что ты находишь недостатки в визиторе говорит лишь о том что в некоторых языках expression problem не решается.

G>>У меня-то как раз опыт есть, а у тебя видимо нет. Ты приводишь пример для фабрики, даже не понимая зачем фабрика нужна.
V>Так всё таки есть у паттернов цели, преимущества и недостатки?
Еще раз: паттерны решают задачи. Нету задачи — паттерн лепить бессмысленно.

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