Что лучший способ состоит в том, чтобы разделить опасения за этот код?
Необходимо осмотреть заголовок PE .dll, так как это в конечном счете, что Windows делает так или иначе.
Принятие у Вас есть указатель на .dll's IMAGE_OPTIONAL_HEADER (можно или использовать dbghelp's ImageNtHeader функция с дескриптором к .dll, загруженному через LoadLibrary, или попытаться найти его сами, если Вы будете знать расположение .dll сами), Вы захотите посмотреть optional_header->DataDirectory[IMAGE_DIRECTORY_ENTRY_EXPORT], найти таблицу экспорта относительно дополнительного заголовка со смещением там, затем обойти таблицу экспорта (это IMAGE_EXPORT_DIRECTORY).
Для funsies, назад совместимое изображение PE начинается с IMAGE_DOS_HEADER; смещение к эти IMAGE_NT_HEADER IMAGE_DOS_HEADER::e_lfanew, и эти IMAGE_OPTIONAL_HEADER встраивается в заголовок NT.
4 ответа
Как продолжение моего первоначального комментария :) ... В настоящее время лучшим вариантом является третий вариант, но если ситуация станет более сложной, вы можете выбрать второй, добавив при этом методы фасада для выполнения заранее заданных последовательностей:
Policy policy = new Policy();
policy.Status = Active;
policyManager.InactivateAndUpdate(policy);
//methods in PolicyManager
public void Inactivate(Policy policy)
{
// possibly complex checks and validations might be put there in the future? ...
policy.Status = Inactive;
}
public void InactivateAndUpdate(Policy policy)
{
Inactivate(policy);
Update(policy);
}
InactivateAndUpdate - это своего рода метод фасада, который предназначен только для сделайте вызывающий код немного более аккуратным, при этом позволяя методам, выполняющим фактическую работу, быть отдельными задачами (что-то вроде нарушает единую ответственность за методы, но иногда вам просто нужно быть прагматичным!). Я намеренно называю такие методы в стиле X и Y, чтобы выделить их как выполняющие две задачи.
Затем метод InactivateAndUpdate позволяет вам приступить к реализации шаблонов стратегии или разделению реальных методов реализации на объекты команд для динамической обработки или любой другой архитектуры, которая может стать возможной в будущем.
Я определенно выбрал бы 3-й вариант по причинам, о которых вы упомянули:
объект политики сохраняет свой собственный состояние, а затем используйте класс менеджера сохранить информацию в база данных
Также взгляните на шаблон репозитория . Он может заменить ваш PolicyManager .
Что бы я сделал:
Создайте репозиторий, который сохраняет и извлекает политики. (PolicyRepository)
Если у вас есть сложная логика, которая должна выполняться для активации / деактивации политики, вы можете создать для этого службу. Если этой службе требуется доступ к базе данных, вы можете передать ей PolicyRepository, если это необходимо. Если не задействована никакая сложная логика, а активация / деактивация политики - это просто вопрос установки флага в значение false или true, или если задействованы только члены класса политики, то почему «Активирован» не является простым свойством Политики класс, который вы можете установить в false / true? Я бы создал службу только в том случае, если задействованы другие объекты или если для активации или деактивации политики требуется доступ к БД.
Если статус является частью состояние класса Policy , тогда Policy также должен иметь метод Inactivate - это просто базовая инкапсуляция. Объединение нескольких классов в одну ответственность по крайней мере так же плохо, как предоставление одному классу нескольких обязанностей.
В качестве альтернативы, статус можно рассматривать как метаданные о Политике , не принадлежащих к политика , но в PolicyManager . Однако в этом случае политика вообще не должна знать свой собственный статус.