Здраствуйте, пишу калькулятор с применением принципов SOLID, возникла такая трудность:

Есть абстрактный класс Операции и его наследник класс MathOperators



есть также класс ActionMathOperation который использует в качестве поля экземпляр класса Operations 


Что нужно прописать в переопределённом методе DoOperation, что бы в методе ActionMathOperation класса ActionMathOperations можно было вызвать математические методы(Sum/Divide/Subtract/Multiply)??
класс Operations не должен содержать перечень допустимых методов, по скольку если потребуется внести изменения , то изменения должны вносится только в класс MathOperators!!(фото прикреплю там схема классов Operations and MathOperators)

Присоединённый файл ( Кол-во скачиваний: 0 )
 class.PNG 92,07 Kb

1) У метода DoOperation параметр поставь строковый
2) В ActionMathOperation при вызове DoOperation подставляй в параметр переменную MathAction
3) В самом метода DoOperation так же через switch...case сравнивай значение параметра и вызывай нужную функцию

Этот ответ добавлен с нового Винграда - http://vingrad.com

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

Поясню такую не всем понятную тонкую вещь, что такое ООП и почему оно популярно и где его хорошо использовать, где не очень.
ООП не потому круто, что оно МОДЕЛИРУЕТ явления. Оно круто, потому что оно подстраивается под наш язык. Не все могут думать математически, во многих случаях люди, особенно потупее, думают предложениями и языком. В языке есть подлежащие и сказуемые. Поэтому человеку КАЖЕТСЯ, что мир состоит из объектов и их поведения. У нас даже ВЕТЕР ДУЕТ. Это бессмыслица, но язык требует жертв. Поэтому в нашем языке появляется объект "ветер", который умеет выполнять действие "дуть". Хотя представление о процессе говорит, что нет отдельного объекта и действия.

Поэтому, вот следите за мыслью: ООП лучше делать там, где подлежащие и сказуемые мы хорошо представляем. А вот с операцией и с оперированием происходит какая-то ерунда. Мы умеем называть операцией вычитание, да. Но вычитание - это то же что "вычитать". И строя на ООП такую архитектуру, вы все время упираетесь в вопрос, класс это или его поведение?
Сишарп отлично работает с двумя парадигами, с функциональной тоже. Поэтому советую взглянуть в таких случаях на предтавление задачи иначе.
Вот с ходу решение вашей задачи. (Просто набираю не проверяя. Надеюсь, логику поймете, а возможные ошибки простите).



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

Теперь если поняли суть, то можно к ООП перейти. На самом деле в плюсах например, виртуальные функции - это по сути словарь, который я выше показал. Т.е. там таблица виртуальных функций. И сама иерархия объектов по сути реализовывает словарь, когда подменяются указатели на функции. Если хотите с помощью ООП это реализовать, то логика должны быть похожей. Виртуальная функция должна быть одна в базовом объекте, а наследники переопределяют. Т.е.:



А наследники - конкретные операции:


Далее делаете что-то вроде фабричного метода, в котором как угодно делаете порождение объектов. Можете switch использовать или опять же словарь. Но допустим switch:



И далее просто делать вызов после получения операции:


Заметили насколько больше плясок с ООП, чем просто со словарем? Потому что не подходящее средство, а механизм работы в принципе тот же.
Хотите, чтобы каждый наследник возвращал и словами что он делает ("Сумма чисел составляет: " и т.д.), переоределяйте еще методы, ToString() или что-то другое свое.  

Этот ответ добавлен с нового Винграда - http://vingrad.com

все вышесказанное верно и замечательно, НО...
100 пудов автору поста задали задачу в технаре или универе или т.п., и тогда препод ожидает, что задача будет решаться изучаемыми в настоящее время методами и средствами, а значит "умничать" - равносильно списать из инета и схлопотать "незачет".
это я сужу по себе, с одной лишь поправкой - в мою студенческую бытность инета не было и все работали мозгом, так вот мои преподы никак не могли усвоить истину, что мой мозг не хуже их, а в чем-то и лучше, в итоге постоянно страдал за "умничество"

Этот ответ добавлен с нового Винграда - http://vingrad.com

Может быть. Но если не выходить за рамки ООП, то я показал как с помощью ООП решать задачу. Даже в этом случае у автора ошибка.

Объектно-ориентированное проектирование - простая на самом деле вещь. Вообще, я бы советовал научиться для начала хорошо проектировать реляционные базы данных, а после них учится проектировать классы. Там многое аналогично.

В ООП надо всего лишь определять общее и частности. Общее в базовый класс, частности в наследники. И при этом представлять смысл, а не коробочки и контейнеры с алгоритмами. Смысл - это то, что формулируется. Если люди начинают себе представлять код как механизм, получаются казусы в проектировании.

Когда автор думал о наследовании, он начинал видим одумать так: есть операции, есть более конкретные - математические операции. Но при этом думал множествами операций. Когда как если предположить ось наследования в математических операциях, то надо рассуждать так: есть НЕКИЕ операции. Каждая из которых выполняется ПО СВОЕМУ. Т.е. класс операций должен представлять одну операцию, в которой будет виртуальный (абстрактный) метод, который будет выполнять по своему каждая операция.

А он классы сделал множествами операций. В результате в MathOperations наделал отдельными методами то, что делать должна каждая отдельная операция. Т.е. никакого смысла и толка он наследования не осталось. И далее у него случилась несостыковка, как же эти методы взять и вызывать красиво при наследовании.
Никак. Сшить франкенштейна можно, делая пару раз дерево из if-ов или switch. К ООП это не имеет отношения.

Этот ответ добавлен с нового Винграда - http://vingrad.com

не факт, может быть он мыслил математическими, логическими и черт-знает-еще-какими операциями, и хотя каждая из групп тоже в принципе состоит из множества операций - делать их отдельными классами не всегда целесообразно.
у меня в практике был такой пример - составление блок-схемы некоего бизнес-процесса, так я тоже не стал делать отдельные блоки на каждый чих, а сделал (например) один блок "функция" и в нем уже указывалась нужная функция и выбирались аргументы.

Этот ответ добавлен с нового Винграда - http://vingrad.com

В смысле не факт? Сам механизм виртуальных функций по сути всего лишь заменяет ифы и позволяет однообразно вызывать разные функции.

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

Смотрите. Если от множества наследуется множество, Operations -> MathOperations - то вы "не пробъете" через иерархию наследования никакие полезные методы. Я по крайней мере таких не представляю.
Да я вообще слабо понимаю код у автора, потому что Operations только по названию множество, а по телу - одна операция.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Ладно, ок. Соглашусь, что я просто не понимаю код автора. Может у него не стояла задача, использовать наследование.
Но тогда Operations - лишний класс. Два поля типа double намекают, что это математическая операция. В MathOperations вставить работу со словарем как у меня первый пример с делегатами на уже созданные методы. Или хотя бы switch. В методе DoOperation. И, конечно, передавать текстовое имя, не double.

Что написано в ActionMathOperations даже комментировать сложно. Выкинуть всё. Передать в объект MathOperations значения и вызвать DoOperation передав имя операции.

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

Этот ответ добавлен с нового Винграда - http://vingrad.com

1. По поводу double в DoOperations, то я в тот момент экспериментировал, что из этого получится...
2. По поводу названия класса Operations, до этого там был не один метод, а перечисление абстракт. матем. методов...а в классе MathOperations их переопределял,и в классе ActionMathOperations создавал экземпляр класса и спокойно через switch использовал, но препод, сказал что так не должно быть, и что надо использовать принцип Dependency inversion principle..
3. jsharp36 и chupachups, спасибо за разъяснения и примеры, когда я только получил это задание, у меня тоже возникало желание сделать каждую мат. операцию отдельным классом, но потом решил пойти как написано в п.2, но увы это оказалось не верным решением.