对扩展开放对修改关闭,为了使程序的扩展性好,易于维护和升级。
任何基类可以出现的地方,子类一定可以出现,多使用多态的方式。
尽量多依赖于抽象类或接口而不是具体实现类,对子类具有强制性和规范性
尽量多使用小接口而不是大接口,避免接口的污染,降低类之间耦合度。
一个实体应当尽量少与其他实体之间发生相互作用,使系统功能模块相对独立。高内聚,低耦合。
尽量多使用合成/聚合的方式,而不是继承的方式。
设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。
设计模式就是一种用于固定场合的固定套路。
单例设计模式主要分为:饿汉式 和 懒汉式,懒汉式需要对多线程进行同步处理。
饿汉模式 (立即加载, 线程安全, 推荐):类加载慢, 运行时获取对象快
/*
饿汉式
*/
public class Singleton {
// 2. 使用private static 共同修饰对象的引用
private static Singleton sin = new Singleton();
//1. 私有化构 方法 使用private关键字修饰
private Singleton(){ }
// 3. 提供公有的get方法将对象返回出去,用public static共同修饰
public static Singleton getInstance(){
return sin;
}
}
懒汉模式 (延迟加载, 非线程安全):类加载快, 运行时获取对象慢
/*
懒汉式--双重锁(适用于多线程)
*/
public class Singleton {
// 2.声明本类类型的引用指向本类类型的对象并使用private static关键字修饰
private static Singleton sin = null;
// 1.私有化构造方法,使用private关键字修饰
private Singleton() {}
// 3.提供公有的get方法负责将上述对象返回出去,使用public static关键字修饰
public static Singleton getInstance() {
if (null == sin) {
synchronized (Singleton.class) {
if (null == sin) {
sin = new Singleton();
}
}
}
return sin;
}
}
普通工厂方法模式就是建立一个工厂类,对实现了同一接口的不同实现类进行实例的创建。
Send接口:
public interface Sender {
// 自定义抽象方法来描述发送的行为
void send();
}
Send实现类:
/*
短信形式发送...
*/
public class SmsSender implements Sender {
@Override
public void send() {
System.out.println("正在发送短信...");
}
}
/*
邮件形式发送...
*/
public class MailSender implements Sender {
@Override
public void send() {
System.out.println("正在发送邮件...");
}
}
普通工厂:
public class SendFactory {
// 自定义成员方法实现对象的创建
public Sender produce(String type) {
if ("mail".equals(type)) {
return new MailSender();
}
if ("sms".equals(type)) {
return new SmsSender();
}
return null;
}
测试:
public class SendFactoryTest {
public static void main(String[] args) {
// 缺点:代码复杂,可读性略差
// 优点:扩展性和可维护性更强! 尤其是在创建大量对象的前提下
// 1.声明工厂类类型的引用指向工厂类类型的对象
SendFactory sf = new SendFactory();
// 2.调用生产方法来实现对象的创建
Sender sender = sf.produce("mail");
// 3.使用对象调用方法模拟发生的行为
sender.send(); // 输出:正在发送邮件...
}
}
主要缺点 :在普通工厂方法模式中,如果传递的字符串出错,则不能正确创建对象,并且可能出现空指针异常。
多个工厂:
public class SendFactory {
// 自定义成员方法实现对象的创建
public Sender produce(String type) {
if ("mail".equals(type)) {
return new MailSender();
}
if ("sms".equals(type)) {
return new SmsSender();
}
return null;
}
public Sender produceMail() {
return new MailSender();
}
public Sender produceSms() {
return new SmsSender();
}
}
测试:
public class SendFactoryTest {
public static void main(String[] args) {
// 缺点:代码复杂,可读性略差
// 优点:扩展性和可维护性更强! 尤其是在创建大量对象的前提下
// 1.声明工厂类类型的引用指向工厂类类型的对象
SendFactory sf = new SendFactory();
// 2.调用生产方法来实现对象的创建
Sender sender = sf.produceMail; //多个工厂
// 3.使用对象调用方法模拟发生的行为
sender.send(); // 输出:正在发送邮件...
}
}
主要缺点 :在多个工厂方法模式中,为了能够正确创建对象,先需要创建工厂类的对象才能调用工厂类中的生产方法。
静态工厂:
public class SendFactory {
// 自定义成员方法实现对象的创建
public Sender produce(String type) {
//System.out.println("随便加一句打印进行测试");
if ("mail".equals(type)) {
return new MailSender();
}
if ("sms".equals(type)) {
return new SmsSender();
}
return null;
}
public static Sender produceMail() {
return new MailSender();
}
public static Sender produceSms() {
return new SmsSender();
}
}
测试:
public class SendFactoryTest {
public static void main(String[] args) {
// 缺点:代码复杂,可读性略差
// 优点:扩展性和可维护性更强! 尤其是在创建大量对象的前提下
// 1.声明工厂类类型的引用指向工厂类类型的对象
//SendFactory sf = new SendFactory();
// 2.调用生产方法来实现对象的创建
//Sender sender = sf.produce("mail");
//Sender sender = sf.produce("maill");
//Sender sender = sf.produceMail();
Sender sender = SendFactory.produceMail(); //静态工厂
// 3.使用对象调用方法模拟发生的行为
sender.send();
}
}
工厂方法模式适合:凡是出现了大量的产品需要创建且具有共同的接口时,可以通过工厂方法模式进行创建。
工厂方法模式有一个问题就是,类的创建依赖工厂类,也就是说,如果想要拓展程序生产新的产品,就必须对工厂类的代码进行修改,这就违背了开闭原则。
围绕一个超级工厂创建其他工厂。该超级工厂又称为其他工厂的工厂。
抽象工厂模式提供了一个创建一系列相关或者相互依赖对象的接口,无需指定他们具体的类。
就拿上面的例子来讲,抽象工厂模式对比上面的工厂方法模式区别就是:工厂方法模式是一个工厂类(SendFactory )中有两个生产方法(produceMail()和produceSms())。而抽象工厂就是两个工厂类各自有一个生产方法,然后让两个工厂类实现同一个接口。
适用场景:
客户端不依赖于产品类实例如何被创建、实现等细节。
强调一系列相关的产品对象(属于同一产品族)一起使用创建对象需要大量的重复代码。
提供一个产品类的库,所有的产品以同样的接口出现,从而使得客户端不依赖于具体的实现。
优点:
具体产品在应用层的代码隔离,无需关心创建的细节。
将一个系列的产品统一到一起创建。
1、简单工厂模式(静态工厂模式):虽然某种程度上不符合设计原则,但实际使用最多。
2、工厂方法模式:不修改已有类的前提上,通过增加新的工厂类实现扩展。
3、抽象工厂模式:不可以增加产品,可以增加产品族。
1、JDk中Calendar的getInstance方法
2、JDBC中的Connection对象的获取
3、Spring中IOC容器创建管理bean对象
4、反射中Class对象的newInstance方法
实例化对象不使用new,用工厂方法替代。
将选择实现类,创建对象统一管理和控制,从而将调用者跟我们的实现类解耦。
装饰器模式就是给一个对象动态的增加一些新功能,要求装饰对象和被装饰对象实现同一个接口,装饰对象持有被装饰对象的实例。
可以实现一个类功能的扩展。可以动态的增加功能,而且还能动态撤销(继承不行)。
缺点:产生过多相似的对象,不易排错。
代理模式就是找一个代理类替原对象进行一些操作。
如果在使用的时候需要对原有的方法进行改进,可以采用一个代理类调用原有方法,并且对产生的结果进行控制,这种方式就是代理模式。
使用代理模式,可以将功能划分的更加清晰,有助于后期维护。
接口:
public interface Sourceable {
// 自定义抽象方法
void method();
}
真实对象:
public class Source implements Sourceable {
@Override
public void method() {
System.out.println("--我是真实对象,也就是被代理的对象(房东)");
}
}
代理对象:
public class Proxy implements Sourceable {
private Source source;
public Proxy() {
source = new Source();
}
@Override
public void method() {
source.method();
System.out.println("我是代理对象!(中介)");
}
}
访问测试:
public class SourceableTest {
public static void main(String[] args) {
// 使用代理类实现功能(找中介租房)
Sourceable sourceable = new Proxy();
sourceable.method();
}
}
- 装饰器模式通常的做法是将原始对象作为一个参数传给装饰者的构造器,而代理模式通常在一个代理类中创建一个被代理类的对象。
- 装饰器模式关注于在一个对象上动态的添加方法,然而代理模式关注于控制对对象的访问。
模板方法模式主要指一个抽象类中封装了一个固定流程,流程中的具体步骤可以由不同子类进行不同的实现,通过抽象类让固定的流程产生不同的结果。
我有一个模型:classItem项目有一个属性“商店”基于存储的值,我希望Item对象对特定方法具有不同的行为。Rails中是否有针对此的通用设计模式?如果方法中没有大的if-else语句,这是如何干净利落地完成的? 最佳答案 通常通过Single-TableInheritance. 关于ruby-on-rails-Rails-子类化模型的设计模式是什么?,我们在StackOverflow上找到一个类似的问题: https://stackoverflow.co
大约一年前,我决定确保每个包含非唯一文本的Flash通知都将从模块中的方法中获取文本。我这样做的最初原因是为了避免一遍又一遍地输入相同的字符串。如果我想更改措辞,我可以在一个地方轻松完成,而且一遍又一遍地重复同一件事而出现拼写错误的可能性也会降低。我最终得到的是这样的:moduleMessagesdefformat_error_messages(errors)errors.map{|attribute,message|"Error:#{attribute.to_s.titleize}#{message}."}enddeferror_message_could_not_find(obje
我主要使用Ruby来执行此操作,但到目前为止我的攻击计划如下:使用gemsrdf、rdf-rdfa和rdf-microdata或mida来解析给定任何URI的数据。我认为最好映射到像schema.org这样的统一模式,例如使用这个yaml文件,它试图描述数据词汇表和opengraph到schema.org之间的转换:#SchemaXtoschema.orgconversion#data-vocabularyDV:name:namestreet-address:streetAddressregion:addressRegionlocality:addressLocalityphoto:i
鉴于我有以下迁移:Sequel.migrationdoupdoalter_table:usersdoadd_column:is_admin,:default=>falseend#SequelrunsaDESCRIBEtablestatement,whenthemodelisloaded.#Atthispoint,itdoesnotknowthatusershaveais_adminflag.#Soitfails.@user=User.find(:email=>"admin@fancy-startup.example")@user.is_admin=true@user.save!ende
我将应用程序升级到Rails4,一切正常。我可以登录并转到我的编辑页面。也更新了观点。使用标准View时,用户会更新。但是当我添加例如字段:name时,它不会在表单中更新。使用devise3.1.1和gem'protected_attributes'我需要在设备或数据库上运行某种更新命令吗?我也搜索过这个地方,找到了许多不同的解决方案,但没有一个会更新我的用户字段。我没有添加任何自定义字段。 最佳答案 如果您想允许额外的参数,您可以在ApplicationController中使用beforefilter,因为Rails4将参数
给定一个复杂的对象层次结构,幸运的是它不包含循环引用,我如何实现支持各种格式的序列化?我不是来讨论实际实现的。相反,我正在寻找可能会派上用场的设计模式提示。更准确地说:我正在使用Ruby,我想解析XML和JSON数据以构建复杂的对象层次结构。此外,应该可以将该层次结构序列化为JSON、XML和可能的HTML。我可以为此使用Builder模式吗?在任何提到的情况下,我都有某种结构化数据-无论是在内存中还是文本中-我想用它来构建其他东西。我认为将序列化逻辑与实际业务逻辑分开会很好,这样我以后就可以轻松支持多种XML格式。 最佳答案 我最
目录前言滤波电路科普主要分类实际情况单位的概念常用评价参数函数型滤波器简单分析滤波电路构成低通滤波器RC低通滤波器RL低通滤波器高通滤波器RC高通滤波器RL高通滤波器部分摘自《LC滤波器设计与制作》,侵权删。前言最近需要学习放大电路和滤波电路,但是由于只在之前做音乐频谱分析仪的时候简单了解过一点点运放,所以也是相当从零开始学习了。滤波电路科普主要分类滤波器:主要是从不同频率的成分中提取出特定频率的信号。有源滤波器:由RC元件与运算放大器组成的滤波器。可滤除某一次或多次谐波,最普通易于采用的无源滤波器结构是将电感与电容串联,可对主要次谐波(3、5、7)构成低阻抗旁路。无源滤波器:无源滤波器,又称
项目介绍随着我国经济迅速发展,人们对手机的需求越来越大,各种手机软件也都在被广泛应用,但是对于手机进行数据信息管理,对于手机的各种软件也是备受用户的喜爱小学生兴趣延时班预约小程序的设计与开发被用户普遍使用,为方便用户能够可以随时进行小学生兴趣延时班预约小程序的设计与开发的数据信息管理,特开发了小程序的设计与开发的管理系统。小学生兴趣延时班预约小程序的设计与开发的开发利用现有的成熟技术参考,以源代码为模板,分析功能调整与小学生兴趣延时班预约小程序的设计与开发的实际需求相结合,讨论了小学生兴趣延时班预约小程序的设计与开发的使用。开发环境开发说明:前端使用微信微信小程序开发工具:后端使用ssm:VU
了解Rails缓存如何工作的人可以真正帮助我。这是嵌套在Rails::Initializer.runblock中的代码:config.after_initializedoSomeClass.const_set'SOME_CONST','SOME_VAL'end现在,如果我运行script/server并发出请求,一切都很好。然而,在我的Rails应用程序的第二个请求中,一切都因单元化常量错误而变得糟糕。在生产模式下,我可以成功发出第二个请求,这意味着常量仍然存在。我已通过将以上内容更改为以下内容来解决问题:config.after_initializedorequire'some_cl
我在我的项目中有一个用户和一个管理员角色。我使用Devise创建了身份验证。在我的管理员角色中,我没有任何确认。在我的用户模型中,我有以下内容:devise:database_authenticatable,:confirmable,:recoverable,:rememberable,:trackable,:validatable,:timeoutable,:registerable#Setupaccessible(orprotected)attributesforyourmodelattr_accessible:email,:username,:prename,:surname,: