Проверка на корректность операции

@Tochka · Регистрация: 31.07.2012

Студворк — интернет-сервис помощи студентам

Добрый день.

Не знаю как лучше задать вопрос.
Смысл идеи таков:
Есть интерфейс типа данных (IVariable) и наследники от него, например: Number, Complex, Matrix.
Необходимо реализовать функцию сложения Sum(IVariable a, IVariable b), так чтобы можно было определить возможность сложения и вернуть значение IVariable суммы чисел.
Пример:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
#include <iostream>
#include "Math"
 
using namespace std;
 
int main (int argc, char ** args)
{
   Number a (5);
   Complex b (4,2);
   Matrix c (2,2);
   
   cout << a<<"+"<<b<<"="<<sum(a,b)<<endl;
   cout <<b<<"+"<<c<<"="<<sum(b,c)<<endl;
   return 1;
}

Результат:

Bash
1
2
5+4+2i=9+2i
4+2i+{2,2}=нельзя складывать эти типы.

На ум приходит только метод у интерфейса OperationCorrect(int /*Тип операции */, int /* Тип переменной */)
Тогда операцию сложения можно написать так:

C++
1
2
3
4
5
6
7
8
9
const int SUM=1;
IVariable sum(IVariable a, IVariable b)
{
 if(a.OperationCorrect(SUM,b.type)
     return a+b;
 if(b.OperationCorrect(SUM,a.type)
     return b+a;
 return new IErrorSum();
}

Может кто знает более интересней вариант.

P.S. Тип Number ничего не знает про тип Complex и Matrix,
тип Complex и Matrix знают про тип Number.

@gooseim · 01.08.2012, 18:35

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

@Tochka · 01.08.2012, 18:53 **[ТС]**

gooseim, спасибо что подтвердили мою теорию.
А что касается передачи одного параметра, то я наверно не до конца описал задачу, в дальнейшем потребуется переопределить *,/,- и тогда встанет вопрос как разделить, что операция Number*Matrix - является корректной, а Number+Matrix - нет.

Насколько я понимаю это единственный вариант?

@Avazart · 01.08.2012, 18:53

Вариант 1:

C++
1
bool TrySum(IVariable a, IVariable b,IVariable &result);// Возвращает успешность,если успешно результат заносит в result.

Вариант 2:
Реализовать свой класс исключений и ловить их при выполнении операций

C++
1
2
3
4
5
try
  { 
    c=sum(a,b);
  }
catch(myerror &e) { cerr<<e.what()<<endl; }

@gooseim · 01.08.2012, 19:17

Tochka, когда будет другая операция, для нее будет другой виртуальный метод и т.д. Т.е. проверка должна осуществляться в методе операции. Причем в методе производного класса.

Добавлено через 22 минуты
Если делать проверку на валидность в базовом классе, мы нарушим идеологию ООП. Базовый класс не должен ничего знать о своих потомках. И потомки должны знать по минимуму друг о друге.

@Tochka · 01.08.2012, 19:28 **[ТС]**

gooseim, может быть я что-то не понимаю, но я планировал перегрузить операторы вида
"operator Op (IVariable)", а так как, я заведомо не знаю какой тип стоит с лева, а какой с права то предполагал проверку на на знание типа (исходя из неё и переставлять местами элементы).

Avazart, исходя из вашей логики Number+Complex - будет выдавать ошибку, а Complex+Number - будет выдавать правильный вариант?

Добавлено через 2 минуты

Если делать проверку на валидность в базовом классе

В базовом классе будет только чисто виртуальная функция которая будет принимать два параметра, а в потомках необходимо будет её перегружать.

@Nick Alte · 01.08.2012, 19:28

Эта тема - прямо-таки классический пример ситуации, для которой придумали double dispatch.

@gooseim · 01.08.2012, 19:54

Сообщение от Tochka

const int SUM=1; IVariable sum(IVariable a, IVariable b) { if(a.OperationCorrect(SUM,b.type) return a+b; if(b.OperationCorrect(SUM,a.type) return b+a; return new IErrorSum(); }

Такой вариант не покатит. Объект не являющийся IVariable не сможет вернуть сам себя и себе подобных как IVariable. Можно только IVariable& и const IVariable&. Либо сделать конструктор для IVariable для каждого типа. Это опять нарушение ООП. Принимать IVariable тоже не может.

В общем, походу нет красивого решения, как сделать, чтобы операция a + b возвращала тоже самое, что b + a, если b и a разного типа.

Новые блоги и статьи Все статьи Все блоги /
Модель заражения группы наркоманов alhaos 17.04.2026 Условия задачи сформулированы тут Суть: - Группа наркоманов из 10 человек. - Только один инфицирован ВИЧ. - Колются одной иглой. - Колются раз в день. - Колются последовательно через. . .	Мысли в слух. Про "навсегда". kumehtar 16.04.2026 Подумалось тут, что наверное очень глупо использовать во всяких своих установках понятие "навсегда". Это очень сильное понятие, и я только начинаю понимать край его смысла, не смотря на то что давно. . .	My Business CRM MaGz GoLd 16.04.2026 Всем привет, недавно возникла потребность создать CRM, для личных нужд. Собственно программа предоставляет из себя базу данных клиентов, в которой можно фиксировать звонки, стадии сделки, а также. . .	Знаешь почему 90% людей редко бывают счастливыми? kumehtar 14.04.2026 Потому что они ждут. Ждут выходных, ждут отпуска, ждут удачного момента. . . а удачный момент так и не приходит.
Фиксация колонок в отчете СКД Maks 14.04.2026 Фиксация колонок в СКД отчета типа Таблица. Задача: зафиксировать три левых колонки в отчете. Процедура ПриКомпоновкеРезультата(ДокументРезультат, ДанныеРасшифровки, СтандартнаяОбработка) / / . . .	Настройки VS Code Loafer 13.04.2026 { "cmake. configureOnOpen": false, "diffEditor. ignoreTrimWhitespace": true, "editor. guides. bracketPairs": "active", "extensions. ignoreRecommendations": true, . . .	Оптимизация кода на разграничение прав доступа к элементам формы Maks 13.04.2026 Алгоритм из решения ниже реализован на нетиповом документе, разработанного в конфигурации КА2. Задачи, как таковой, поставлено не было, проделанное ниже исключительно моя инициатива. Было так:. . .	Контроль заполнения и очистка дат в зависимости от значения перечислений Maks 12.04.2026 Алгоритм из решения ниже реализован на примере нетипового документа "ПланированиеПерсонала", разработанного в конфигурации КА2. Задача: реализовать контроль корректности заполнения дат назначения. . .

@gooseim 516 / 421 / 92 Регистрация: 23.09.2010 Сообщений: 1,165
	01.08.2012, 18:35
	Можно, например, сделать метод интерфейса IVariable, который принимает единственный параметр - второй операнд суммы ли других операций. Этот метод переопределить в разных классах. Каждый класс будет проверять, является ли переданный параметр известным ему типом (тип можно хранить как атрибут или просто проверять на dynamic_cast, первый вариант, все же думаю лучше). Это решение похоже на ваше, но оно позволяет не знать классам того, что можно не знать. Что более логично. 0

@Tochka 0 / 0 / 0 Регистрация: 31.07.2012 Сообщений: 6
	01.08.2012, 18:53 [ТС]
	gooseim, спасибо что подтвердили мою теорию. А что касается передачи одного параметра, то я наверно не до конца описал задачу, в дальнейшем потребуется переопределить ,/,- и тогда встанет вопрос как разделить, что операция NumberMatrix - является корректной, а Number+Matrix - нет. Насколько я понимаю это единственный вариант? 0

@gooseim 516 / 421 / 92 Регистрация: 23.09.2010 Сообщений: 1,165
	01.08.2012, 19:17
	Tochka, когда будет другая операция, для нее будет другой виртуальный метод и т.д. Т.е. проверка должна осуществляться в методе операции. Причем в методе производного класса. Добавлено через 22 минуты Если делать проверку на валидность в базовом классе, мы нарушим идеологию ООП. Базовый класс не должен ничего знать о своих потомках. И потомки должны знать по минимуму друг о друге. 0

@Nick Alte 1675 / 1047 / 174 Регистрация: 27.09.2009 Сообщений: 1,945
	01.08.2012, 19:28
	Эта тема - прямо-таки классический пример ситуации, для которой придумали double dispatch. 0

Опции темы