Yup, this is what we're talking about... your original code is alright though,
as it doesn't call any other methods, or access non-private class state. (i.e.
doesn't access a member variable!)

To echo what other people have said though: a well named and abstracted object
will not have a verb in the name, but it may have a *verbal noun*, e.g.
'Helper' or 'Manager' etc. A verbal noun is useful because it gives you some
idea of what services a class might offer - it suggests a verb, even if it's a
vague one, like 'manager' suggests 'manage'.
It all makes sense really, as an object is a thing, i.e. a noun, not a verb.
(And you could think of instances as proper nouns, as in "*the* apple" vs.
"apple".)

(Verbal noun definition btw: http://www.bartleby.com/61/1/V0060100.html - maybe
what I'm thinking of isn't quite a verbal noun, but it seems to fit quite well!)

Also, a constructor should do things that are required to set up the object for
use, and not much more. In your example, your constructor is doing too much -
it's actually doing the ftp put - but this in part stems from your choice of
class name. If instead you chose a class name like "FtpHelper", then it would
be more natural to just construct an FtpHelper object, and then call a method
like ftpPut() on it.

Another commonly seen but not great idea is to do any sort of GUI realisation
activity in the constructor (by which I mean showing a window and similar
things). Also I prefer not to even do population of GUI items in a constructor
- I prefer to make it explicit by having a populate() method. IMO
showing/hiding of a GUI item should always be done explicitly, with a call to
show() or similar.

Anyway, I am digressing like a diggity thing, so I'll stop.

alex