Re: Interface with implied Constructor
On 19.07.2013 04:21, Arved Sandstrom wrote:
On 07/14/2013 01:03 PM, Robert Klemme wrote:
On 10.07.2013 00:46, Richard Maher wrote:
So let me ask you "Why do you want to use setters or an init() method?"
I opted for the init() method OR factory method pattern. Both are type
safe because in both cases a method in an interface needs to be
implemented. Picking a constructor solely based on argument types has a
looser coupling between the contract and the implementation of it. An
interface makes that coupling explicit.
I'll be honest, Robert, personally I consider the behaviour of an object
- the kinds of things you could specify in an interface - to be what the
*initialized* object can (should) do.
Of course. A factory instance can also be an initialized object.
Often the best way to properly initialize an object is to call a
constructor with arguments. That's what they are for. And to be honest
once again, a ctor *is* an implementation thing, IMO: it's not the
business of an interface to dictate how an implementation will
initialize objects that can support the interface contract. After all,
how can an interface even possibly imagine what the internal state of an
initialized object, hence what ctor args are required, is?
In situations like Richard's (at least as I understand it) the
environment knows what information it has available and the interface
for the factory can be defined in such a way to pass data potentially
needed or the data that the environment is willing to provide. The
factory implementation then can decide which part of that information is
needed to create the instance and ignore the rest. It's surely better
to let the implementor of the construction process decide which
information to use than the implementor of the environment (or call it
"framework").
No problem with factory methods, except they are for specific
situations. And I think they also lean more towards implementation.
What "specific situations" do you have in mind? As far as I can see the
name of the class to create is configured and Richard said reflection
will be used in his initial posting. I think that is a typical
situation where a factory class can be configured which is created via a
no arg constructor and which has a method createFoo(...) with
appropriate arguments. Then there is no need to fiddle with reflection
to analyze constructors and argument lists. Also, this gives more
flexibility as the factory can decide which class to instantiate at
runtime if need be.
My main point is that I dislike using reflection to _find_ an
appropriate method - be it a constructor or another method. I prefer
that method to be identified in an interface - whether that is an init()
method in the interface of the object I will eventually be using or a
create() method in another interface defining the factory API I care
less. I think Class.forName() and newInstance() is enough reflection to
get flexibility and decoupling but from there on I prefer to use methods
specified via an interface or abstract base class.
Kind regards
robert
--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/