Open GoogleCodeExporter opened 9 years ago
+1
My only reservation is that IResourceHelper is pretty big already. Perhaps
there
could be another helper for things like this? That said, it should be obvious
(and
easy) to access these functions. The discoverability of these methods is good
if
they're on an object you're already likely to have around... (On the other
hand, God
Classes are passe; can you tell I'm on the fence?!? ;))
Another argument for putting this somewhere else is that much of what the
helpers do
is interact with the UI through the UI context. This method (and in fact a
host of
ones already defined in IResourceHelper) don't do that, going instead right to
programmatic access. It's a bigger point but perhaps worth considering if we
want to
tease these apart.
Original comment by phil.qui...@gmail.com
on 1 May 2009 at 4:56
IMO, The size of the interface should not be a limiting factor on where an API
is placed.
History: One of the primary problems that the helper library is trying to solve
is
eliminating duplicate test code. The biggest reason for duplicated test code
was BY
FAR, in my experience, because test authors did not know where to find the code
that
they needed. The solution was to place API methods in the place that made the
most
sense conceptually. In other words, if the API method is a resource method,
then it
should be put into IResourceHelper. Without something very basic, very obvious,
trying to reverse engineer the API author's intent is impossible because
everyone
thinks differently.
Original comment by jhouston.mail@gmail.com
on 8 May 2009 at 7:36
Original issue reported on code.google.com by
jhouston.mail@gmail.com
on 29 Apr 2009 at 3:30