Есть класс, который реализует некую ф-ть
class Object
У него есть методы, типа
GetName — имя
GetSize — возвращает свой размер без учета детей
GetChilds — возвращает список своих детей

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

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

А>Кто как поступает с такими методами?

Сваливаем в отдельный ObjectHelper

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

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

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

А>Появилась необходимость написать ряд методов, типа расчета размера рекурсивно с учетом всех детей, генерации уникального имени среди детей и т.д
А>Все эти методы могут быть реализованы за счет публичного интерфейса Object, поэтому включать их в класс Object не хочется. Пока свалил их как внешние ф-ции в отдельный фаил ObjectHelper в виде CalcFullObjectSize, GetObjectUniqChildName, но выглядит это не очень красиво...
А>Кто как поступает с такими методами?

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

Child в множественном числе будет Children, т.е. метод правильно должен быть назван GetChildren

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

L>>Сваливаем в отдельный ObjectHelper
A>Главное не забыть задать тот же самый вопрос позднее, когда ObjectHelper превратится в свалку
Очень интересно, почему ObjectHelper должен превратиться в свалку?

L>>>Сваливаем в отдельный ObjectHelper
A>>Главное не забыть задать тот же самый вопрос позднее, когда ObjectHelper превратится в свалку
CRA>Очень интересно, почему ObjectHelper должен превратиться в свалку?
Ок, "если вдруг превратится в свалку". Ну есть у меня подозрения (и даже примеры из опыта) что такое может случиться (с приличной вероятностью).
Само название этому способствует: "Helper". Помогает, ну просто во всем-всем-всем помогает. А позже, обнаруживаешь, что этот Помощник, не просто "помощник", а Помощник в нескольких совершенно конкретных направлениях. И оказывается, что его можно разделить на несколько классов с Бизнесс-Названиями: ObjectSizeCalculator, ObjectChildrenManager, ...
Главное не упустить этот момент.

P.S. Кста, то же самое можно сказать про суффикс "Manager".
P.P.S. Это не более чем мое ИМХО и навязывать его я никому не хочу

А>Все эти методы могут быть реализованы за счет публичного интерфейса Object, поэтому включать их в класс Object не хочется.
Мне все же кажется, что методам CalcFullObjectSize и GetObjectUniqChildName самое место в Object
Плюсы:
— Не плодится дополнительный объект с непонятной зоной ответственности (об этом говорит имя объекта) // имхо, самый главный плюс
— Сам класс может более эффективно решить эти задачи, так как знает свою внутреннюю структуру
— Требуемый для подсчета публичный интерфейс может в будущем измениться // самый неглавный плюс

Минусы:
-- Нарушается принцип "сингл респонцибилити".? ИМХО, это в ответственности класса знать свои "внутренности"


Object -- (скорее всего) пример паттерна Composite.
Если посмотреть на примеры реализации этого паттерна (System.Windows.Forms.Control, XmlDocument, ...) можно увидеть, что операции над своими составляющими чаще всего поручаются именно Композиту, а не внешнему для него классу.

СУВ, Aikin

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

L>>Сваливаем в отдельный ObjectHelper
A>Главное не забыть задать тот же самый вопрос позднее, когда ObjectHelper превратится в свалку

A>Т.е. как временное решение этот способ очень даже хорош. А тем более если проповедовать принцип "делать только то, что нужно в данный момент". Вполне возможно, позднее кандидат на "хозяина" этим методам найдеться сам.

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

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

А>Есть класс, который реализует некую ф-ть
А>class Object
А>У него есть методы, типа
А>GetName — имя
А>GetSize — возвращает свой размер без учета детей
А>GetChilds — возвращает список своих детей

А>Появилась необходимость написать ряд методов, типа расчета размера рекурсивно с учетом всех детей, генерации уникального имени среди детей и т.д
А>Все эти методы могут быть реализованы за счет публичного интерфейса Object, поэтому включать их в класс Object не хочется. Пока свалил их как внешние ф-ции в отдельный фаил ObjectHelper в виде CalcFullObjectSize, GetObjectUniqChildName, но выглядит это не очень красиво...
А>Кто как поступает с такими методами?

Я бы добавил в класс, по сути это методы объекта (если переименовывать — GetFullObjectSize и GetObjectUniqChildName),
просто это будут не простые геттеры, а скрывающие какую-то логику — затем поля и делают доступными через get/set, потому что там может не "return fullObjectSize;".
При таком решении результаты работы методов можно будет кэшировать и, если объект не изменился, выдавать закэшированное значение.
Метод CalcFullObjectSize можно сделать статическим и вызывать его из GetFullObjectSize.

Я бы так поступил.

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

А>Появилась необходимость написать ряд методов, типа расчета размера рекурсивно с учетом всех детей, генерации уникального имени среди детей и т.д
А>Все эти методы могут быть реализованы за счет публичного интерфейса Object, поэтому включать их в класс Object не хочется. Пока свалил их как внешние ф-ции в отдельный фаил ObjectHelper в виде CalcFullObjectSize, GetObjectUniqChildName, но выглядит это не очень красиво...

Действительно не красиво. То что методы могут быть реализованы за счет публичного интерфейса класса вовсе не повод выносить их в отдельный класс. Не следует забывать что объект инкапсулирует не только свое состояние но и поведение, т.е. код. Это собственно и называется инкапсуляцией (данные + код).
В хелпер класс можно выносить аспекты, не свойственные для самого класса. Например, код форматирования данных класса для сериализации.

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

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

S>Действительно не красиво. То что методы могут быть реализованы за счет публичного интерфейса класса вовсе не повод выносить их в отдельный класс. Не следует забывать что объект инкапсулирует не только свое состояние но и поведение, т.е. код. Это собственно и называется инкапсуляцией (данные + код).
S>В хелпер класс можно выносить аспекты, не свойственные для самого класса. Например, код форматирования данных класса для сериализации.

Stump, по вашим словам, получается, что метод "генерации уникального имени среди детей" — это подходящий кандидат на инкапсуляцию в Object?
Мне например кажется, что рекурсивный обход дерева, это не ответственность самого дерева

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

MC>Child в множественном числе будет Children, т.е. метод правильно должен быть назван GetChildren

А ещё правильнее GetChildList.

Здравствуйте, C...R...a...S...H, Вы писали:

CRA>Stump, по вашим словам, получается, что метод "генерации уникального имени среди детей" — это подходящий кандидат на инкапсуляцию в Object?
CRA>Мне например кажется, что рекурсивный обход дерева, это не ответственность самого дерева

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

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



S>Ну с чего ты взял, что "генерации уникального имени среди детей" == "рекурсивный обход дерева" ?
Я так не считаю

S>Но даже если так, дети — это данные объекта. При рекурсивном обходе дерева детей используются какие либо внешние данные? Очевидно нет. И это веский повод инкапсулировать этот метод в данный класс.
Очень интересная тем, может ли сам алгоритм обхода быть внешними данным, а считаю что ДА, так как таких алгоритмов может быть нескально, например: обход начиная с родителя, либо обход начиная с самого нижнего уровня.
Из этого следует что, может существовать функциональность,которая требует различные алгоритмы обхода, следовательно, как написано Вами ниже необходимо создавать strategy или реализовывать IoC.

S>А вот другой пример. Во многих бизнес приложениях есть функциональность, позволяющая настраивать правила нумерации экземпляров сущностей (заказов, накладных и т.п.). Вот это уже повод вынести данную функциональность за пределы сущности. Правда тут понадобится уже не хелпер а что-то вроде strategy или какой нибудь другой IoC.
Выше я рассмотрел пример с алгоритмом обходом дерева (который, является кандидатом на инкапсуляцию) и почему то, я не вижу смысла инкапсулировать в сам объет несколько алгоритмов обхода. И по этому получается придется выносить данный алгоритм в другой класс, а не инкапсулировать. А вот как называть новый класс TreeBypassStategy реализуя стратегю, либо ObjectHelper не реализую оную. Да хоть ObjectManagerService. Главное, то, что алгоритм отделе от Object.

Здравствуйте, C...R...a...S...H, Вы писали:

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



S>>Ну с чего ты взял, что "генерации уникального имени среди детей" == "рекурсивный обход дерева" ?
CRA>Я так не считаю

S>>Но даже если так, дети — это данные объекта. При рекурсивном обходе дерева детей используются какие либо внешние данные? Очевидно нет. И это веский повод инкапсулировать этот метод в данный класс.
CRA>Очень интересная тем, может ли сам алгоритм обхода быть внешними данным, а считаю что ДА, так как таких алгоритмов может быть нескально, например: обход начиная с родителя, либо обход начиная с самого нижнего уровня.
CRA>Из этого следует что, может существовать функциональность,которая требует различные алгоритмы обхода, следовательно, как написано Вами ниже необходимо создавать strategy или реализовывать IoC.

Я говорю здесь об инкапсуляции данных и кода, которой зачастую необоснованно пренебрегают. Увлечение "хелпер" классами хороший пример подобного пренебрежения. Действительно, бывает масса обстоятельств, которые затрудняют подобную инкапсуляцию, и тогда хэлпер представляется наиболее простым решением в лоб. Но в большинстве случаев самое простое решение не самое удачное. Тут говорили, что хэлпер может превратится в помойку, но чаще возникает другая проблема. По мере усложнения кода хэлпера, он начинает влиять на интерфейс класса которому он "помогает". Хэлперу нужно все больше и больше знать о внутреннем состоянии объекта которому он "помогает".
Хелперы увеличивают связность и размазывают логику. В тоже время, часто для таких случаев IoС, например dependency ijection, более удачное решение, поскольку не нарушает инкапсуляцию и порождает меньшую свяность.
Поэтому прежде создавать хэлпер надо (1) хорошенько подумать можно ли этот код оставить в самом классе, и (2) если оставить его там нельзя стоит прикинуть, нет ли более подходящего варианта для этого (observer, service locator и т.п.).

Здравствуйте, C...R...a...S...H, Вы писали:

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



S>>Ну с чего ты взял, что "генерации уникального имени среди детей" == "рекурсивный обход дерева" ?
CRA>Я так не считаю

S>>Но даже если так, дети — это данные объекта. При рекурсивном обходе дерева детей используются какие либо внешние данные? Очевидно нет. И это веский повод инкапсулировать этот метод в данный класс.
CRA>Очень интересная тем, может ли сам алгоритм обхода быть внешними данным, а считаю что ДА, так как таких алгоритмов может быть нескально, например: обход начиная с родителя, либо обход начиная с самого нижнего уровня.
CRA>Из этого следует что, может существовать функциональность,которая требует различные алгоритмы обхода, следовательно, как написано Вами ниже необходимо создавать strategy или реализовывать IoC.

S>>А вот другой пример. Во многих бизнес приложениях есть функциональность, позволяющая настраивать правила нумерации экземпляров сущностей (заказов, накладных и т.п.). Вот это уже повод вынести данную функциональность за пределы сущности. Правда тут понадобится уже не хелпер а что-то вроде strategy или какой нибудь другой IoC.
CRA>Выше я рассмотрел пример с алгоритмом обходом дерева (который, является кандидатом на инкапсуляцию) и почему то, я не вижу смысла инкапсулировать в сам объет несколько алгоритмов обхода. И по этому получается придется выносить данный алгоритм в другой класс, а не инкапсулировать. А вот как называть новый класс TreeBypassStategy реализуя стратегю, либо ObjectHelper не реализую оную. Да хоть ObjectManagerService. Главное, то, что алгоритм отделе от Object.

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

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

А>Пока свалил их как внешние ф-ции в отдельный фаил ObjectHelper в виде CalcFullObjectSize, GetObjectUniqChildName, но выглядит это не очень красиво...

Что именно выглядит некрасиво? И как красиво?

А>Кто как поступает с такими методами?

Делаю хелперы, методы делаю extension, что позволяет привязать их в интеллисенсе к объекту.

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

А>Есть класс, который реализует некую ф-ть
А>class Object
А>У него есть методы, типа
А>GetName — имя
А>GetSize — возвращает свой размер без учета детей
А>GetChilds — возвращает список своих детей

А>Появилась необходимость написать ряд методов, типа расчета размера рекурсивно с учетом всех детей, генерации уникального имени среди детей и т.д
А>Все эти методы могут быть реализованы за счет публичного интерфейса Object, поэтому включать их в класс Object не хочется. Пока свалил их как внешние ф-ции в отдельный фаил ObjectHelper в виде CalcFullObjectSize, GetObjectUniqChildName, но выглядит это не очень красиво...
А>Кто как поступает с такими методами?


можно рассмотреть на обсосанном string

int string.toInt()
int toInt(string)


1. — 2.
Выход простой , складывать их в классы хелперы с нормальными названиями , наприммер ObjectTraversal, ObjectParamExtraxtor, и т.п.
3. Есть еще и третий выход , чтобы класс возвращал гетерами сервисные классы. например:
Object.getIteratorBFS и т.п. Которые реализованны с помощью публичного интерфейса класса но предоставляют функциональность в сторонке от класса.
iterator string.begin()

4. Или как четвыртый вариант , жесткое разделение на классы а потом в прикладном коде использование лекгих фасадов в зависимости от варианта использования.
MyCoolString : public string
{
Int toInt()
{
Helper1::toInt(this);
}
}

5. Не всегда Object вообще дожен появляться в пользовательском коде. Т.е. все детали могут быть скрыты за безопасными с точки зрения инкапсуляции фасадами.
MyCoolString
{
stringDataStorage
stringTraits1
stringTraits2
}



Теперь о самой идее складывания функций хелперов в отдельные классы.

Этот вопрос в програмировании обсуждается на протяжении десятилетий и до сих пор нет однозначного ответа (вспомните кормление вомбата).

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

Минусы разделения:
— Распыление функциональности на много классов, тяжелее в использовании.
— Есть опасность что при изменении Object , придется выносить наружу новые методы для реализации Helpers. Т.е. связь которая казалось совершенно внешней окажется очень интимной в будущем для объекта.

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

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

А>Кто как поступает с такими методами?

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