aspose file tools*
The moose likes Java in General and the fly likes Friendly programming interfaces Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Java 8 in Action this week in the Java 8 forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "Friendly programming interfaces" Watch "Friendly programming interfaces" New topic
Author

Friendly programming interfaces

Clifton Craig
Ranch Hand

Joined: May 26, 2006
Posts: 103
A little pattern I discovered in my coding and wanted to share, see my site.


Holla at me...<br /><a href="http://codeforfun.wordpress.com" target="_blank" rel="nofollow">http://codeforfun.wordpress.com</a>
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
What you are discovering (perhaps inadvertantly) is that pure functional programming is the most concise method to express "software". You are also eluding to the fact that OO programming digresses from "software" with the benefit of a higher order communication mechanism - we refer to "the String", not "function a, function b, function c, etc." That is, we sacrifice software for the ability to communicate (with ourselves as developers and others).

Since clients of the industry have some (very low) expectation of "software", developers are able to deviate to a degree such that the delivery appears as "software" (for the expected contrived definition of the client) and therefore, use OO systems. However, as the industry's expectations rise ever so slowly, we begin to acknowledge some of the flaws of the tools that we work with. We can begin by asking ourselves, "what is wrong with declaring 100 methods on an interface?". Why is the so-called "optimal" number declining? Better, why is there no agreement on this number?

More to your point however, you can begin by asking a developer who uses the traditional way of doing things (TDD, mocking and all that nonsense) the question, "write a unit test for an interface that contains a single method that returns type void". To save you the time, it cannot be done. Instead there is a unidirectional dependency of this method on some other method(s) through which you can observe some side effect. Of course, you could write the unit test by referring to the aforementioned methods, however, this highlights the unidirectional dependency - it is not bidirectional, because you can write the unit tests for the methods through which you can observe the side effect without referring to the "effectual" method (the one that returns void).

In other words, in all "software", you invoke some effect, and later you observe it - sound familiar? (like a pure function? I admit that is somewhat simplistic, but I dare not enter that discussion).

What you are suggesting is expressing the "effectual" and "observational" functions as a single function. This is somewhat contrived since it implies a bidirectional dependency (symbiosis of operations) - which is untrue.

I could keep going for another 3000 or so pages, but instead I implore you to think a little deeper.


Tony Morris
Java Q&A (FAQ, Trivia)
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24168
    
  30

Originally posted by Tony Morris:
asking a developer who uses the traditional way of doing things (TDD, mocking and all that nonsense) the question, "write a unit test for an interface that contains a single method that returns type void".


First, Tony, I hope you'll indulge my little smile at seeing TDD being described as "traditional." It's not brand-spanking-new anymore, but the way I recall my history of programming, test-last is traditional, not test-first.

But secondly, if the developer in the scenario above was truly doing TDD, this simply wouldn't have happened; the untestable interface method wouldn't have been specified in the first place. In TDD, you write a test, the test tells you what the code looks like, and then you write the code; hence, untestable code is impossible, by definition.

Now, given your answers here, and in the other thread about ignoring return values: the methods being discussed here have return values which, by definition, are just there for convenience, and have no essential purpose. This is an excellent counterexample to the "ignoring return values is bad" answer you gave previously. Don't you think writing methods that simply can't fail is preferable to checking return values?


[Jess in Action][AskingGoodQuestions]
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Ernest Friedman-Hill:


First, Tony, I hope you'll indulge my little smile at seeing TDD being described as "traditional." It's not brand-spanking-new anymore, but the way I recall my history of programming, test-last is traditional, not test-first.


I retract the verb "traditional" and replace it with "prolific". I call it traditional because I once it quite extensively for the usual reasons as well as an attempt to find any legitimacy - which there is, only the critical reasoning is missing (which is why it sells).

But secondly, if the developer in the scenario above was truly doing TDD, this simply wouldn't have happened; the untestable interface method wouldn't have been specified in the first place. In TDD, you write a test, the test tells you what the code looks like, and then you write the code; hence, untestable code is impossible, by definition.

I understand that, but the challenge stands. Let's replace it with some TDD euphemisms mixed with reality. Write a valid requirement specification (read: unit test) and then write the code to make it pass. The code should be a single method with a void return type and no declaring signals (read: exceptions). Let's extrapolate that it is impossible to write this unit test/requirement specification because it is invalid and digresses from the definition of "software".

However, it is indeed possible if your unit test refers to "something other than this method". Is this a "requirement leak" (TDD has no analogous term for this)? It is merely a dependency for the legitimate existence of some contractual operation. We could of course, eliminate effectual operations altogether and we would have a pure functional language (representing software), but that has some inconvenience and lack of appeal to the "layperson" (read: developer with average or lower skills).

Software is a function of requirement specification without omission, addition or misrepresentation. The community chooses to ignore the second point with the assumption that the cost is minimal. However, I observe the side-effect of this ignorance at least once every 10 seconds when I sit down at work to write software with existing tools/methodologies. TDD is a workaround - and a reasonable, but not best, one - to the underlying flaws.

Now, given your answers here, and in the other thread about ignoring return values: the methods being discussed here have return values which, by definition, are just there for convenience, and have no essential purpose. This is an excellent counterexample to the "ignoring return values is bad" answer you gave previously. Don't you think writing methods that simply can't fail is preferable to checking return values?


I don't understand this precisely enough to comment (since I run the risk of omitting some critical piece which is open to refutation).
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:
What you are discovering (perhaps inadvertantly) is that pure functional programming is the most concise method to express "software".


I don't see that. It seems to me that returning "this" is totally orthogonal to wether the function has any side effect (which I think is the basic idea of functional programming - "side effect free" programming).

StringBuffer, for example, uses Clifton's pattern, and isn't at all functional, as far as I can tell.

And as an aside, TDD is far from being nonsense, and is in fact again totally orthogonal to OOP - you can test-drive functional programs as well, and I would do that if I were working in one.


The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Ilja Preuss:

I don't see that. It seems to me that returning "this" is totally orthogonal to wether the function has any side effect (which I think is the basic idea of functional programming - "side effect free" programming).

I didn't mean to suggest that, and I apologise for the missing logic in between. It is a little more complicated than I expect you might be thinking.

StringBuffer, for example, uses Clifton's pattern, and isn't at all functional, as far as I can tell.

And as an aside, TDD is far from being nonsense, and is in fact again totally orthogonal to OOP - you can test-drive functional programs as well, and I would do that if I were working in one.


I think you might be confused about what functional programming is. This is very common.

TDD is an extreme form of nonsense. I predict that this will come to the fore over the next few years as the industry's expectations of software rise, quality being correlated to the dollar, and TDD will eventually be proven as a workaround to an underlying flaw. You do not "test-drive" pure functional programming - you might be thinking of procedural languages. The term "test-drive" makes me cringe quite profusely.

TDD denies spatial cognition, forcing the externalisation of "the blur" that many developers fail to clarify internally (due to lack of spatial ability). I observe the average developer to possess the spatial ability of just above that of a high school student. For example, my 5 year old can now perform addition in his head up to about 20 or 30. Two years ago, he'd have had to draw apples on a piece of paper and count them in order to perform this ability. His spatial ability has improved to a point at or below where most educated adults can perform, however, to reiterate, most educated adults, who work in this industry, have very average or poor spatial recognition, hence we have TDD.

Did you know that you can execute test cases in your head? I can hear the TDD crowd screaming now in denial. But I assure you - it is possible to achieve with precise clarity, far beyond that of which your typical developer might think possible. Just like my 5 year old has trained himself to perform addition with precise clarity in his head, one can train oneself to perform computational progression in one's head with an accurate and concise expression of requirement. Sound freakish? I don't think so - we do this type of mind conditioning with all sorts of things - isn't it obvious?

I know this isn't the place to "write a book" about what is apparent to me and a few of my acquaintances (but clearly not the critical mass), so I omit quite a lot from what I am saying - instead I implore you (the arbitrary audience) to think a little deeper.
[ June 24, 2006: Message edited by: Tony Morris ]
Ken Blair
Ranch Hand

Joined: Jul 15, 2003
Posts: 1078
Originally posted by Tony Morris:
Did you know that you can execute test cases in your head? I can hear the TDD crowd screaming now in denial. But I assure you - it is possible to achieve with precise clarity, far beyond that of which your typical developer might think possible. Just like my 5 year old has trained himself to perform addition with precise clarity in his head, one can train oneself to perform computational progression in one's head with an accurate and concise expression of requirement. Sound freakish? I don't think so - we do this type of mind conditioning with all sorts of things - isn't it obvious?


I do this. It isn't normal? I've always assumed everyone did this.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Ken Blair:


I do this. It isn't normal? I've always assumed everyone did this.


From my interactions with you in the past, I assumed you has quite a high spatial ability - which is a surprisingly accurate prediction given the lacking communication medium (essentially scrolling text).

Is it normal? That's a pretty loaded question. Let's just say that until recently I was working for a very large corporation where it was very abnormal - and could even lead to disciplinary action - to express any sign of intellect (the primary reason that I left) and that I now work with a bunch of people are (were?) TDD (and all that nonsense ) advocates who are slowly changing their position as I continue to argue my case and cause them to question why they really think what they do.

Whatever the case, it's everyone else who is not normal
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:
I think you might be confused about what functional programming is. This is very common.


Well, then please tell me that http://en.wikipedia.org/wiki/Functional_programming is wrong, or explain how that definition fits with what Clifton describes.

Regarding TDD, of course I "test in the head", and I think I'm quite good at it. Still I also find TDD to be very valuable. If you are interested in why, start a new thread in the process forum - it's just too off topic for this thread to continue the discussion here.
Tony Morris
Ranch Hand

Joined: Sep 24, 2003
Posts: 1608
Originally posted by Ilja Preuss:
Well, then please tell me that http://en.wikipedia.org/wiki/Functional_programming is wrong, or explain how that definition fits with what Clifton describes.

That's a pretty good general definition - perhaps I made an inaccurate assumption. I still stand by the original point - the article is simply highlighting that anything but a pure functional system deviates from "software", while purporting to legitimise some other context (many many articles do exactly that).

Perhaps I can invoke a thought with "have you ever written a system in such a way that all types are immutable (a loaded term, but I'll use it anyway)? or at least, tried to? if so, what was driving this requirement?".
Clifton Craig
Ranch Hand

Joined: May 26, 2006
Posts: 103
Tony,

My topic was merely a demonstration of a technique I believe leads to cleaner code. (Not that I write clean code. You should see some of the stuff I've put into production!) I believe the technique helps, though it's not always valid. You raise do some interesting points, though your wording leaves me vague in some areas as I feel like one of those developers with average or lower skills. I don't say that tongue in cheek either because I admit there are many theories on software development that I am only beginning to understand. (It's ok to be admit stoopidity as long as you grow from it.) Functional programming is one of them. I tend to draw a parallel between what the industry titles "declarative" and what I've come to know as "functional" and treat the terms as interchangeable because... well because I don't know no different. I personally like the feel of declarative languages such as XSLT and SQL because the results are often more precise. I'm no expert in the theories of functional, vs. declarative, vs. OO, vs. procedural. Hell, I don't even know what I'm talking about here. From your post, Tony it almost sounds as if your implying that my blog entry was showing the merits of functional programming. (While that is a beleif of mine it was not my intention.) Like I said though, I am unable to decipher many of your points and determine of you're speaking mumbo-jumbo or pointing out something important. You're a little over my head but it sure sounds cool.
[ June 26, 2006: Message edited by: Clifton Craig ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Originally posted by Tony Morris:
That's a pretty good general definition


Good, then we are probably more or less on the same page on this.

I still stand by the original point - the article is simply highlighting that anything but a pure functional system deviates from "software"


I still don't see it. I don't see anything in the article that is about functional programming.


Perhaps I can invoke a thought with "have you ever written a system in such a way that all types are immutable (a loaded term, but I'll use it anyway)? or at least, tried to? if so, what was driving this requirement?".


I like immutable types. I don't see what that has to do with Clifton's technique of "return this;", though. StringBuffer is using that technique for its append methods, and it's hardly immutable.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Self-returning methods are also discussed here. One connection to immutable objects is that you may need a mutable builder for the immutable object, and using self-returning methods for the builder makes it easier to invoke the builder in one line and convert to and immutable view or copy. E.g.

In this way you can create an immutable Foo instance in one line, but you can explicitly name the parameters as you use them (rather than forcing everyting into one big argument list where you have to just remember what the different arguments mean). It's a minor thing, but in my opinion it makes the final API a bit nicer to use.

If we could try to keep replies at least marginally connected to the original topic here, that would be swell. Interesting side digressions would be welcome as separate topics, but please don't overwhelm the original post, OK? Thanks.


"I'm not back." - Bill Harding, Twister
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Friendly programming interfaces
 
Similar Threads
Where are You ?
Another 'Y' game
Congrats Amy!
Smiley test
What is your favorite letter?