[FoRK] ravioli code

owen at permafrost.net owen at permafrost.net
Sat Nov 15 21:46:13 PST 2008


Fork is the second hit for "ravioli code"
http://www.xent.com/FoRK-archive/spring97/0091.html

"The ideal software structure is one having components that are small and
loosely coupled; this ideal structure is called ravioli code. In
ravioli code, each of the components, or objects, is a package
containing some meat or other nourishment for the system; any component
can be modified or replaced without significantly affecting other
components."

Owen


On Sat, Nov 15, 2008 at 08:33:33PM -0800, Stephen Williams wrote:
> damien morton wrote:
> >I learned a new phrase today. "Ravioli Code".
> >
> >>From Richard Carlson, developer of "parametrised modules" for erlang, a 
> >kind
> >of object oriented programming facility:
> >
> >
> >In the Object Oriented Programming world, "ravioli code"
> >is what you get when you have factored your program into
> >too many small chunks of code, so that it becomes impossible
> >to keep track of where the actual work is being done.
> >  
> I have always disliked this.  Having too many classes in Java is a 
> similar issue.  You just don't need extreme modularity everywhere all 
> the time.
> 
> I like to see the code without jumping through 20 files...
> 
> sdw
> >(It's "all in the sauce", which of course is hard to get a good
> >grip of.) With abstract modules, these kinds of programs become
> >possible also in Erlang. In the worst case, a program
> >could start with instantiating hundreds of abstract modules,
> >nally creating an "application" module instance M and calling
> >M:start/0, and it could then take weeks to understand
> >(even for the original author) which parts of the code are
> >actually being called, from where, and at what time.
> >This kind of overuse of parameterizing modules should be
> >avoided. The strategy to be used mainly depends on the
> >programming problem: some problems map easily onto a
> >set of functions without any real need for parameterizing
> >the module itself { in those cases, the temptation to create
> >an abstract module should be resisted. In other cases, parameterizing
> >the module solves the problem in a very elegant
> >manner. Use abstraction with discretion.
> >_______________________________________________
> >FoRK mailing list
> >http://xent.com/mailman/listinfo/fork
> >  
> 
> 
> 
> _______________________________________________
> FoRK mailing list
> http://xent.com/mailman/listinfo/fork


More information about the FoRK mailing list