

One of the Worst Bits of Programming Advice I ever Got - AshFurrow
http://ashfurrow.com/index.php/2011/09/one-of-the-worst-bits-of-programming-advice-i-ever-got/

======
raganwald
The argument seems to be:

1\. I was told not to do X.

2\. I did X and I like it.

Therefore:

3\. “Learn from your own experiences and beware of anyone espousing the
virtues of the One True Way.”

This is motherhood and Apple pie. It _sounds_ like wisdom, but it doesn’t
follow logically from his example even if you agree with his feelings about
his code.

By way of a counter-example, We could pick millions of lines of terrible PHP
and Javascript. These were all written by people who learned from their own
experiences and didn’t follow any dogmatic rules or guidelines.

Why is it that sometimes breaking the “rules” is a good idea but sometimes it
isn’t? For a blog post to be _useful_ , it should propose some sort of
repeatable criteria for when to defy thirty years of experience/folklore with
OOP and when to respect it.

Again, I am deliberately avoiding agreeing or disagreeing with his example,
just pointing out that the conclusion as stated isn't really useful.

~~~
tom_b
There seems to be a pressure for coders to blog. Writing well (and creating
_useful_ posts) requires the same attention to craft that coding does.

Thoughtfulness is a rare quality in both code and blog posts - I savor it when
I find it. We probably need fewer coding frameworks and more mental frameworks
that encourage thoughtfulness in coding and writing.

But I do think there is room in the blog world for writing as journaling.
Maybe the usefulness of a blog post is limited to the author, but there may be
some value for us as readers in simply seeing another's thought process at
work rather than requiring the post to meet some metric of _useful_.

~~~
AshFurrow
>>> Writing well (and creating useful posts) requires the same attention to
craft that coding does.

Yeah, for sure. And rushing through writing a quick response when I should be
heading out the door for work was probably a bad idea. Next time I'll sit on
it until I'm through my first cup of coffee.

~~~
raganwald
Maybe, but then again, maybe not. A blog is not a hardbound book with gilt
corners. You can read the responses, revise it, perhaps learn from the
feedback. I certainly do, and in that respect my own writing resembles my
code: Writing is rewriting.

Therefore, I’d rather see you write and be thoughtful about the responses you
receive than hold back until you have researched every idea thoroughly in an
attempt to avoid criticism.

That is my personal view, I am not sure I can provide any evidence that it is
a good idea.

~~~
AshFurrow
I think the biggest problem I made with this particular post was conflating it
with a code sample.

Few people who probably argue that OOP is the only way to code. But when faced
with an example of another way, people are focusing on that specific example
as a way that "I don't understand OOP." I'm finding more and more that what I
don't include in my writing makes a strong piece.

------
jameskilton
So to answer his own question, yes he's doing OOP the wrong way. The advice
he's given is actually _really good_ if you want to learn how to think with
objects, any "actionable" name like Helper or Fetcher implies that there's a
behavior mismatch somewhere and you should refactor so that you're back to
Objects doing their thing.

For the sake of the blog post, he should have refactored APIHelper to be
something like ExternalApi, where it and it alone knows about how to fetch and
how it's implemented. Then it's super simple to refactor ExternalApi's
internals to be async instead of sync, but now he's got another object
strictly dependent on the internal workings of another object, and will have
trouble in the future.

The fact that he instead built an async wrapper around a sync call shows that
he doesn't understand OOP and is himself stuck in procedural land with
objects.

This article should be titled "How I threw away some of the best OOP advice
I've ever been given".

------
rcrowley
I think this is an instance of one of the hard problems in computer science:
naming things.

When thinking about "-er" names to avoid, think about "Executor" and its ilk.
Contrast that with this example and I see "APIHelper" and "ModelFetcher" that
should probably just be called "MyBackgroundThread" or some such with methods
for fetching models and making synchronous HTTP requests.

In other words, I think avoiding "-er" is a specialization of [http://steve-
yegge.blogspot.com/2006/03/execution-in-kingdom...](http://steve-
yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html).

------
cpt1138
I read that too, with a grain of salt and subsequently did a 'find . -name
"*er.java"' just to see. 23 out 148 matched in one of my projects. Cursorily,
half of them are nouns and the other half are a combination of Loader, Manager
and Handler. :)

I think its more a case of doing what I've seen done before. Maybe some "angry
monkey" but maybe more like "Hey, that seems like a good way to do it."

~~~
rcrowley
The mere existence of Loader, Manager, Handler, Factory, and the like
classes/methods indicate a lack of expressive power in Java's constructors.

------
nvictor
who? where? when? references?

everything is relative.

------
mdg
typical hacker news: someone says something that someone else takes too
literally and subsequent blog posts/arguments/flame wars ensue

~~~
rbanffy
A piece of advice: before posting, consider carefully whether you add
something to the discussion. If you don't, maybe you shouldn't.

