"It Depends" vs. "Fact With Exceptions"

>> My question is, is "It Depends" really accurate?

Well, sometimes yes; othertimes no - it depends...

:D

Ben - Well said. In my OO journey I have heard the same thing sooooo many times it gets frustration. Sometimes I begin to wonder if it matters whihc methodology you choose for a particular task. In some cases maybe it doesn't.

Lately I have been trying to ask the question differently. Instead of asking "How should I handle form validation...?", where I would likely get the answer "It Depends" from 9 out of 10 Developers, I try to ask "How do YOU handle form validation...?" and hopefully get something clearer.

@Ben,

I agree with your assessment of the phrase, "it depends". It's too generic, has the connotation you described as well as the connotation that the writer doesn't really know the likelihood that the result will occur or not. I little bit phrase would be "usually", or "in most cases, yes".

But even would be when there was some statistical data (not always feasible, of course) to back up a claim - something like, "80% of the time X happens, 19% Y happens, and 1% Z happens".

PS - to play devil's advocate to your not-meant-to-be-entirely-accurate analogue: keep in mind that some Buddhists, as well as probably in a few other belief systems, it is never "okay" to be violent towards any other sentient being for any reason (even to protect one's own life). So, "it depends" on which belief system one aligns oneself with, and whether one will truly act according to those beliefs when confronted with the reality of the moment. (sorry, I have no stats at the moment to back up these statements). Peace. :-)

As someone who has become somewhat infamous for saying "It Depends", let me jump in and defend that annoying habit... :)

So, yes, part of the problem is what Jason hints at - asking a generic question. If you just ask "How should I do X?" with no background information, you're going to get an unhelpful generic answer.

Part of the problem is that with OO there is no "One True Way" and in my experience when trying to teach OO, a lot of people have a tendency to latch onto one way to do something without really understanding it and then they run into problems and have no idea why (when they should be using a different approach). This is especially true of people coming from a procedural background because in OO they no longer have their regular frame of reference for solving a given problem.

If you think about how you write procedural code, you make design decisions and trade offs all the time, based on your experience. Once you get really comfortable with OO, you'll find yourself doing the same thing. A lot of people who are prone to saying "It Depends" have been badly bitten by offering some off-the-cuff advice and then getting nailed because that advice doesn't apply to the situation (which the questioner failed to describe properly).

The bottom line is that OO design is much more fluid than procedural design because the trade offs can be much larger between different approaches. A bad OO design can really hurt you. Sometimes, you can't get to a good OO design without a lot of experience (i.e., making mistakes and learning from them) and it's not always easy to explain enough of the trade offs to help a novice in a way that doesn't completely overwhelm them :(

That's partly why OO can seem so hard to learn - there are a lot of gray areas.

To be fair (to me), when I say "It Depends", I usually follow up by asking a bunch of questions about the problem space and offering multiple solutions with some explanation of the trade offs. I want people to realize that there *are* multiple solutions to most problems and that there *are* trade offs - pros *and* cons - to every solution.

If you look at Design Patterns, one of the most important aspects - and the one most commonly glossed over in almost every design patterns talk I've seen given by CFers - is that each pattern has trade offs and that the pattern description itself explains when a pattern is applicable and what the pros and cons are for given situations.

Sometimes (like with your form validation problem) I say It Depends because there are good reasons for doing it in several ways, but the one I would go with depends on all the elements in the equasion.

For example, in your dilemma about putting save on the 'smart bean' vs the service, I might be perfectly happy with it on the object, unless I had to deal with saving the object in several states, each in turn with differing cascading objects. This happens a lot and is better put somewhere else.

You could put the save in the object and delegate to the service. Thereby putting the transaction logic and the cascading stuff into the service. This would make DI easier since we all know that ColdSpring isn't too excited about gen'ing instance objects.... but then again, you aren't using ColdSpring and don't have to worry about that. You also don't have to worry too much about cascading objects in this case either.

Blah blah blah...

There are many right answers, each with their own sets of tradeoffs. Each of which has numerous refactors. You seem to be learning much more by thinking this out than by having people tell you what the right answer is...

To be clear here, Object Oriented Programming and Design Patterns are two distinct things, even though DP is a "subset" of OOP. You can write OOP without following any Design Patterns. It's probably best to think of OOP as writing well structured sentences and paragraphs and Design Patterns are a specialized style of writing like poetry, screenplays, song writing, etc. Another analogy is the basics of writing and reading sheet music vs knowing jazz scales, classical scales, diatonic, pentatonic, etc.

There is no "it depends" when it comes to OOP. OOP is a foundation and the rules of OOP are clear and defined. Without that foundation, though, you can't successfully engage in specialized styles.

"It depends" relates to Design Patterns. The way most people learn Design Patterns is they learn one and then try to apply it to everything. By doing this, they learn the limits of that pattern first hand and then are driven to look into other patterns. It's pretty much universal that the first few patterns you learn you will use in that way. It isn't until you get a few under your belt that you start to understand a pattern upon reading its description, and differentiate between when a pattern is appropriate.

In other words, "It depends" is the only applicable terminology, and if you don't understand why "it depends", then you need more experience and the only way to get that experience is to walk the path.

I personally think the two most important patterns to learn first are Observer (Event/Listener), followed by MVC (I think the book "Agile Web Development with Ruby on Rails" is the best way to learn proper MVC concepts, even though it isn't Flash, it's leaps and bounds above any Actionscript-specific MVC texts or lessons I've ever read). If you can throw DRY in the process (an important auxiliary style that applies to OOP in general), all the better.

Once you have Observer and MVC down, you've got a solid foundation to move on to Factory, Singleton, Composition, and Strategy, in that order. Once you get those six patterns down, you will understand why "it depends" in any new pattern you learn.

On the other side of the coin, I find myself often looking at a situation where I've been working on some piece of code that deviates from what I've suggested as a good general practice and wondering "when am I going to have to defend this code because somebody thinks I'm being hipocritical here?" ...

The reality is of course that no matter how emphatically you state that X is either good or bad general practice, there are always exceptional cases like the woman who's attacking you with a deadly weapon. But when I'm writing articles where I'm commenting about things like for example why the semantics of Spry actually create more work (rather than making things easier like they're supposed to), I generally don't offer "it depends" as a justification for the way those things are written, I just say "x ain't good form if you want to accomplish y". Where y is usually productivity and x is usually the way most software is written.

Yes I believe most software practices -- the ones that are most widely used anyway -- are counterproductive. :) The day that I walk onto a new job or contract and am given a task and am able to achieve results in the hour that it takes me to do things my way, vs. the 5 hrs it takes to do the same thing someone else's way and the resultant code is both equally flexible (right now it's less flexible, i.e. Spry + lack of ORM) and no less error prone, then I'll be a convert.

I should probably have tried harder not to sound so conceited... :)

hey ben... sounds like you came to the same conclusion/observation that i did when doing the OO thing... being "right" is subjective :)

http://charlie.griefer.com/blog/index.cfm/2007/12/7/the-art-of-being-right-learning-OO

as sean points out above, one of the most frustrating things (that i've found, at least) in moving from procedural to OO is that we're looking for that recipe... that one "right" way to do it. we want to hear "if this, then do that.. else, do this". but that doesn't exist.

while it can be frustrating to hear that there is no "right" way, it can be awfully empowering to think of it as there is no "wrong" way. at the end of the day... does the code run? congrats. you've done it. it's "right" :)

now, that isn't to say there is not a "better" way and a "not so good" way... but it's subjective. it'll never be as clear-cut black-and-white as right or wrong.

look at the debates that rage on various mailing lists and forums. among people that i look up to as being experts in all things OO (sean c, joe rinehart, brian kotek, peter bell, etc), debates that border on all out holy-war still go on. is it because one knows what's "right" and the others are wrong? no. it's because they're all right. their ways work for them. different means to a similar end. is one method "better" than the other? depends who you ask :)

i still struggle to a degree with accepting that there's no strict formula to which i can adhere and start writing "good" OO code. i've accepted the fact that i'm going to write what seems to work for me. in a month or three, or maybe even a year i'll probably look back on it and go, "charlie wtf were you thinking?". but you know what? i do that today with my procedural code :)

focus on understanding things from a conceptual level, rather than the concrete implementation. i don't know that there's a specific "a-ha" moment when the light bulb turns on... for me, it's been kind of a dimmer switch. it's still sorta dark, but i can see that it's getting brighter little by little.

the whole OO thing really is a journey. it's not about crossing a finish line. it's about staying on the track.

Any askable question depends on some other piece of information to some degree. So it is very rarely worth saying. If follow-up questions need to be asked, just ask them.

A lot of the permutations can be ruled out from observing the question and some knowledge about the asker. If an OO newbie asks an unsophisticated question, it is very unlikely that they are concerned with the ramifications that your solution will have to sticky sessions in a cloud environment, for example.

It is only worthwhile to say so when then options are truly equal, given all that you know about the asker, the question and basic follow-up questions. Otherwise, to me at least, it is typical condescending IT snobbery to start every answer with "it depends".

q: "Should I separate my SQL into a DAO?".

a: "Well it depends, is there someone pointing a gun at you and threatening to shoot if you use DAOs?"

q: "Yes"

a: "Well then it depends, are you looking to die or live?"

q: "Die"

a: "Well then it depends, do you want to hear a loud noise right before you die?"

The problem here is that people really, really want a hard-and-fast recipe for how to solve OO problems. And there isn't one.

Well, there is, actually, but it is so general as to be nearly useless to newcomers. The rules "favor composition over inheritance", "design to interfaces not to implementation", "encapsulate by convention reveal by need", "tell don't ask", etc. are what end up dictating virtually every solution. But that doesn't really help because the rules apply at such a high level.

As Sean mentioned, software problems are rarely black and white. The best solution in one context may very well not be the best solution in another. So much depends on what the person actually needs to do, the constraints, and the knowledge of the person solving the problem, that to offer a blanket solution often will make things worse.

Look at what happened way back when Sean put out his Coding Guidelines. He showed off the use of the Memento, DAO, and Gateway patterns. And what happened? Everyone who read it ran off and added Memento, DAO and Gateway objects all over their applications, with no actual understanding of what factors went into their use. I know this, because I did it myself! It is reasons like this that people are leery of trying to provide sweeping answers to questions, because the answer truly is, it depends...on a wide range of things.

The core issue here is that really internalizing the theory behind OOP and the elements that go into making design decisions cannot be supplied by cookie-cutter answers. Believe me, I wish it could be, it would have saved me years of effort and pain. ;-)

All one can do is try to grok the fundamental rules, and try things out. Ask for advice where you can, but know that the advice you get is provided with a very generalized idea of what problem you might be solving. The process never stops, no matter how far along you think you are. I can look at code I wrote last MONTH and something will jump out that makes me go "why the hell did I do that when THIS would have been sooo much easier?".

Anyway, this may not be a great answer to your question because it isn't much of an answer at all. But hopefully it helps a bit anyway. :-)