Гарантия нескольких экземпляров объекта

Question

Я действительно не знаю, как правильно назвать этот вопрос. У меня есть определенный сценарий, когда у меня есть объект, который нужно удалять при каждом использовании. Причины этого носят двоякий характер:

1. Я должен гарантировать, что каждая переменная-член (поле) инициализируется до любого нового использования.
2. Я должен гарантировать, что не существует двух методов вызова этого объекта одновременно, поскольку он не является потокобезопасным.

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

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

Так что я придумал решение, которое я нахожу, как чистый и очень странно:

Мой объект разоблачить статические методы, которые имеют в качестве параметров переменные, необходимые для обоих создать новый экземпляр объекта и выполнить метод , Этот статический метод создает экземпляр объекта, а затем вызывает необходимый метод.

Конечно, конструктор является закрытым.

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

Мои вопросы (наконец !, я знаю), являются:

• Есть шаблон, который будет придерживаться моих требований (всегда используя новый экземпляр объекта)?
• Есть ли образец, описывающий мой подход? Или это анти-шаблон?
• Помимо того факта, что объект кажется коллекцией процедурных функций, есть ли у меня другая причина, не имея такого подхода?

Благодарим за любые комментарии.

Answer 1

Как и в случае с вашими объяснениями, это просто синтаксический анализ классов старых процедурных функций. на самом деле это не класс объектов. Я не думаю, что существует какой-либо шаблон ООП, включающий не-ООП-программирование (кроме Singleton?).

В чем смысл такого дизайна с добавлением дополнительной памяти/производительности для создания и уничтожения одноразового объекта использования внутри функций?

Кстати, вы могли бы разделить класс на два класса. Один для ресурса, удерживающий другого для работы на ресурсах. Позвольте клиентам решить наиболее подходящую схему управления ресурсами и передать объект ресурса в методы класса операций.

Answer 2

Вы не говорите, на каком языке вы используете (хорошо использовать тег для этого). В C# я бы сделал следующее:

1. Сделать поля закрытыми и разоблачить их только через свойства.
2. Инициализировать поля при строительстве.
3. Поскольку класс явно должен быть потокобезопасным («должен гарантировать, что не существует двух методов вызова этого объекта одновременно»), сделайте его поточно-безопасным. Защитите изменяемое разделяемое состояние с помощью блокировок.
4. Внесите Dispose pattern, в результате чего клиент несет ответственность за удаление экземпляров.

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

Answer 3

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

1. Если объект имеет один метод, который вы называете на него один раз, то вы можете установить «состояние» внутри объекта, когда он создан, то установить состояние на «используется» состояние после вызова метод. У этого есть различные проблемы, но это возможное решение.
2. Вы можете заставить пользователя «получить токен» для использования объекта. Затем, когда объект используется, он должен передать этот токен, затем объект сравнивает токен с «используемым маркером» и только позволяет ему функционировать, если его нет. Опять же, проблема в том, что она в основном работает только если у вас есть один метод, который вы вызываете только один раз.
3. Вызова распоряжаться внутри самого объекта, по сути destorying любых ресурсов, создавать, поэтому второе использование было бы выбросить исключение ...