-2

When I was trying to write a library for myself that handles the algebraic expressions I encountered a problem. I have three classes: divide, expression, groupexpression. I want to use divide type in expression and group expression. And use expression type in group expression. The problem is I also need to use group expression type in divide class like this:

// * (2x)/(4b)
class Divide{
    //...
    GroupExpression numerator, denumerator;
    //...
}
// * -2Pow(x, 3)
class Expression{
    //...
    Divide pow, multiple;
    //...
}
// * (2x-3ax+Pow(x, 5))/(ax-2x)
class GroupExpression : Divide{
    //...
    vector<Expression> group;
    //...
}

But this does not meet with programing rules that we should declare it first to use it. How to sort this to meet the rules?

I've been thinking about the exception but didn't found any answer. Didn't find any solution on internet because I don't know how to search this problem so I appreciate any help.

Is it possible doing this this?

  • 3
    So division is not a type of expression, but a group expression is a type of division and not a type of expression? This hierarchy is incomprehensible. Are you sure you're using inheritance to model *is-a* relationships? – Silvio Mayolo Dec 12 '22 at 19:59
  • 5
    A more sane hierarchy would be that you have the base `Expression` class. Then you have `GroupExpression` which is an (and inherits from) `Expression`. Then you have the `Divide` expression which is also a (and inherits from) `Expression`, and `GroupExpression` is a *part of* (*composition*) `Divide`. You might want to study more about the common relationships in OOP. – Some programmer dude Dec 12 '22 at 20:05
  • @SilvioMayolo . Well no. If you look correctly the GroupExpression has a type of Expression not division but you're right this will not work and I was looking for another way to do this from the first place if you look correctly to the title of the question. thanks to btilly now I know how to approach this. – ahmady danyal Dec 14 '22 at 07:18

1 Answers1

0

Without knowing a lot more about what you are trying to do, I don't know the right design.

But a typical approach would involve having a BaseExpression class. Then you could have child classes like DivideExpression that have member variables named denominator and numerator which are themselves of class BaseExpression. And those expressions might be concrete instances of another class like ExpressionTerm. But DivideExpression doesn't need to know that detail. All that it needs to know is that they are of type BaseExpression, which was declared first.

And now any methods you want available for all, like printing and evaluation, should be methods on BaseExpression. Going further you can then have a parser to turn a text expression into a parse tree that is then turned into the appropriate Expression objects.

Note that you don't probably don't need a generic GroupExpression because that need is covered by being able to create a recursive tree of specific kinds of expressions. None of which need to know more about their subexpressions other than that they inherit from BaseExpression.

btilly
  • 43,296
  • 3
  • 59
  • 88