Objects by Design Forums Here you can view your subscribed threads, work with private messages and edit your profile and preferences Registration is free! Calendar Find other members Frequently Asked Questions Search Home  
Objects by Design Forums : Powered by vBulletin version 2.3.5 Objects by Design Forums > Main Forums > Object-Oriented Calculator > operator precedence
  Last Thread   Next Thread
Author
Thread Post New Thread    Post A Reply
JSLacar
Junior Member

Registered: Mar 2002
Location: Columbus, OH
Posts: 4

I did something like this in another forum (I'll refrain from naming the site for now until SZ says it's OK for me to plug it ).

That effort followed a less formal process though and we tried doing it using a Test-Driven Development approach and JUnit. Unfortunately, the thread has lost some steam (my fault entirely) but I might pick it up again. It'll be interesting to compare the results of both projects.

From what I've see so far though, I question the appropriateness of having the precedence logic/constants in the Operation class. It doesn't seem to sit well there. Reason: two different calculators may have slightly different ways of handling precedence. Take for example the M$ Calculator: in standard mode, the expression (1 + 2 * 3) evaluates to 9. In scientific mode, the same expression evaluates to 7. If the precedence logic responsibility belonged in the Operation class, how would an Operation distinguish between the two different modes? Are five levels of precedence enough? What happens if we want to add more operations and find we need more precedence levels?

My $0.02...

-Junilu

Report this post to a moderator | IP: Logged

Old Post 04-24-2002 02:53 PM
JSLacar is offline Click Here to See the Profile for JSLacar Click here to Send JSLacar a Private Message Find more posts by JSLacar Add JSLacar to your buddy list Edit/Delete Message Reply w/Quote
SZ
Administrator

Registered: Apr 2001
Location: New York
Posts: 492

You have an important point, Junilu.

I agree that the precedence should be set from outside the Operation classes. It was put inside the operations to minimize knowledge about individual operations outside of themselves (encapsulation). However, an attribute which is relative to multiple operations probably shouldn't be encapsulated this way.

This is easy to refactor by adding a setPrecedence() method to Operation and have the factory method findOperation() in Cpu set the precedence from a lookup table. What should be done is make the precedence table external (text file) to the application since operations can be added more easily this way. In this way, building a calculator can be like assembling the operations you want to support and setting their relative precedence to eachother.

Based on this, it would help to understand how to make a reasonable configuration file (XML is overkill here for such a small application).

Good point.

Report this post to a moderator | IP: Logged

Old Post 04-24-2002 05:00 PM
SZ is offline Click Here to See the Profile for SZ Click here to Send SZ a Private Message Visit SZ's homepage! Find more posts by SZ Add SZ to your buddy list Edit/Delete Message Reply w/Quote
JSLacar
Junior Member

Registered: Mar 2002
Location: Columbus, OH
Posts: 4

Originally posted by SZ:
This is easy to refactor...

Which brings me to my next question: Are there any unit tests for this project or any plans to make some? That would help a lot in the refactoring.

Junilu

Report this post to a moderator | IP: Logged

Old Post 04-24-2002 06:28 PM
JSLacar is offline Click Here to See the Profile for JSLacar Click here to Send JSLacar a Private Message Find more posts by JSLacar Add JSLacar to your buddy list Edit/Delete Message Reply w/Quote
JSLacar
Junior Member

Registered: Mar 2002
Location: Columbus, OH
Posts: 4

Question questionable Value methods?

Dug around a little more and I don't understand why operation-like methods are included in Value. I can somehow see the need for addDigit() and maybe even create() (but why not a constructor that takes a String?) but can't find any justifiable reason to include add() , substract() , etc. I would think that the logic that goes in these methods would be implemented by concrete Operation classes in the execute() method.

Junilu

Report this post to a moderator | IP: Logged

Old Post 04-24-2002 07:41 PM
JSLacar is offline Click Here to See the Profile for JSLacar Click here to Send JSLacar a Private Message Find more posts by JSLacar Add JSLacar to your buddy list Edit/Delete Message Reply w/Quote
SZ
Administrator

Registered: Apr 2001
Location: New York
Posts: 492

Definitely want to get JUnit tests up and running. This is one of the areas that we are looking for contributors.

I will also list some other areas that contributors can really help out at this stage.

Report this post to a moderator | IP: Logged

Old Post 04-24-2002 08:31 PM
SZ is offline Click Here to See the Profile for SZ Click here to Send SZ a Private Message Visit SZ's homepage! Find more posts by SZ Add SZ to your buddy list Edit/Delete Message Reply w/Quote
SZ
Administrator

Registered: Apr 2001
Location: New York
Posts: 492

Since Value is an interface, it is not possible to have a constructor that takes a String. The use of a create() method is consistent with a Factory Method pattern and will work well when dealing with multiple data types - the factory doesn't have to know anything about the type except its name (see the way Operations are created in class Cpu).

I definitely did not want to tie the Operations in with any specific data type, even if it was the best data type for a basic calculator, like BigDecimal for instance. One example why is that it could have forced the Operations to deal with issues such as rounding and precision, which are much better encapsulated within DecimalValue, which implements the divide() operation on the interface Value.

But the bigger reason is that tying a data type in with the Operations would have made it messy to add another data type or even replace the data type at some other time. I originally used Double, didn't like it and had to pull it out. Since the coupling is very high between the data type and the Operations, this can take time to refactor. Better to encapsulate everything in a class which implements the Value interface. Then all the benefits of encapsulation become obvious.

Keep in mind that since the calculator is used as a teaching tool by OBD, it is easier to take certain liberties to make something more "object-oriented". There may be a better design, which I would be happy to consider; conversely, this design may prove itself to be the most extensible, which is largely what object-orientation is about.

Report this post to a moderator | IP: Logged

Old Post 04-26-2002 12:31 PM
SZ is offline Click Here to See the Profile for SZ Click here to Send SZ a Private Message Visit SZ's homepage! Find more posts by SZ Add SZ to your buddy list Edit/Delete Message Reply w/Quote
All times are GMT. The time now is 10:23 PM. Post New Thread    Post A Reply
  Last Thread   Next Thread
Show Printable Version | Email this Page | Subscribe to this Thread

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
 

< Contact Us - Objects by Design >

Powered by: vBulletin Version 2.3.5
Copyright ©2000 - 2018, Jelsoft Enterprises Limited.
Copyright 1999-2005, Objects by Design, Inc.