精华内容
下载资源
问答
  • Java设计模式——单一职责模式

    千次阅读 2018-05-23 10:22:20
    今天和大家聊一聊单一职责模式,大家从名字应该就能想到这个设计模式的核心思想就是降低耦合性,强调一个类/整体只做一件事。今天就不给大家代码举例子了,因为这个会很好理解,你只要写一个类,强调一个方法,方法...

    今天和大家聊一聊单一职责模式,大家从名字应该就能想到这个设计模式的核心思想就是降低耦合性,强调一个类/整体只做一件事。今天就不给大家代码举例子了,因为这个会很好理解,你只要写一个类,强调一个方法,方法只实现一种功能举行啦!

    单一职责模式:就一个类而言,应该仅有一个引起它变化的原因。

    有的同学会问,一个类如果只是有且仅有一个因素来引起他的变化,岂不是我们的程序的代码会非常臃肿?这个情况我们要视情况而定,其实在生活中也是,我们如果做到一件事情的专精,那就要舍弃一些其他方面的功能。例如我们的手机可以照相,但是他的专业程度不如数码摄像机,再比如我们的交通工具,汽车负责马路,轮船负责大海,飞机负责天空一样,我们要做到一件事情让他专精一个功能。

    在一些特定的情况下,一个类我们只让他承担一个特定的职责,如果一个类承担的职责过多,就等于把这些职责耦合在一起,这是我们编程思想中所忌讳的,程序员一直都再致力于使我们的代码简洁化,我们常说的就是让代码高内聚低耦合,降低代码的耦合性,这样我们在如果对代码中的一个功能模块进行修改时,我们只需要修改特定功能的类即可,从而不会影响其他功能的代码。如果我们提高功能代码的耦合性,那我们设计的代码就会非常脆弱,当一个功能代码发生变化时,我们的代码设计就会招到破坏,影响是非常大的。

    我们在实际开发中,会发现软件的功能是非常多的,我们不能盲目的去分离代码和职能,我们一定要去判断这些功能是否需要分离,我们的分离原则就是相同功能的类我们提取使用工厂和策略模式,如果功能不同我们可以让这个类职责单一化,即分离出来。

    还有一个就是如果这个类有很多的动机或者因素来改变它,我们就需要考虑分离它,使它的功能单一化。

    今天的单一职责模式不太好写代码或者太容易写出代码,我们要根据我们的项目区思考,什么时候会去用到它,什么时候是不需要分离类的。作为一个程序员,我们一定要加入自己的思考,而不只是作为一个代码的搬运工。

     示例代码如下:

    class Animal{
        public void breathe(String animal){
            System.out.println(animal+"呼吸空气");
        }
    
        public void breathe2(String animal){
            System.out.println(animal+"呼吸水");
        }
    }
    
    public class Client{
        public static void main(String[] args){
            Animal animal = new Animal();
            animal.breathe("牛");
            animal.breathe("羊");
            animal.breathe("猪");
            animal.breathe2("鱼");
        }
    }





    Good luck!

    Write by Jimmy.li





    展开全文
  • 单一职责模式的核心思想: 一个类,最好只做一件事,只有一个引起它变化的原因 与其相关的设计模式包括外观模式设计和代理模式设计 外观模式: 外观模式(Facade)为子系统中的一组接口提供一个一致的界面,此...

    单一职责模式的核心思想:

    一个类,最好只做一件事,只有一个引起它变化的原因

    与其相关的设计模式包括外观模式设计和代理模式设计

    外观模式:

    外观模式(Facade)为子系统中的一组接口提供一个一致的界面,此模式定义了一个高层接口,这个接口使得这一子系统更加容易使用。

    在大话设计模式里通过引用股卖买进卖出的原理举了一个例子

    股民炒股代码

    //股票1
        class Stock1
        {
            //卖股票
            public void Sell()
            {
                Console.WriteLine("股票1卖出");
            }
            public void Buy()
            {
                Console.WriteLine("股票1买入");
            }
        }
    //股票2
        class Stock2
        {
             与股票1类似
        }
    //国债
        class NationalDebt1
        {
             与股票1类似
        }
    //房地产
        class Realty1
        {
             与股票1类似
        }
     //基金类,它需要了解所有的股票或其他投资方式的方法或属性,进行组合,以备外界调用
        class Fund
        {
            Stock1 gu1;
            Stock2 gu2;
            NationalDebt1 nd1;
            Realty1 rt1;
            public Fund()
            {
                gu1 = new Stock1();
                gu2 = new Stock2();
                nd1 = new NationalDebt1();
                rt1 = new Realty1();
            }
            public void BuyFund()
            {
                gu1.Buy();
                gu2.Buy();
                nd1.Buy();
                rt1.Buy();
            }
            public void SellFund()
            {
                gu1.Sell();
                gu2.Sell();
                nd1.Sell();
                rt1.Sell();
            }
        }
    //客户端代码
            static void Main(string[] args)
            {
                Fund jijin = new Fund();
                //基金购买
                jijin.BuyFund();
                //基金卖出
                jijin.SellFund();
                Console.ReadLine();
            }

    一般而言,外观模式使用于以下场合:(粘贴)

    第一:为一个复杂的子系统提供一个简单的接口。子系统往往因为不断的演化而变的越来越复杂,使用外观模式可以保持外部系统对子系统调用的简洁性,而那些需要细节调用的用户却可以越过外观模式直接对子系统进行调用。

    第二:引进外观模式可以将一个子系统和使用它的客户端以及其它的子系统分离开来,这就提高了子系统的独立性和可移植性。

    第三:在构建一个层次化结构的时候,可以使用外观模式定义每一个层次对外交互的接口。此时,层与层之间只需要通过外观进行通信,从而简化层与层之间的依赖关系。

           外观模式是一种得到广泛应用的模式,例如我们熟知的MVC模式就采用了外观模式。在MVC,在MVC架构模式中,每一层并不需要知道其它层次的细节,只是通过层与层之间的接口调用即可。这大大的方便了开发。

    二、代理模式

    实现方式主要是定义一个接口,代理类和normal类实现相依的方法,可以在代理类里进行一些判断客户端调用代理类,对于一些功能复杂的可以抽离出一个代理类。

     

    转载于:https://www.cnblogs.com/kaixinxingfu/archive/2012/11/12/2766308.html

    展开全文
  • 设计模式单一职责原则学习

    千次阅读 多人点赞 2012-05-03 11:07:20
    单一职责原则:就一个类而言应该仅有一个引起它变化的原因。 比如写一个窗口应用程序。我们会创建一个类,将各种各样的代码,如某种算法的代码或是访问数据库的代码,都放在这个类中。以后一旦需求有所更改就必须...

    单一职责原则:就一个类而言应该仅有一个引起它变化的原因。

    比如写一个窗口应用程序。我们会创建一个类,将各种各样的代码,如某种算法的代码或是访问数据库的代码,都放在这个类中。以后一旦需求有所更改就必须修改这个类。各个功能的耦合性太大,牵一发而动全身。维护很麻烦,复用不可能,也缺乏灵活性。

    由于c语言是我的第一门编程语言,这么多年的使用,面向过程的思想早已根深蒂固。短时间很难培养起使用面向对象开发的习惯。看来任何东西都有两面性,在学C++之前先学习C语言可能对入门有帮助,但也有一些弊端。世上很多东西都是矛盾的,重要的是要从这些矛盾中找到一个平衡点。

    如果一个类承担的功能过多,就等于把这些职责偶合在一起,一个职责的变化可能会削弱或抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的破坏。

    俄罗斯方块游戏的设计

    应该考虑将程序至少分为两个类:一个是窗口类,用于处理界面交互。另一个是游戏逻辑类。当有一天要改变界面或是移植到其他平台上就不涉及游戏逻辑的改变。

    对于游戏逻辑设计,方块的可移动区域,可以用一个二维数组进行表示。对方块的各种操作就是对二维数组值进行的操作。。我觉得也需要两个大类,首先是各种图形的表示类,比如口型,L型,1型。给出它的各个成员在二维数组的坐标。它们应该从一个共同的基类继承。另外一个是对图形类进行操作的操作类。比如左移、右移、变形以及碰撞检测、消行等。可以考虑使用策略模式来对各个图形类进行管理。

        代码稍后奉上。。。。。
    
    


          软件设计真正要做的内容,就是发现职责并把那些指职责分离。如果能找出多于一个动机去改变一个类,这个类就具有多个职责,此时就应该考虑职责分离。

     

    展开全文
  • 单一职责原则:就一个类而言,应该仅有一个引起它变化的原因! 如果一个类承担的职责过多,就等于把... 单一职责原则,其核心的思想是:一个类,最好只做一件事,只有一个引起它变化的原因。一个优良的系统设计,强
    单一职责原则:就一个类而言,应该仅有一个引起它变化的原因!

     

    如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力。这种耦合会导致脆弱的设计,当变化发生时,设计会遭受意想不到的破坏!

     

     

    单一职责原则,其核心的思想是:

    一个类,最好只做一件事,只有一个引起它变化的原因。

    一个优良的系统设计,强调模块间保持低耦合、高内聚的关系,在面向对象设计中这条规则同样适用,所以面向对象的第一个设计原则就是:单一职责原则(SRP,Single Responsibility Principle)。

    单一职责,强调的是职责的分离,在某种程度上对职责的理解,构成了不同类之间耦合关系的设计关键,因此单一职责原则或多或少成为设计过程中一个必须考虑的基础性原则。

     

    单一职责原则可以看作是低耦合、高内聚在面向对象原则上的引申,将职责定义为引起变化的原因,以提高内聚性来减少引起变化的原因。职责过多,可能引起它变化的原因就越多,这将导致职责依赖,相互之间就产生影响,从而极大的损伤其内聚性和耦合度。单一职责,通常意味着单一的功能,因此不要为类实现过多的功能点,以保证实体只有一个引起它变化的原因。

     

    关于单一职责原则,建议是:

    1. 一个类只有一个引起它变化的原因,否则就应当考虑重构。
    2. SRP由引起变化的原因决定,而不由功能职责决定。虽然职责常常是引起变化的轴线,但是有时却未必,应该审时度势。
    3. 测试驱动开发,有助于实现合理分离功能的设计。
    4. 可以通过Façade模式或Proxy模式进行职责分离。

     

     

     

                                  二〇〇九年十一月五日

    展开全文
  • 需要说明的一点是,单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都适用单一职责原则。比如说单一职责原则不仅仅适用于类,还适用于方法。 单一职责原则针对的问题 有一个类T负责两个不同...
  • 今天和大家聊一聊单一职责模式,大家从名字应该就能想到这个设计模式的核心思想就是降低耦合性,强调一个类/整体只做一件事。今天就不给大家代码举例子了,因为这个会很好理解,你只要写一个类,强调一个方法,方法...
  • 在设计模式中,有着几条视为黄金原则,设计模式都是围绕黄金原则,对代码或者说是架构设计做出一些相应的调整,久而久之,GoF 4人组,发现其实有些设计思想可以称为模式,能实现代码复用的好处,从而设计模式出世。...
  • 问题 责任链模式的引入需要从外观模式和代理模式引入,我们因为不希望顾客不停的和不同部门和人员打交道,设置了接待经理,由接待经理统一负责。又因为接待经理可能会过于繁忙,所以给他请...责任链模式思想几乎遍布
  • 0.设计模式思想

    2015-06-26 13:44:07
    1.说明 该篇不涉及具体的设计模式,而是对相关编程思想的总结,而具体...2.单一职责模式 就一个类而言,应该仅有一个引起它变化的原因 如果一个类职责过多,就等于把这些职责耦合在一起,一个职责的变化,可能会削
  • 设计模式思想

    千次阅读 2011-04-16 22:41:00
    1.单一职责:就一个类而言,应该仅有一个引起它变化的原因。职责要单一。否则如果一个代码块完成了超过一件的事情,意味着这段代码的移植性受到了影响,因为一次移植就打包移动了两段逻辑。而且不稳定,因为可能任何...
  • 面向对象思想设计原则 单一职责原则 开闭原则 里氏替换原则 依赖注入原则 接口分离原则 迪米特原则 设计模式的分类 简单工厂模式 简单工厂模式概述 工厂方法模式 工厂方法模式概述 单例设计模式 单例设计模式概述 ...
  • 在之前的java 23 中,了解过设计模式的单例模式和工厂模式。在这里,介绍下设计模式 面向对象思想设计原则  在实际的开发中,我们要想更深入的了解面向对象思想,就必须熟悉前人总结过的面向对象的思想的设计...
  • 由来:单一职责原则的由来,是面向对象核心思想,高内聚 低耦合,中的高内聚体现,一个类只负责一个类改做的事情,职责分清楚,写一个案例来体现:以下案例是违反了单一职责原则的模拟代码:public class Main { // ...
  • 2.核心思想 降低类的复杂度,一个类只负责一项职责。 提高类的可读性、可维护性。 降低变更引起的风险。 通常情况下,我们应当遵守单一职责原则。只有逻辑足够简单,才可在代码级别违反单一职责原则。类中方法数量...
  • 面向对象思想设计原则 在实际的开发中,我们要想更深入的了解面向对象思想,就必须熟悉前人...在设计模式中,所有的设计模式都遵循这一原则。 开闭原则 开闭原则 核心思想是:一个对象对扩展开放,对修改关闭...
  • 定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。 遵循单一职责原的优点有: 1、可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定...单一职责原则不只是面向对象编程思想所特有
  • 单一职责原则:就一个类而言,应该仅有一个引起它变化的原因; 2.策略模式UML图 3.java代码示例 4.OOP 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会消弱或者抑制这个类完成其他职责...
  • 设计模式原则 总原则:开闭原则(Open Close Principle) 开闭原则就是说对扩展开放,对修改关闭。在程序需要进行拓展的时候,不能去修改原有的代码,而是要扩展原有代码,实现一个热插拔的效果。所以一句话...
  • 设计模式的六大原则已经学了五个了,本来想的学完这本书了再总结,怕时间长了会忘了,能理解多少先总结多少吧,以后学到新的东西再补充。 核心思想 单一指责原则(SRP):就一个类而言,应该仅有一个引起它变化的...
  • 命令设计模式首先需要一个只有单一方法的接口,然后从该接口实现具有各自不同的行为的多个子类。接下来,程序员就可以构造命令对象,并在需要的时候使用它们: package com; import java.util.*; import static ...
  • 现在的软件行业已经烂了,干了一两年,学了点23种设计模式,就是在简历上写上精通软件设计模式,深入了解SOA、OOP和OOD等编程思想,针对这个问题面试中我就提到既然精通设计模式了那设计模式的设计原则有几种分别是...
  • 1、单一职责原则 ( SRP ) 2、开闭原则 ( OCP ) 3、里氏替换原则 ( LSP ) 4、依赖倒置原则 ( DIP ) 5、接口隔离原则 ( ISP ) 6、最少知道原则(迪米特原则) 7、合成/聚合复用(CARP) 三、创建型模式 ( 5种 ) ...
  • 1.设计模式的目的 设计模式是为了更好的代码重用性,可读性,可靠性,可维护性。 2.常用的六大设计模式 1)单一职责原则 2)里氏替换原则 3)依赖倒转原则 4)接口隔离原则 5)迪米特法则 6)开闭原则 单一职责 ...
  • 单一职责原则是模块化设计思想的基本教义,基本得让很多人甚至不屑提起。但是如何划分模块,尤其当项目达到一定的复杂度后,如何恰如其分地划分模块粒度,是非常能体现工程师功力的。可以说,合理划分模块,是做好...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 733
精华内容 293
关键字:

思想模式单一