Строганцев Антон#3
Conversation
| for (const auto& operation : _unarys) | ||
| if (std::strncmp(operation->getSymbols().c_str(), symbols.c_str(), operation->getSymbols().size()) == 0) | ||
| return operation.get(); | ||
| return nullptr; |
There was a problem hiding this comment.
можно использовать std::find
только нужно перегрузить оператор ==
можно классы IUnaryOperation, IBinaryOperation,... унаследовать от общего класса с перегруженным ==, равенство можно проверять через getSymbols
Правда вопрос, что делать с унарным и бинарным минусом (dynamic_cast?)
There was a problem hiding this comment.
Да, так можно было сделать, но две эти функции все равно нельзя было бы объединить в одну, т.к. для корректного анализа вводимых данных парсер ожидает в зависимости от предыдущего токена операцию конкретного типа (это как раз таки сделано во избежание конфликта операций разных типов, имеющих одно обозначение, как "-").
There was a problem hiding this comment.
тут проще добавить поле с уникальным id (для каждого нового класса) и делать проверку по нему
| Operations() | ||
| { | ||
| _unarys.emplace_back(new UnaryMinus()); | ||
| _unarys.emplace_back(new Sinus()); | ||
| _unarys.emplace_back(new Cosinus()); | ||
|
|
||
| _binarys.emplace_back(new BinaryPlus()); | ||
| _binarys.emplace_back(new BinaryMinus()); | ||
| _binarys.emplace_back(new Multiplication()); | ||
| _binarys.emplace_back(new Division()); | ||
| _binarys.emplace_back(new Pow()); | ||
| } |
There was a problem hiding this comment.
Конструктор копирования, оператор присваивания наверно тоже нужно сделать приватными. Если этого не сделать, ведь их можно будет вызвать?
There was a problem hiding this comment.
Да, это действительно стоило сделать.
| TUnarys _unarys; | ||
| TBinarys _binarys; |
There was a problem hiding this comment.
Казалось бы _unarys, _binarys можно сделать статическими, все остальные методы тоже. Тогда получается можно и без паттерна Singleton можно обойтись? Или нет? А если можно обойтись, то почему (и в каких случаях) это хуже?
There was a problem hiding this comment.
В принципе, любой шаблон проектирования имеет более "топорные" аналоги. В данном случае замена на статические списки и правда не дала бы заметных изменений, но существуют ситуации, например, где экземпляр класса имеет промежуточные состояния, для которых также бы пришлось заводить отдельные переменные и неиспользуемые пользователем (приватные) методы, что привело бы к загромождению рабочего пространства и возможным ошибкам использования сущности.
2 participants
No description provided.