抽象方法

本文参考原文- http://bjbsair.com/2020-03-22/tech-info/5702/ jad反编译工具，已经不再更新，且只支持JDK1.4，但并不影响其强大的功能。 基本用法：jad xxx.class，会生成直接可读的xxx.jad文件。 自动拆装箱 对于基本类型和包装类型之间的转换，通过xxxValue()和valueOf()两个方法完成自动拆装箱，使用jad进行反编译可以看到该过程： public class Demo { public static void main(String[] args) { int x = new Integer(10); // 自动拆箱 Integer y = x; // 自动装箱 } } 反编译后结果： public class Demo { public Demo(){} public static void main(String args[]) { int i = (new Integer(10)).intValue(); // intValue()拆箱 Integer integer = Integer.valueOf(i); // valueOf()装箱 } } foreach语法糖 在遍历迭代时可以foreach语法糖，对于数组类型直接转换成for循环： // 原始代码 int[] arr = {1, 2,

昨天公司有同事分享了设计模式的一些内容，主要讲了简单工厂，抽象工厂，工厂方法的东西，讲的时候听得不是很明白，就像自己上网调查，并且写一篇博客加深自己的印象 抽象工厂： 　　抽象工厂是对应类这个概念的，也就是说一个类就是一个工厂。一个类里边可以有很多方法，这个是毋庸置疑的，而方法最多只能有一个返回值，假如这个类里边有三个方法，每个方法都一个返回值的话，那么对应抽象工厂来讲就是一个工厂里边有好多的产品线，每个产品线都可以生产一个产品，那么一个工厂就可以生产好多产品。 　　刚才讲的好像跟<抽象>没什么关系，那抽象是怎么体现出来的呢，类是怎么抽象的？提取一些事物的共同特征称其为抽象，像C#里边的接口，抽象类，都是抽象的概念，其实类也是一种抽象，对象才是真真正正具体的东西，就像我们讲<工厂> 他就是一个抽象概念，比如说小明家旁边有两家工厂，一个水泥厂，一个水果糖厂(这两个好像挨着不太好) 你可以说小明家旁边的<水泥厂>是<工厂>，但是你不能说<工厂>是小明家旁边的<水泥厂>,概念颠倒了,小明家旁边的的水果糖厂也是工厂啊。好还是用刚才的例子来举例，用这两种东西来举例有点难，但是咱们就硬着头皮上吧。比如说水泥厂要生产水泥有三种选择，A,B,C型水泥，对应不同的档次，同时呢水果糖厂也有三种选择，A,B,C型水果糖，对应不同的档次，现在我们要生产产品，但是这个水泥和水果糖找共同特征有点难

　 　 工厂方法模式是类的创建模式，又叫做虚拟构造子(Virtual Constructor)模式或者多态性工厂(Polymorphic Factory)模式。工厂方法模式的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。 　　那么工厂方法模式是在什么场景下使用呢，下面就以本人的理解举例说明:相信很多人都做过导入导出功能，就拿导出功能来说。有这么一个需求：XX系统需要支持对数据库中的员工薪资进行导出，并且支持多种格式如：HTML、CSV、PDF等，每种格式导出的结构有所不同，比如：财务跟其他人对导出薪资的HTML格式要求可能会不一样，因为财务可能需要特定的格式方便核算或其他用途。如果使用简单工厂模式，则工厂类必定过于臃肿。因为简单工厂模式只有一个工厂类，它需要处理所有的创建的逻辑。假如以上需求暂时只支持3种导出的格式以及2种导出的结构，那工厂类则需要6个if else来创建6种不同的类型。如果日后需求不断增加，则后果不堪设想。这时候就需要工厂方法模式来处理以上需求。在工厂方法模式中，核心的工厂类不再负责所有的对象的创建，而是将具体创建的工作交给子类去做。这个核心类则摇身一变，成为了一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪一个类应当被实例化这种细节。 　　这种进一步抽象化的结果

描述工厂方法模式： 　　工厂方法模式是类的创建模式，又叫做虚拟构造子(Virtual Constructor)模式或者多态性工厂（Polymorphic Factory）模式。 　　工厂方法模式的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。 那么 工厂方法模式 是在什么场景下使用呢，下面就以本人的理解举例说明: 　　相信很多人都做过导入导出功能，就拿导出功能来说。有这么一个需求：XX系统需要支持对数据库中的员工薪资进行导出，并且支持多种格式如：HTML、CSV、PDF等，每种格式导出的结构有所不同，比如：财务跟其他人对导出薪资的HTML格式要求可能会不一样，因为财务可能需要特定的格式方便核算或其他用途。 　　如果使用简单工厂模式，则工厂类必定过于臃肿。因为简单工厂模式只有一个工厂类，它需要处理所有的创建的逻辑。假如以上需求暂时只支持3种导出的格式以及2种导出的结构，那工厂类则需要6个if else来创建6种不同的类型。如果日后需求不断增加，则后果不堪设想。 　　这时候就需要工厂方法模式来处理以上需求。在工厂方法模式中，核心的工厂类不再负责所有的对象的创建，而是将具体创建的工作交给子类去做。这个核心类则摇身一变，成为了一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口，而不接触哪一个类应当被实例化这种细节。 　　这种进一步抽象化的结果

在阎宏博士的《JAVA与模式》一书中开头是这样描述工厂方法模式的： 　　工厂方法模式是类的创建模式，又叫做虚拟构造子(Virtual Constructor)模式或者多态性工厂（Polymorphic Factory）模式。 　　工厂方法模式的用意是定义一个创建产品对象的工厂接口，将实际创建工作推迟到子类中。 那么 工厂方法模式 是在什么场景下使用呢，下面就以本人的理解举例说明:( 内容转自此文章 ) 　　相信很多人都做过导入导出功能，就拿导出功能来说。有这么一个需求：XX系统需要支持对数据库中的员工薪资进行导出，并且支持多种格式如：HTML、CSV、PDF等，每种格式导出的结构有所不同，比如：财务跟其他人对导出薪资的HTML格式要求可能会不一样，因为财务可能需要特定的格式方便核算或其他用途。 　　如果使用简单工厂模式，则工厂类必定过于臃肿。因为简单工厂模式只有一个工厂类，它需要处理所有的创建的逻辑。假如以上需求暂时只支持3种导出的格式以及2种导出的结构，那工厂类则需要6个if else来创建6种不同的类型。如果日后需求不断增加，则后果不堪设想。 　　这时候就需要工厂方法模式来处理以上需求。在工厂方法模式中，核心的工厂类不再负责所有的对象的创建，而是将具体创建的工作交给子类去做。这个核心类则摇身一变，成为了一个抽象工厂角色，仅负责给出具体工厂子类必须实现的接口

源码地址: https://github.com/weilanhanf/PythonDesignPatterns 简单工厂模式的不足： 在简单工厂模式中，只提供了一个工厂类，该工厂类处于对产品类进行实例化的中心位置，它知道每一个产品对象的创建细节，并决定何时实例化哪一个产品类。简单工厂模式最大的缺点是当有新产品要加入到系统中时，必须修改工厂类，加入必要的处理逻辑，这违背了“开闭原则”。在简单工厂模式中，所有的产品都是由同一个工厂创建，工厂类职责较重，业务逻辑较为复杂，具体产品与工厂类之间的耦合度高，严重影响了系统的灵活性和扩展性，而工厂方法模式则可以很好地解决这一问题。 说明： 工厂方法模式： 定义一个用于创建对象的接口，但是让子类决定将哪一个类实例化。工厂方法模式让一个类的实例化延迟到其子类。 工厂方法模式就是简单工厂模式的进一步抽像。由于面向对象多态性，工厂方法模式保持了简单工厂的有点同时克服了他的缺点。工厂方法模式中，核心的工厂被提升为一个抽象类，将具体的创建工作交给他的子类完成。这个抽象的工厂类仅规定具体工厂实现的接口，而不明确指出如何实例化一个产品类，这使得工厂方法模式允许系统在不修改原有产品结构的情况下轻松的引进新产品。 抽象工厂模式： 提供一个创建一系列相关或相互依赖对象的接口，而无须指定它们具体的类。 抽象工厂模式是所有形式的工厂模式中最为抽象和最具一般性的一种形式

桥梁模式的用意 　　 桥梁模式虽然不是一个使用频率很高的模式，但是熟悉这个模式对于理解面向对象的设计原则，包括“开-闭”原则以及组合/聚合复用原则都很有帮助。理解好这两个原则，有助于形成正确的设计思想和培养良好的设计风格。 　　桥梁模式的用意是“将抽象化(Abstraction)与实现化(Implementation)脱耦，使得二者可以独立地变化”。这句话很短，但是第一次读到这句话的人很可能都会思考良久而不解其意。 　　这句话有三个关键词，也就是抽象化、实现化和脱耦。理解这三个词所代表的概念是理解桥梁模式用意的关键。 　　 实现化 　　抽象化给出的具体实现，就是实现化。 　　一个类的实例就是这个类的实例化，一个具体子类是它的抽象超类的实例化。 　　 脱耦 　　所谓耦合，就是两个实体的行为的某种强关联。而将它们的强关联去掉，就是耦合的解脱，或称脱耦。在这里，脱耦是指将抽象化和实现化之间的耦合解脱开，或者说是将它们之间的强关联改换成弱关联。 　　所谓强关联，就是在编译时期已经确定的，无法在运行时期动态改变的关联；所谓弱关联，就是可以动态地确定并且可以在运行时期动态地改变的关联。显然，在Java语言中，继承关系是强关联，而聚合关系是弱关联。 　　将两个角色之间的继承关系改为聚合关系，就是将它们之间的强关联改换成为弱关联。因此，桥梁模式中的所谓脱耦

不论是在公司内部，还是在面试过程中，经常看到很多开发人员，说想成长为架构师，但是实际上却像一支无头苍蝇一样学习、成长。所以今天我就来简单总结一下，开发人员要成长为一个架构师，都应该学习哪一方面的知识。也就是：架构师的能力模型。 （PS：本文纯属个人见解，并不一定完全正确。对于此类话题，每个人可能都有不同的看法。欢迎大家拍砖。） 开发人员职业发展方向 在说明架构师能力模型前，我得先说明开发人员在职场中的职业发展方向图。 开发者应该根据自己的性格、爱好来选择自己的职业方向。对于性格外向、愿意多与人交流、沟通能力较好的同学，可以考虑向管理方向发展。对于热爱技术、喜欢钻研、性格偏内向的同学，则更适合往技术方向发展。 两个方向并没有好坏之分，只是术业有专攻而已。两个方向也不是完全独立的，对于技术总监、架构师及其以上的岗位，往往也需要较强的沟通能力，以及一定的管理能力。 CTO 是很多开发人员理想中的最终职业方向。但是对于不同的公司而言，对 CTO 要求不尽不同（可以看看 2016年炒得比较火的某 CTO 离职事件）。所以 CTO 也会由不同的岗位成长而来。但是，并不意味着每个人都要以 CTO 为自己的职业目标。 图中黑体的岗位，都可以作为开发人员的职业方向。 对于还没有职业方向的的开发人员来说，选择好一个奋斗的方向， 非常关键。方向对了，就不怕路远！ 方向不清晰，则会做很多徒劳无功的事

3 月，跳不动了？>>> Java中接口与抽象类的区别？ 抽象类：如果一个类含有抽象方法，则称这个类为抽象类，抽象类必须在类前用abstract关键字修饰。因为抽象类中含有无具体实现的方法，所以不能用抽象类创建对象。抽象方法是一种特殊的方法：它只有声明，而没有具体的实现。因为抽象类中含有无具体实现的方法，所以不能用抽象类创建对象。如果一个类继承抽象类，那么就必须为基类中的抽象方法提供定义。如果不这么做，那导出类也为抽象类。 注意，抽象类和普通类的主要有三点区别： 1、抽象方法必须为public或者protected（因为如果为private，则不能被子类继承，子类便无法实现该方法），缺省情况下默认为public。 2、抽象类不能用来创建对象； 3、如果一个类继承于一个抽象类，则子类必须实现父类的抽象方法。如果子类没有实现父类的抽象方法，则必须将子类也定义为abstract类。 接口：可以含有 变量和方法。但是要注意，接口中的变量会被隐式地指定为public static final变量（并且只能是public static final变量，用private修饰会报编译错误），而方法会被隐式地指定为public abstract方法且只能是public abstract方法（用其他关键字，比如private、protected、static、final等修饰会报编译错误）

3 月，跳不动了？>>> 3年工作经验是吧？ 你知道工厂模式分为几类吗？他们都有什么区别？ 那你说说你们项目中是怎么使用工厂模式的？ 带着问题，尤其是面试问题的学习才是最高效的。加油，奥利给！ 文章收录在 GitHub JavaEgg ，N线互联网开发必备技能兵器谱 工厂模式 工厂模式（Factory Pattern）是 Java 中最常用的设计模式之一。这种类型的设计模式属于创建型模式，它提供了一种创建对象的最佳方式。 在工厂模式中，我们在创建对象时不会对客户端暴露创建逻辑，并且是通过使用一个共同的接口来指向新创建的对象。 工厂模式可以分为三类： 简单工厂模式（Simple Factory） 工厂方法模式（Factory Method） 抽象工厂模式（Abstract Factory） 简单工厂其实不是一个标准的的设计模式。GOF 23种设计模式中只有「工厂方法模式」与「抽象工厂模式」。简单工厂模式可以看为工厂方法模式的一种特例，为了统一整理学习，就都归为工厂模式。 这三种工厂模式在设计模式的分类中都属于 创建型模式 ，三种模式从上到下逐步抽象。 创建型模式 创建型模式(Creational Pattern)对类的实例化过程进行了抽象，能够将软件模块中对象的创建和对象的使用分离。为了使软件的结构更加清晰，外界对于这些对象只需要知道它们共同的接口，而不清楚其具体的实现细节