Нарушает ли обработка памяти принцип единственной ответственности?

SRP : There should never be more than one reason for a class to change

Если у меня есть class A, в обязанности которого входит выполнение taskA. Нарушает ли обработка памяти внутри class A SRP? Если да, то приемлемо ли это? Какие решения у нас есть?

Примечание. Использование delete или a std smart_ptr одинаково, это все еще своего рода обработка памяти (например: мы можем захотеть изменить unique_ptr auto_ptr и т. д.).

Вот как я думал, можно с этим справиться. Я не нахожу его достаточно хорошим, потому что MemoryHandler должен измениться по двум причинам: если A нужно больше атрибутов или если нам нужен другой способ обработки памяти.

Обратите внимание на примеры: обычно у вас будет много методов (функций-членов) и несколько атрибутов (переменных-членов). Мы можем предположить, что owned_ptr — это функтор (алгоритм/паттерн-стратегия) или что-то еще, необходимое для class A и task A.

Пример 1 (cpp):

class A {
   Object* owned_ptr;

public:
   taskA() { ... }
   ~A() { delete owned_ptr; }
};

Пример 2 (cpp):

class MemoryHandler {
   Object* owned_ptr;
public :
   Object* object() { return owned_ptr; }
   ~MemoryHandler() { delete owned_ptr; }
};

class A {
   MemoryHandler data;

public:
   taskA() { ... }
   ~A() { }
};

person Julien__    schedule 24.05.2014    source источник
comment
taskA использует owned_ptr?   -  person T.C.    schedule 24.05.2014
comment
Да, мы можем предположить, что это так (я отредактировал вопрос).   -  person Julien__    schedule 24.05.2014


Ответы (1)


С практической точки зрения обработка памяти в вашем примере не нарушает SRP. Вы следуете стандартному подходу к работе с памятью в вашей среде, что на самом деле не добавляет отдельной ответственности. Вы бы не сказали, например, что создание экземпляров объектов является отдельной обязанностью, и ваш случай не так уж и отличается.

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

person Dave Schweisguth    schedule 24.05.2014
comment
Ну, я действительно думаю, что создание экземпляра объекта - это ответственность ... Я думаю, что класс не должен создавать экземпляры объектов, которые он использует, а запрашивать их: это позволяет инверсию зависимостей. - person Julien__; 07.01.2015