[Newbies] Spaghetti code
Ron at USMedRec.com
Sun Feb 18 02:00:34 UTC 2007
Welcome to the list. Before telling you what I would do I have two things
First when I'm teaching people Smalltalk (and by the way I'm not a teacher,
the only people that I've taught is coworkers or people that worked for me)
I give a them a lot of latitude to make mistakes. I give a lot of credit to
someone for making something that works. Only after they succeeded in doing
something on their own do I go back and explain methods and techniques that
would improve their programming, usually on a different project. So keeping
that in mind it may be better to let your son solve the problem on his own
and then go back and build something else using some new techniques that you
can show him.
Second there are a lot of possible designs for this problem. The
implementation of the design should be kept separate from the design itself.
Whether or not you use a text file or how you store the data is a detail.
The details come easy once you have a good design. So focus on design
That aside this is a fun question. (Although I really don't like the actual
flow chart, killing and kids don't mix well in my mind. I know there are
lots of killing video games but not that I let my child play)
The real problem is that it is difficult to gather the requirements so since
this is just a conversation I thought I'd just make them up.
First I want my game to be able to add things. It should be easy to do.
The things should be able to answer questions based on properties of the
things. Next I want the thing to be able to follow multiple question flows.
It should be easy to add properties, questions and flows to the design. I
would personally like to be able to ask random questions so that I can
follow random flows.
OK so this is Smalltalk so let's figure out what objects we have.
We have: Thing, Property, Question, Message, Tree.
The Thing has properties.
The Property has a question.
The Question has an answer of yes or no.
The System gives user Messages.
And we build the flow with a Tree.
The Tree routes by Questions.
If the Tree does not have a question then it routes automatically to the
If the Tree does not have another Tree then we are done.
Ok so first thing we need to do is build properties.
Each property has a question so build a property by giving it a question.
We could also add a name.
instanceVariableNames: 'propertyName question'
In your example there are only properties that have yes answers but there
could be a property that applies on a no answer. For example:
question -> Question
Question -> Is it round?
answer -> no
propertyName -> non round thingy
So now have your system add properties by asking you to name the property
and then type in a question and its answer.
System: Enter Property Name:
System: Enter Question for Property Scary:
You: Is it Scary?
System: Answer to question Is it Scary?:
Now that we have properties we can build thingys
What we do is have you provide the things name and then ask you all the
questions from all the properties that you added.
If you answer the question with the same answer that is stored on the
property question then the property is added to the thingy.
Now you have thingys with properties. We need to build a flow.
A tree has a question or a message.
instanceVariableNames: 'questionOrMessage yesOrDefaultTree noTree'
So now you build your tree by having the system ask you for a question from
the list of questions added by properties or you can optionally type in a
If you add a message like: Boring find another thing. Then you can either
add a default tree to the message or nothing indicating that you are done.
So for every question added, the system should ask you for the next question
or message allowing you to specify the yes or no tree to add too. And it
should verify each branch on the tree has a yes and no tree or ends in a
Notice there is no branching code any more. To follow a flow you start from
the root tree.
Tree >> processFlow
"move along the tree branches until there are no more trees,
displaying the question or message and following the path based on answers"
anAnswer := nil.
self treeHasQuestion ifTrue: [
"do not allow anAnswer to be set to nil"
anAnswer := self getAnswer.
(anAnswer isNil or: [anAnswer isYes]) ifTrue: [
self yesOrDefaultTree isNil
ifTrue: ["we are done"
ifFalse: [^self yesOrDefaultTree processFlow]
^self noTree processFlow
Ok so why did we build thingys? Well because things can now answer
questions for themselves and we can build costumes on thingies and get them
to run around on screen. Now we don't have to ask the user questions we can
just send messages. (Like KILL! Ugh).
So to summarize my suggestion: you use a tree construct to represent
branching instead of using hard coded flows. (It is not really a linked
list) You build objects that represent properties that have questions and
answers. You can then build things that have these properties.
Hope that helps and wasn't too complicated.
President / Principal Software Engineer
US Medical Record Specialists
> From: Blake
> Sent: Saturday, February 17, 2007 7:11 PM
> I'm half thinking-out-loud here and soliciting thoughts on a programming
> lesson. If this sort of thing bugs you, feel free to ignore.
> My son is coding this flow-chart as a Q&A type application:
> So, it says, "You found something!" then asks "Is it alive?" and then
> branches out accordingly. I'm letting him muddle through with the idea of
> using his code as a platform to teaching him a better approach (or
> Looking at the chart, it looks like spaghetti code, and reminds me of some
> of the stuff I did in BASIC. And that's sort of what he's doing within
> Smalltalk. I'm actually tempted to show him how it would look in BASIC
> using GOTOs and line numbers. It would have the advantage of being easy to
> see all in one glance.
> But I want to, of course, show him a better approach and explain why it's
> better. My first thought was to make a state machine, but I don't think
> that'd be much better, in fact.
> Then I thought of what I would do, professionally, in a similar context:
> The problem with the spaghetti code and even a state machine is that it's
> static, and adding bits and pieces tends to require everything to be
> massaged around the new parts. In the real world, I know that the chart's
> not going to be static.
> I'd probably end up create a linked list of one-exit nodes and two-exit
> So, that's what I'll probably show him.
> The other thing I'd do, though, is put this all in an editable text file,
> 1,foundsomething,"You found something",alive
> 2,alive,"Is it alive?",friend,smash
> 2,friend,"Is it a friend?",lately,scary
> 1,smash,"Smash it with a stick!",shiny
> But I'm wondering if this last wouldn't be too much.
> Beginners mailing list
> Beginners at lists.squeakfoundation.org
More information about the Beginners