[
https://issues.apache.org/jira/browse/HADOOP-1230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12614912#action_12614912
]
Sanjay Radia commented on HADOOP-1230:
--------------------------------------
This comment is on the general observation that doug made about interfaces and
abstract classes in this Jira.
Doug, your observation about the power of abstract class for evolution is right
on!
However, your viewpoint that "_Some folks seem to believe that interfaces are
somehow 'cleaner' and should be used for all public facing APIs. But that's not
true_" is not quite correct. Joshua Bloch in "Effective Java" argues the use
of both interfaces and abstract base classes together. (see Effective Java
...item 16 p 84): "_You can combine the virtues of interfaces and abstract
classes by providing an abstract skeletal implementation class to go with each
non trivial interface you export._"
I believe your argument is flawed for the following reasons.
1) Interfaces and abstract base classes are not mutually exclusive; both can be
used. Many suggest that both be used. When defining an interface it is useful
to create a Java Interface and Abstract base Class to support the
implementation of the interface.
2) You cannot predict the need for mixins ahead of time. Well defined
interfaces are more likely to be used as mixins down the road.
3) Your approach is to use the abstract base class, as both an interfaces to
callers of the interface and to implementers of the interface; hence the
abstract class ends up providing two "interfaces" :
- the main interface to the callers
- the interface to the implementers of the base class.
The caller then becomes confused about which is their interface. For
example there may be methods in the base class that are to be used by the
implementers or for testing and debugging the abstract class or its
implementation. The callers of the main interface don't need to see any of
these implementation-targeted methods.
4) In some cases you may have multiple base classes providing different
implementation properties for implementing a single interface; the public
interface for both abstract base classes are best defined in a single Java
Interface.
Your observation about the power of abstract class for evolution is right on:
interfaces that are directly implemented by implementations are hard to evolve
because ALL the implementations need to be fixed to add the new methods.
Unfortunately you jumped to the wrong conclusion of using on an abstract base
class for defining an interface. A better approach is to define the interface
as a Java Interface and provide at least one abstract base class for the
implementations for the interface.
> Replace parameters with context objects in Mapper, Reducer, Partitioner,
> InputFormat, and OutputFormat classes
> --------------------------------------------------------------------------------------------------------------
>
> Key: HADOOP-1230
> URL: https://issues.apache.org/jira/browse/HADOOP-1230
> Project: Hadoop Core
> Issue Type: Improvement
> Components: mapred
> Reporter: Owen O'Malley
> Assignee: Owen O'Malley
> Attachments: context-objs-2.patch, context-objs-3.patch,
> context-objs.patch
>
>
> This is a big change, but it will future-proof our API's. To maintain
> backwards compatibility, I'd suggest that we move over to a new package name
> (org.apache.hadoop.mapreduce) and deprecate the old interfaces and package.
> Basically, it will replace:
> package org.apache.hadoop.mapred;
> public interface Mapper extends JobConfigurable, Closeable {
> void map(WritableComparable key, Writable value, OutputCollector output,
> Reporter reporter) throws IOException;
> }
> with:
> package org.apache.hadoop.mapreduce;
> public interface Mapper extends Closable {
> void map(MapContext context) throws IOException;
> }
> where MapContext has the methods like getKey(), getValue(), collect(Key,
> Value), progress(), etc.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
