在多文件输出情况下使用哪种设计模式?

时间:2016-12-15 06:03:04

标签: design-patterns

我手头有一个问题,我必须生成多种类型的文件输出,如PDF,Excel,文本文件等,数据取决于用户输入。

我正在尝试实现一个设计模式,它将帮助我摆脱设计缺陷,并让我在未来证明一些新的文件输出类型。

我已经注意到工厂和战略模式,但无法在两者之间做出决定。

请建议在上述情况中挑选哪一个以及为什么?此外,如果还可以在此处实施任何其他设计模式吗?

1 个答案:

答案 0 :(得分:1)

我建议使用提供商和策略模式,结合工厂模式。 如果我理解正确,您需要以下内容: 1.生成多种文件类型,比如来自{T1,... Tn}的n种类型 2.类型的数量不固定 - 将来有可能增加这个数字。 3.如果需要新类型,您希望确保将来对应用程序所做的修改最小化。

这是我的方法。

  1. 将可能的文件类型/扩展名的类型配置为属性
  2. 提供程序的实现类包含基于转换和修改策略的格式的任何文件类型转换的代码。
  3. Factory方法用于获取提供者。
  4. 详情:

    PFB代码

    提供者:

    public interface ConversionProvider {
    
        public SupportedFile convert(String inputFilePath);
    
        public void register();
    
    }
    
    
    
     public class ExcelProvider implements ConversionProvider{
    
        private ZipStrategy zipStrategy;
    
        @Override
        public ExcelFile convert(String inputFilePath) {
            // TODO Auto-generated method stub
            return new ExcelFile();
        }
    
        @Override
        public void register() {
            // TODO Auto-generated method stub
    
        }
    }
    

    工厂:

    public abstract class ConversionTypeFactory {
    
        protected ConversionProvider provider;
    
        /**
         * Conversion Provider for the input Type.
         * @return
         */
        public abstract ConversionProvider getProvider(); 
    }
    
    public class ExcelTypeFactory extends ConversionTypeFactory{
    
        @Override
        public ConversionProvider getProvider() {
            // TODO Auto-generated method stub
            provider = new ExcelProvider();
            return provider;
        }
    
    }
    

    文件层次结构

    public class SupportedFile {
    
        protected String fullQualifiedPath;
    }
    
    public class ExcelFile extends SupportedFile{
    
    }
    

    策略

    public class FileStrategy {
    
    }
    
    public class ZipStrategy extends FileStrategy{
    
        private String compressionMode;
        private String encryptionType;
    }
    
    public class SplitStrategy extends FileStrategy{
    
        private int defaultBlocksCount;
    }
    

    调用:

    public class UseProvider {
    
        /**
         * @param args
         */
        public static void main(String[] args) {
            // TODO Auto-generated method stub
            String name="Excel"; //Assume to be read from property or assigned dynamically
            ExcelFile file;
            String inputFilePath="";
            ConversionTypeFactory factory;
            if(name.equals("Excel")){
                factory = new ExcelTypeFactory();
                file= (ExcelFile) factory.getProvider().convert(inputFilePath);
            }
        }
    
    }
    

    问:保持三种模式相互混淆,这是一种过度杀伤吗? 答: - 这个问题的答案取决于您的具体要求。我考虑过一个复杂的系统,其中最好分解与您的要求相关的每一个问题。它将简化维护,打包和依赖管理。

    问:我将采用哪些方案来保留三种模式? 答: - 规模能力,隔离和易用性的场景。 如果我们需要新的文件类型,添加属性,添加工厂子类,添加转换提供程序,可以使用预定义的策略。您的策略永远不会与您的提供商混淆。您的供应商永远不会与您的工厂混在一起。

    未来案例和扩展: - 如果将来需要一些文件合并要求,只需添加一个策略子类,然后继续。如果要求FileOperations需要扩展以适应ETL生态系统,那么提供者可以轻松地作为服务工作(当然,在这种情况下,名称必须更明确),可以在系统中注册,工厂是重新使用。

    使用这种方法,您可以自由地将服务和策略打包在一个单独的jar中,只需在相关项目中添加依赖项。

    如果这符合您的目的,请告诉我。