[klmr]

I know this isn’t the point of the article but the code shown there is the archetypal case where writing classes is an anti-pattern, as argued in “Stop Writing Classes” [1]. All the classes in that code can — should! — be functions. There’s no downside, and it’s less code (and otherwise identical).

[1] https://news.ycombinator.com/item?id=3717715

[naringas]

maybe he was a Java programmer?

all joking aside, the reason he's doing classes seems to be an intention towards making a FooStep (and/or a BarStep) which could then maybe handle generic Foo stuff (authentication comes to mind) in the future?

[epr]

"maybe"..."in the future" is the root of much object oriented evil

[w23j]

Well... that is certainly correct in 99.99% of cases. But does it really apply when you write a "Do Nothing Script"(!) with the intention of automating the steps later? If you follow the "rules" to the end you just end up deleting the file after writing it, because it has no effect.

[ardani]

Only if your intention encompasses as much detail as you're leaving out in advance. It's baggage and comes with nigh certainty of wasting your willpower.

[pytester]

"maybe in the future" are four words I've learned to dread hearing from any developer. YAGNI goes much, much deeper than most people realize.

[shareIdeas]

I don't think there is a correct answer, but I like that a developer has foresight.

[mattnewton]

The problem is you get more information in the future, but all this boilerplate is has been written before that information so the first instinct / seemingly least-resistance thing to do is to fit the new information into the old boilerplate / hierarchy.

Lots of people have OO scar tissue from getting weird impedance mismatches on newish OO systems designed this way.

[sullyj3]

Real foresight is understanding the cost of unnecessary technical debt.

[kissgyorgy]

This is a pretty common misconception. I have yet to see a bit of perfect abstraction that has been written before the problem occured.

[ori_b]

> Do not put code in your program that might be used. Do not leave hooks on which you can hang extensions. The things you might want to do are infinite; that means that each has 0 probability of realization. If you need an extension later, you can code it later and probably do a better job than if you did it now. And if someone else adds the extension, will he notice the hooks you left? Will you document this aspect of your program?

From http://wiki.c2.com/?PrematureGeneralization

[dillonmckay]

YAGNI

[barbecue_sauce]

YAGNI for thee, but not for me.

[rzzzt]

You Are Going to Need It

[newaccoutnas]

There's a decent python library for these kind of things - https://www.fabfile.org/ (amongst others)

Allows you to do both local and ssh based interactions

[diminoten]

You will tire yourself out long before you change the minds of many SAs when it comes to code quality.

They're a breed with a very strong sense of "It works so I don't care", and honestly I don't really blame them.

[zshrdlu]

My face fell when I saw the code. I will actually henceforth use this as an example of this anti-pattern.

Whether or not the author was a Java programmer shouldn't matter - I think one should try to writing idiomatic code in any language, unless there are reasonable reasons against it.

[masukomi]

I dunno. it could be argued that in the "do nothing" form of the script it's silly. HOWEVER some of those steps could eventually require the encapsulation of lots of behavior and information. So, `CreateSSHKeypairStep` Could become a full-on class with lots of small methods in it that eventually get wrapped up in a `.call` method. It seems better to start with code that's prepped for the eventuality you know is coming. Setting yourself up for a good long term codebase.

[CaptainMarvel]

Seems like a violation of YAGNI, and converting a function to a class is fairly effortless

[getpost]

Moreover, the steps should be in a table, with just one function to process the contents of the table.

[dharmab]

The point of writing this script is to follow up by replacing each function's implementation with code that automates the step. Using a data-driven design here ossifies the code and makes it harder to migrate the automated version.