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

O>Как эта проблема решается или должна решаться архитектурно ?

Кажется, еще никто не упоминал про anemic-like подход, когда класс-обертка остается примитивным DTO, а всякая обработка реализуется в виде внешних классов-"алгоритмов". Тогда досыпаем себе алгоритмов, исходя из поребностей проекта, а класс-обертка остается неизменных во всех проектах.

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

MD>Кажется, еще никто не упоминал про anemic-like подход, когда класс-обертка остается примитивным DTO, а всякая обработка реализуется в виде внешних классов-"алгоритмов".
это называется C-style ;=)

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

O>Приветствую, коллеги !

O>Предлагаю пофилософствовать на следующую тему.

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

• обертка над системными функциями
  
• абстракция от операционной системы (для портабельности или юнит-тестированности других модулей, к примеру)

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

Registry
{
  Key ReadKey(..)
}

RegistryInfoNotifier
{
  SendRegistryKeyOverEmail(Key, email)
}

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

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

O>>Как эта проблема решается или должна решаться архитектурно ?
O>По моему банальное наследоваие
Причем лучше — от абстрактного класса...

O>>>Как эта проблема решается или должна решаться архитектурно ?
O>>По моему банальное наследоваие
LVV>Причем лучше — от абстрактного класса...
в данном случае необходимости нету, а я слишком ленив чтобы тайпать код без необходимости

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

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

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

5er>Я за компонентную архитектуру.
5er>В приведенном примере я бы создал компонент для работы с реестром.
5er>Нужен backup/restore — кверишь соответствующий интерфейс.
5er>Нужна работа с параметрами — кверишь соответствующий интерфейс.
5er>А что там внутри сидит, супер-мега-продуманный класс или просто вызовы API функций в принципе все равно.
Поздравляю, вы только что изобрели COM

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

U>Здравствуйте, Mr.Delphist, Вы писали:

MD>>Кажется, еще никто не упоминал про anemic-like подход, когда класс-обертка остается примитивным DTO, а всякая обработка реализуется в виде внешних классов-"алгоритмов".
U>это называется C-style ;=)
Не, это называется процедурное программирование. Только каждая процедура завёрнута в свой класс, чтобы это можно было называть модным словом

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

O>Как эта проблема решается или должна решаться архитектурно ?

Любая либа хороша, если она облегчает решение типичных задач . В данном случае, это прочитать значение, записать значение, удалить значение. А когда начинается тонкие операции с реестром, где возможностей либы не хватает, то не надо плодить монстра, который бы умел все. Ибо в конечном счете мы получим весь набор функций API, только в профиль. С той проблемой, что функции API лучше документированы и принципы их работы знает не один человек. Уместнее посчитать, что данный код специфичен для данного приложения и написать его на голом API. И назвать его в терминах самого проекта (не просто там RegOpenKeyWithAccessMask, а например CreateUserSecurityKey). Конечно, если потом увидишь, что фрагмент кода дублируется, то ничто не помешает выделить еще одну функцию.