Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Fuschia, President-Elect of the Bright Purplish-Green Council" Newsgroups: comp.lang.java.programmer Subject: Re: Passing a Method Name to a Method Date: Thu, 23 Jun 2011 13:42:26 -0400 Organization: IBM Lines: 24 Message-ID: References: <81h4075t4gfjglji1n033rb20025ebho68@4ax.com> NNTP-Posting-Host: 8VhVVOJhq9kx7Yha7TGFgg.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Xnews/2006.08.24 X-Notice: Filtered by postfilter v. 0.8.2 Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:5590 On 23/06/2011 10:01 AM, Stefan Ram wrote: > Arved Sandstrom writes: >> for (i=1; i<=nRepetitions; i++) >> ParseThisWay(args); >> and >> for (i=1; i<=nRepetitions; i++) >> ParseThatWay(args); > This is procedural programming ... > In the general case, object-oriented programing is better, > because it allows to add another parse method by adding > another (third) parse class /without changing/ most of the > other code and thus fulfills the open-closed principle, > while procedural programming usually would required code > changes in more places when adding a third way to parse. I'll just mention here that functional programming, in this case at least, also gives the advantages given by object oriented programming; specifically, you can add another parse method by adding another (third) parse *function* without changing most of the other code. And generally while writing a lot less boilerplate code than Java requires, with one interface, plus one class skeleton around each parse function, plus relevant imports and type declarations here and there.