[jira] Issue Comment Edited: (COMPRESS-61) ArchiveStreamFactory could have static methods as well

["Dmitry Katsubo (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/COMPRESS-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12841301#action_12841301 ] 

Dmitry Katsubo edited comment on COMPRESS-61 at 3/4/10 4:05 PM:
----------------------------------------------------------------

Torsten, I completely understand your position and argumentation. But in 99% of the cases this factory will be used just to create available compressors. In another 1% of the cases I would possibly extend current factory with some more exotic compressor, which only I know how to implement. OK, in this case my steps are:
- I need to create {{MyArchiveStreamFactory}} that extends {{ArchiveStreamFactory}} and override e.g. {{createArchiveInputStream()}}
- Now I need to pass this factory somewhere. What type I will pass? Of course, I can pass more generic type {{ArchiveStreamFactory}} and it will work fine, as it has methods overridden. But will I put put compile-time dependency on the rest of my project on {{commons-compress}} library? No. So I will pass {{MyArchiveStreamFactory}} and I don't mind in my implementation, how to call the parent method: statically or via {{super.}}.

The situation changes, if I _introduce the interface for the factory_. As there are no interfaces defined in {{commons-compress}}, I will use some infrastructure, which is build on the top of existing {{ArchiveStreamFactory}}. And again, it brings no benefits on how {{ArchiveStreamFactory.createArchiveInputStream()}} is exposed.

So I would say: _using {{static}} methods for factory methods does not limit its usage_. All above is just my opinion, which may be wrong. If you have any counter-cases, please, comment.

      was (Author: dma_k):
    Torsten, I completely understand your position and argumentation. But in 99% of the cases this factory will be used just to create available compressors. In another 1% of the cases I would possibly extend current factory with some more exotic compressor, which only I know how to implement. OK, in this case my steps are:
- I need to create {{MyArchiveStreamFactory}} that extends {{ArchiveStreamFactory}} and override e.g. {{createArchiveInputStream()}}
- Now I need to pass this factory somewhere. What type I will pass? Of course, I can pass more generic type {{ArchiveStreamFactory}} and it will work fine, as it has methods overridden. But will I put put compile-time dependency on the rest of my project on {{commons-compress}} library? No. So I will pass {{MyArchiveStreamFactory}}.

The situation changes, if I _introduce the interface for the factory_. As there are no interfaces defined in {{commons-compress}}, I will use some infrastructure, which is build on the top of existing {{ArchiveStreamFactory}}. And again, it brings no benefits on how {{ArchiveStreamFactory.createArchiveInputStream()}} is exposed.

So I would say: _using {{static}} methods for factory methods does not limit its usage_. All above is just my opinion, which may be wrong. If you have any counter-cases, please, comment.
  
> ArchiveStreamFactory could have static methods as well
> ------------------------------------------------------
>
>                 Key: COMPRESS-61
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-61
>             Project: Commons Compress
>          Issue Type: Improvement
>            Reporter: Sebb
>
> ArchiveStreamFactory currently has to be instantiated in order to use it.
> The methods have to be instance methods in order for subclasses to override them, but until that is done (will it ever be done?) it seems a bit unnecessary to create an instance of the class.
> Perhaps there could be a private static instance of the class that could be used with public static methods?
> The same considerations apply to the other factories.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.