Expression Tree Code Demo (cont.)
Cpt S 321 Washington State University
Problems you identified last time
• Switch statement in the evaluate method: hardcoded and difficult to evolve
• The algorithm for building the expression tree is not intuitive
• Things are defined in one single file
• The design is very coupled and
confusing
• Not sure if it actually works (precedence etc.)
• Hard to read and understand
• All nodes inherit from an empty
abstract class
• Exceptions are all general
• Limited commenting
• No tests
• Duplicated code
THINGS (NOT PROBLEMS) you identified last time
i.e., Things I disagree with
• Having a class for each node is an overkill
• “cannot handle negative numbers”: Not a problem at this point – this is a featureJ
• “when a number is divided by 0, we will get ∞”: Not a problem – this is a featureJ: Dividing a floating-point value by zero results in positive infinity, negative infinity, or not a number (NaN) according to the rules of IEEE 754 arithmetic.
Summary of solutions
• Throw more descriptive exceptions
• Get rid of the hardcoded operators
• Allow support for new operators without needing to change the logic in every method
• Extract classes into separate files
• Consider operator precedence/associativity
• Parse the expression string and build the expression tree more elegantly
• Get rid of the redundant code
As we go, improve documentation, naming, style
Where do we start?
And in what order do we refactor?
Why is the order important?
STOP!
Before you start improving the design make sure ALL your test cases are PASSING!
Pointers for solutions ExpressionTreeCodeDemo
• Extract classes into separate files
• I.e., Node, ConstantNode, VariableNode, and OperatorNode should be in
their own files.
• How do we implement them?
• How are they related?
• What should each of those contain?
• Operator precedence/associativity (useful):
– How to define them (instance vs class properties)?
– Where to define them Base class (i.e., OperatorNode) versus child classes
(e.g., PlusOperatorNode)?
STOP!
Don’t forget to adapt your test cases and run them – the same number should pass before you continue!
Announcements
• Mid-term letter grades have been posted on BB and myWSU. Percentage is calculated as follows:
• SUM(HW1,HW2,HW3,HW4,Mid-term1)/(40+25) if have a grade for HW4
• SUM(HW1,HW2,HW3,Mid-term1)/(30+25) otherwise
• Letter grade assigned as per syllabus
• Note that not taken into account are:
• bonus points for participation
• reducing points for unjustified absence
• Lunch and Learn with Industry Series
• More bonus points: 2 points if you attend a webinar (per webinar!) and come and talk to me about it during
office hours; +1 if you as a question during the webinar
• You can watch past webinars
• Next webinar:
FRIDAY, OCTOBER 23 @ 12:10 PM
EECS Lunch and Learn with Industry Series: Why consider utility engineering and what employers look for when hiring engineers by Cameron Doneen, Puget Sound Energy
Cameron will share personal experiences that led him to choose a career in the utility industry and provide an overview of the breadth of opportunities offered by this sector.
Pointers for solutions ExpressionTreeCodeDemo
• Get rid of hard coded operators
• Extract the operators in a separate class?
• How to name this one?
• Data structure?
• How to decouple the different operators from the parsing and building the expression tree?
Factory method pattern
Factory Method Pattern
• One of the creational patterns proposed by the Gang of Four’s design patterns
• Typically used when a class can’t anticipate the type of objects it must create (or
should not!)
• How?
• Create a Factory class (ex. OperatorNodeFactory) with a factory method (ex. CreateOperatorNode).
• CreateOperatorNode will return an OperatorNode. • How about the input?
• Move the logic for the creation of nodes in CreateOperatorNode
• The client (i.e., the ExpressionTree class) will only know about OperatorNode
and not the different subclasses
• Don’t forget to adapt your test cases and run them – they should all pass before you continue!