Facade Function

A FacadeFunction works according to the FacadePattern and simplyfies an complicated interface of multiple functions or classes to a bare minimum, a single function. -- HelmutLeitner

Example (using ThelopLanguage):

FileCpyUrl( "\remember\FacadeFunction.html", "http://c2.com/cgi/wiki?FacadeFunction")

How is this different than a regular function call? What makes the above an instance of the FacadePattern? You have to go a level deeper if you want to show it as a facade or strategy.

It is a regular function call (BTW I do not know how to do irregular ones). It is not an instance of a FacadePattern, but similar to a FacadePattern. It should be obvious that this function simplifies and unifies a complicated API of multiple functions or classes depending on the environment where you implement it.

Isn't this the case with any function that delegates behavior within its implementation?

How is this different from top-down design and stepwise refinement?

There is no big difference, but I wouldn't use the term FacadeFunction for simple functions like FileCpyStr(filename,string), although you could also develop this function top-down, because there is no complexity hidden.

The term FacadeFunction doesn't introduce something new (do patterns?). It introduces a new way of looking at or talking about "just functions" (or static methods), which have been unduly devaluated in the OOP world. LanguageOrientedProgramming tries to find a new balance between OOP and PP.

Why have the term at all? Why isn't FacadePattern enough? Why does it matter whether the pattern is implemented with a function, method, or class?

What does it matter to be precise and speak of FacadeFunction, FacadeMethod?, FacadeObject? or FacadeClass? in these cases?

What new information is provided by creating this new term for people to remember?

Look at paragraph one of this section. Only time will tell if people like this term enough to use it. That's how languages work. BTW I can't undo it anyway, can I? :-)