Comments for Roop says

Comment on Why Defensive Programming is Rubbish by Russell Centanni

2009-12-02T22:59:45Z

I’m a fan of the fail-fast approach. Lately I’ve been writing methods with parameter assertions up front that throw descriptive exceptions when there’s a problem. Spring has some utility methods in org.springframework.util.Assert that are used for this purpose.

In my opinion, the only appropriate time for null checks is when null means something in the system.. and if that’s the case the check should be done in a method with a meaningful name. Having said that, I feel like groovy’s ? operator makes playing “hide the problem” even easier, resulting in a drop in code quality.

Comment on Why Defensive Programming is Rubbish by Daniel Roop

2009-10-18T00:49:46Z

@Brian
This does help solve the readability problem, but it still keeps the “hide the problem” aspect of your code. That being said I agree there are times when a null check is appropriate, and I am a fan of what the dynamic languages do to make this easier. Groovy has the ? operator (which is probably the best) and ruby let’s you add the conditional at the end of the line (allowing you to focus on the action not the conditions)

Comment on Why Defensive Programming is Rubbish by Michael Sica

2009-10-17T15:58:42Z

I agree. Imagine if you actually tested every path through the code? The danger in your code samples (for a large application) is that understanding the different states your application could end up in is insane. There are much better ways to message a user when something goes wrong than to allow about half your code to work.

Comment on Why Defensive Programming is Rubbish by Brian

2009-10-16T13:30:29Z

It’s ok, Groovy has an operator for that. The ? can be used to chain null checks for more readable code. So you could say:

if(person?.size() > 0) …

Now all you have to do is use Groovy where you want to place null checks. Seems like a reasonable goal to me

Comment on Java to Coldfusion HashMap by Shane

2009-09-23T23:23:34Z

Thanks for posting this! Saved me some headache…

Comment on Actionscript 3.0 Object Equality by Carlos Valdez

2009-09-18T03:30:52Z

Thanks!

Comment on EasyMock Exception when calling createMock by Mattias

2009-08-25T12:11:15Z

Thanks! Fixed the problem for me

Comment on Program to an interface not an Interface by Jason

2009-07-28T22:34:55Z

Another reason why you might not want to use an interface is if you need the object to have a certain method available but you don’t want to make that method public. You can’t do that with an interface. An abstract class is the best alternative but IMO it makes just as much sense to make a concrete class. A concrete class can still be extended and overridden and in a worst case scenario that concrete class can be turned into an abstract class without impacting the client of that class as long as the concrete class cannot be constructed outside of your control. What I have proposed is the use of concrete classes with package, or lower, access constructors. This gives you all the benefits of programming to an “interface” without unnecessary code waste.

Comment on Program to an interface not an Interface by Justin Holzer

2009-06-11T18:36:06Z

IMO, the whole point of programming against interfaces is to be able to define expected behavior without having to go in to details about how the system will be implemented to carry out the behavior. Sure, you can inherit from a concrete or abstract class, but at that point, you are combining the definition of the expected behavior (i.e. method signatures), with the actual implementation of that behavior (optional for an abstract class of course).

Also, inheriting from a base/super class is not a substitute for a Java/C# interface, as you cannot force the sub-class to override non abstract methods. Sure, you could build an abstract class and declare all methods abstract, but at that point, why not just use an interface? Definition of expected behavior and implementation of that behavior should be kept separate, if possible. If you have the Interface (in the Java/C# sense of the word), why not then take advantage of it?

Comment on Program to an interface not an Interface by Fat Agnus » Program to an interface, not an implementation

2009-05-20T10:48:22Z

[…] A java guy talks about Interface vs. Interface […]