views:

108

answers:

8

Hi,

let's consider a small method:

int MyFunction(string foo, int bar)
{
  ...
}

and some calls:

MyFunction("",0)
int x = MyFunction(foo1,bar1)

How would you explain this to a non-technical persons? Has anybody a nice metaphor?

I tried to explain method calling (or function application) several times, but I failed. Seems I can't find the right words here.

Regards, forki

UPDATE: It is important for me to explain how the parameters are passed / matched.

+4  A: 

(Highly non-technical solution)

It's like making an order:

  • Calling the method = dialing the right number
  • Passing the arguments = giving your details
  • the method does is job
  • Getting a return value = getting what you ordered
Am
Nice idea. But passing the arguments is where I failed. This is should be explained further.
forki23
+2  A: 

How about delegating a task? Imagine you’re baking a cake and ran out of flour. Instead of buying some yourself you could just send your kid with instructions to buy flour. Input: money, output: flour.

Konrad Rudolph
Yes. Delegating a task is a nice description for black box behaviour. But I think the probleme here is: How would I communicate with my child?
forki23
@forki: does it matter for the sake of the metaphor?
Konrad Rudolph
If I don't understand that the parameters are matched via the given order and not via a name or something I can't use a method.
forki23
@forki: well, that entirely depends. Some languages *do* allow matching via name rather than order. This is a technical detail and I don’t think that it is in any way relevant to understanding methods.
Konrad Rudolph
Yes, it's a technical detail. But you need to know it otherwise you won't use methods the right way.
forki23
I thought this was about *non-technical* people …
Konrad Rudolph
+5  A: 

You could tell function is a process available into an object that could be called by other. Lets say "You" is an object with function "Work". Your "Boss" is the caller object. Your Boss then can call you to Work with different type (which is parameter).

In the end Your "Boss" can ask "You" to Work("encode this") or Work("check email") or Work("finish deadline"), etc.

Jojo Sardez
I think objects are one abstraction higher than "simple" method calling.
forki23
Excellent one..!
Sri Kumar
Yeah. You could use "Person" in your explanation. Like A Person "You" has a function "Work" and the Caller person is called "Boss".
Jojo Sardez
and the return values are "gimme my money"
Am
+1  A: 

It's difficult to understand the "method call" concept if you don't understand first the
flow of control.

A simple explanation is that methods, or routines, is a construct for packeting instructions
in order to reuse them and make the code more readable.
Calling a method, temporarily, switches the execution flow to that method.

Nick D
A: 
C:: do(a ,b)

You are telling C to do something , given the condition a and b.

pierr
A: 

Think of the system as a teller at a desk. To call a function you fill in a form to ask the system to do something, hand it to the teller. They go off and do the work, then hand you back a piece of paper with the result written on it. Depending on what you want the system to do, you pick an appropriate form.

The form for MyMethod says:

MYMETHOD REQUISITION FORM:
String _______
int    _______

This analogy can be extended in all kinds of ways. Wouldn't it be handy if the form told you what the purpose of the String and int were? That's where languages with named parameters come in.

For OO, instead of having one desk for the whole system, each object is its own teller, you hand a form to them, and in order to get the job done, they hand a lot more forms back and forth between each other. Etc.

slim
Wow. I like that. And I think it's really flexible to describe the behaviour in every level of detail. You can add default parameters as well.
forki23
This analogy can even be used to describe how curried functions are working: You fill out a form to get another form.
forki23
and recursion, where the teller fills in a form and hands it to himself.
slim
A: 

The best approach is probably to come up with a domain specific example which the person you are explaining to can relate to. If she is working with the post office, you should describe the function "send letter with this text to this recipient", where recipient is a parameter (containing the address) and message is the parameter for the textual content.

Parameter order is not important as long as you have a name for each parameter. Trying to explain why order is important in some arcane programming language is fruitless.

Martin Wickman
A: 

How about

  • Calling a function: Ask the software to perform xxx task
  • Returning value type function: Ask your software to perform xxx task and tell you the outcome of the operation
  • Calling a function with param: Given X is this value and Y is thisvalue, ask your software to perform xxx task (and tell you the outcome of the operation)
Fadrian Sudaman