Ian Giblin wrote:
I am an experienced C programmer, learning C++ by writinging a
mathematical toolkit in the framework of a script interpreter. I am
posting here to ask for advice (or references) on the object design
and implimentation.
The first thing to recommend that comes to mind is comp.object
newsgroup. OO Design has common principles that are not necessarily
language-specific. Check it out.
Currently I have a portable "ScriptSession" class which contains the
mechanics of looping with a user prompt, parsing a sentence and
handling syntax errors, etc., and I wan this to be a class I can use
for any script interpreter.
One of the core functions is the execution of a command sentence. This
necessarily involves some mathematical commands which should not be
part of "ScriptSession" so I started by overloading a method called
interpret, which is virtual in the base class:
class ScriptSession
{
public:
...
virtual bool ScriptSession::execute(void);
I thought you said "a method called interpret"... And a small note on
C++ syntax: you don't need a fully qualified name in a class definition.
You usually write
virtual bool execute();
(oh, yes, 'void' is also superfluous).
}
I have then written a method within the final application which
overload this,
The correct term is "overrides".
but it needs to know a lot about the internals of the
ScriptSession class so it has become rather ugly and feels like it is
voilating encpasulation and so on.
Yes, it rather sounds like a bad design.
Also, I have put everything in
here, even basic stuff like interpretation of the command "exit" which
is universal, so that won't do.
Well, without seeing more of your 'ScriptSession' class (at least its
interface, the implementation probably doesn't matter much) it is not
clear what you mean that it needs to know and what exactly are those
"internals". Can't you provide access to those internals through some
protected functions?
I bought "Design Patterns" (Gang of Four) but none of the patterns
seem to really fit this nicely. Or maybe I'm just missing some of the
important stuff. I apologise if I haven't explained the problem
clearly enough; that's part of the problem of course.
"Design Patterns" is by no means a "recipes for all occasions" type of
book. You learn the most common ones so you can recognise patterns in
your own code and describe them and later apply them.
Any advice would be appreciated. Thanks,
Ian Giblin.
Well, take a look at comp.object and possibly ask them for an example
of an interpreter framework that you could extend. Perhaps somebody
here knows about it too (I don't), my colleagues whenever an interpreter
is needed all wrote their own, which seems like an overkill, but that's
up to them.
Shake the Web (or google for "interpreter C++ framework"), see if
something falls out. I bet other folks have written something in that
area. While it is a good idea to write one for training, it isn't so
good to get stuck on design when your actual goal is the language.
Take a look at "Advanced C++. Programming Styles and idioms" by James
Coplien. It's relatively old, but it's a good from design point of
view. Helped me to figure some C++ stuff out. It assumes you know C++
to some extend, of course.
Good luck! If you decide to continue trying to figure out your stuff
here, in comp.lang.c++, I strongly recommend making more specific
questions, a generic topic like "I want to create an interpreter and I
am stuck, help!" calls for a book rather than a newsgroup message.
V
