软件实现接口原则（软件实现接口原则有哪些）

本篇文章给大家谈谈软件实现接口原则，以及软件实现接口原则有哪些对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享软件实现接口原则的知识，其中也会对软件实现接口原则有哪些进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、android实现接口时有几个原则
• 2、软件开发涉及到的六个重要原则？
• 3、通常在软件开发中设计模式都有哪些原则呢？
• 4、软件设计原则有哪些
• 5、完成良好的软件设计应遵循哪些原则

android实现接口时有几个原则

1、Throwable接口中的getStackTrace()方法（或者Thread类的getStackTrace()方法），根据这个方法可以得到函数的逐层调用地址，其返回值为StackTraceElement[]；
2、StackTraceElement类，其中四个方法getClassName()，getFileName()，getLineNumber()，getMethodName()在调试程序打印Log时非常有用；
3、UncaughtExceptionHandler接口，再好的代码异常难免，利用此接口可以对未捕获的异常善后；
使用参见：Android使用UncaughtExceptionHandler捕获全局异常
4、Resources类中的getIdentifier(name, defType, defPackage)方法，根据资源名称获取其ID，做UI时经常用到；
5、View中的isShown()方法，以前都是用view.getVisibility() == View.VISIBLE来判断的(╯□╰)；（谢评论提醒，这里面其实有一个坑：【android】view.isShown ()的用法）
6、Arrays类中的一系列关于数组操作的工具方法：binarySearch()，asList()，equals()，sort()，toString()，copyOfRange()等；
Collections类中的一系列关于集合操作的工具方法：sort()，reverse()等；
7、android.text.format.Formatter类中formatFileSize(Context, long)方法，用来格式化文件Size（B → KB → MB → GB）；
8、android.media.ThumbnailUtils类，用来获取媒体（图片、视频）缩略图；
9、String类中的format(String, Object...)方法，用来格式化strings.xml中的字符串（多谢 @droider An 提示：Context类中getString(int, Object... )方法用起来更加方便）；
10、View类中的三个方法：callOnClick()，performClick()，performLongClick()，用于触发View的点击事件；
11、TextUtils类中的isEmpty(CharSequence)方法，判断字符串是否为null或""；
12、TextView类中的append(CharSequence)方法，添加文本。一些特殊文本直接用+连接会变成String；
13、View类中的getDrawingCache()等一系列方法，目前只知道可以用来截图；
14、DecimalFormat类，用于字串格式化包括指定位数、百分数、科学计数法等；
15、System类中的arraycopy(src, srcPos, dest, destPos, length)方法，用来copy数组；
16、Fragment类中的onHiddenChanged(boolean)方法，使用FragmentTransaction中的hide()，show()时貌似Fragment的其它生命周期方法都不会被调用，太坑爹！
17、Activity类中的onWindowFocusChanged(boolean)，onNewIntent(intent)等回调方法；
18、View类中的getLocationInWindow(int[])方法和getLocationOnScreen(int[])方法，获取View在窗口/屏幕中的位置；
19、TextView类中的setTransformationMethod(TransformationMethod)方法，可用来实现“显示密码”功能；
20、TextWatcher接口，用来监听文本输入框内容的改变，可用来实现一系列具有特殊功能的文本输入框；
21、View类中的setSelected(boolean)方法结合android:state_selected=""用来实现图片选中效果；
22、Surface设置透明：SurfaceView.setZOrderOnTop(true);
SurfaceView.getHolder().setFormat(PixelFormat.TRANSLUCENT);但是会挡住其它控件；
23、ListView或GridView类中的setFastScrollEnabled(boolean)方法，用来设置快速滚动滑块是否可见，当然前提是item够多；
24、PageTransformer接口，用来自定义ViewPager页面切换动画，用setPageTransformer(boolean, PageTransformer)方法来进行设置；
25、apache提供的一系列jar包：commons-lang.jar，commons-collections.jar，commons-beanutils.jar等，里面很多方法可能是你曾经用几十几百行代码实现过的，但是执行效率或许要差很多，比如：ArrayUtils，StringUtils……；
26、AndroidTestCase类，Android单元测试，在AndroidStudio中使用非常方便；
27、TextView类的setKeyListener(KeyListener)方法；
其中DigitsKeyListener类，使用getInstance(String accepted)方法即可指定EditText可输入字符集；
28、ActivityLifecycleCallbacks接口，用于在Application类中监听各Activity的状态变化；
29、Context类中的createPackageContext(packageName, flags)方法，可用来获取指定包名应用程序的Context对象。

软件开发涉及到的六个重要原则？

软件开发原则问题我们已经给大家在前几期的文章中多次强调了其重要性。尤其是不能违反用户的常规使用习惯。今天，IT培训http://www.kmbdqn.cn/就一起来了解一下，软件开发原则中的六个比较重要的原则都有哪些。

一、单一职责原则

1、单一职责定义

单一职责原则：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。

单一职责原则告诉我们：一个类不能太“累”!在软件系统中，一个类承担的职责越多，它被复用的可能性就越小，而且一个类承担的职责过多，就相当于将这些职责耦合在一起，当其中一个职责变化时，可能会影响其

他职责的运作，因此要将这些职责进行分离，将不同的职责封装在不同的类中，即将不同的变化原因封装在不同的类中，如果多个职责总是同时发生改变则可将它们封装在同一类中。

2、单一职责优点

1)降低了类的复杂度。一个类只负责一项职责比负责多项职责要简单得多。

2)提高了代码的可读性。一个类简单了，可读性自然就提高了。

3)提高了系统的可维护性。代码的可读性高了，并且修改一项职责对其他职责影响降低了，可维护性自然就提高了。

4)变更引起的风险变低了。单一职责大的优点就是修改一个功能，对其他功能的影响显著降低。

二、里氏代换原则

这个和单一职责原则比起来，显然就好理解多了，而且也不那么模糊不清。

1、定义

官方定义：所有引用基类(父类)的地方必须能透明地使用其子类的对象。

简单理解就是：子类一般不该重写父类的方法，因为父类的方法一般都是对外公布的接口，是具有不可变性的，你不该将一些不该变化的东西给修改掉。

是不是感觉这个原则不太招人喜欢，因为我们在写代码的时候经常会去重写父类的方法来满足我们的需求。而且在模板方法模式，缺省适配器，装饰器模式等一些设计模式都会采用重写父类的方法。

怎么说呢，里氏代换原则的主要目的主要是防止继承所带来的弊端。

继承的弊端：

继承作为面向对象三大特性之一，在给程序设计带来巨大便利的同时，也带来了弊端。

继承会增加了对象间的耦合性，如果一个类被其他的类所继承，则当这个类需要修改时，必须考虑到所有的子类，并且父类修改后，所有涉及到子类的功能都有可能会产生故障。

三、接口隔离原则

1、定义

当一个接口太大时，我们需要将它分割成一些更细小的接口，使用该接口的客户端仅需知道与之相关的方法即可。

为什么要这么做呢?

其实很好理解，因为你实现一个接口就是实现它所有的方法，但其实你并不需要它的所有方法，那就会产生：一个类实现了一个接口，里面很多方法都是空着的，只有个别几个方法实现了。

这样做不仅会强制实现的人不得不实现本来不该实现的方法，严重的是会给使用者造成假象，即这个实现类拥有接口中所有的行为，结果调用方法时却没收获到想要的结果。

通常在软件开发中设计模式都有哪些原则呢？

你好，很高兴能回答你的问题。

我们在软件开发中设计模式常用的的六大原则有下面几个：

1、开闭原则

开闭原则的意思是：对扩展开放，对修改关闭。在程序需要进行拓展的时候，不能去修改原有的代码，实现一个热插拔的效果。简言之，是为了使程序的扩展性好，易于维护和升级。想要达到这样的效果，我们需要使用接口和抽象类，后面的具体设计中我们会提到这点。

2、里氏代换原则

里氏代换原则是面向对象设计的基本原则之一。 里氏代换原则中说，任何基类可以出现的地方，子类一定可以出现。LSP 是继承复用的基石，只有当派生类可以替换掉基类，且软件单位的功能不受到影响时，基类才能真正被复用，而派生类也能够在基类的基础上增加新的行为。里氏代换原则是对开闭原则的补充。实现开闭原则的关键步骤就是抽象化，而基类与子类的继承关系就是抽象化的具体实现，所以里氏代换原则是对实现抽象化的具体步骤的规范。

3、依赖倒转原则

这个原则是开闭原则的基础，具体内容：针对接口编程，依赖于抽象而不依赖于具体。

4、接口隔离原则

这个原则的意思是：使用多个隔离的接口，比使用单个接口要好。它还有另外一个意思是：降低类之间的耦合度。由此可见，其实设计模式就是从大型软件架构出发、便于升级和维护的软件设计思想，它强调降低依赖，降低耦合。

5、迪米特法则，又称最少指导原则

最少指导原则是指：一个实体应当尽量少地与其他实体之间发生相互作用，使得系统功能模块相对独立。

6、合成复用原则

合成复用原则是指：尽量使用合成/聚合的方式，而不是使用继承。

软件设计原则有哪些

1.六大原则-单一职责原则
原则思想：一个方法只负责一件事情。
描述：单一职责原则很简单，一个方法 一个类只负责一个职责，各个职责的程序改动，不影响其它程序。 这是常识，几乎所有程序员都会遵循这个原则。
优点：降低类和类的耦合，提高可读性，增加可维护性和可拓展性，降低可变性的风险。
2.六大原则-里氏替换原则
原则思想：使用的基类可以在任何地方使用继承的子类，完美的替换基类。
描述：子类可以扩展父类的功能，但不能改变父类原有的功能。子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法，子类中可以增加自己特有的方法。
优点：增加程序的健壮性，即使增加了子类，原有的子类还可以继续运行，互不影响。
3.六大原则-依赖倒置原则
原则思想：高层次的模块不应该依赖于低层次的模块，他们都应该依赖于抽象，抽象不应该依赖于具体实现，具体实现应该依赖于抽象。
描述：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假如修改类A，会给程序带来不必要的风险。
优点：可以减少需求变化带来的工作量，做并行开发更加友好。
4.六大原则-接口隔离原则
原则思想：类和类之间应该建立在最小接口的上。
描述：类A通过接口依赖B，类C通过接口依赖D，如果接口类A和类B不是最小的接口，则依赖的类B和类D必须要实现他们不需要的方法。
优点：提高程序的灵活度，提高内聚，减少对外交互，使得最小的接口做最多的事情。
5.六大原则-迪米特法则
原则思想：一个对象应当对其他对象有尽可能少地了解，简称类间解耦
描述：一个类尽量减少自己对其他对象的依赖，原则是低耦合，高内聚，只有使各个模块之间的耦合尽量的低，才能提高代码的复用率。
优点：低耦合，高内聚。
6.六大原则-开放封闭原则
原则思想：尽量通过扩展软件实体来解决需求变化，而不是通过修改已有的代码来完成变化
描述：一个软件产品在生命周期内，都会发生变化，既然变化是一个既定的事实，我们就应该在设计的时候尽量适应这些变化，以提高项目的稳定性和灵活性。
优点：单一原则告诉我们，每个类都有自己负责的职责，里氏替换原则不能破坏继承关系的体系。

完成良好的软件设计应遵循哪些原则

具体来说软件实现接口原则，真是几篇纸也讲不完软件实现接口原则，但从我软件实现接口原则的经验来说。当然是我的个人认为最为重要的地方。
一、大量的注释（当然代码极为简单已经表明意思的除外）
二、要求有良好的客户体验。
下面是我从网络摘抄软件实现接口原则：（希望对你能有所帮助）
设计模式遵循的一般原则：
1.开-闭原则(Open-Closed Principle, OCP):一个软件实体应当对扩展开发,对修改关闭.说的是,再设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展.换言之,应当可以在不必修改源代码的情况下改变这个模块的行为，在保持系统一定稳定性的基础上，对系统进行扩展。这是面向对象设计（OOD）的基石，也是最重要的原则。
2.里氏代换原则(Liskov Substitution Principle,常缩写为.LSP)
(1).由Barbar Liskov(芭芭拉.里氏)提出，是继承复用的基石。
(2).严格表达:如果每一个类型为T1的对象o1,都有类型为T2的对象o2,使得以T1定义的所有程序P在所有的对象o1都代换称o2时,程序P的行为没有变化,那么类型T2是类型T1的子类型.
换言之,一个软件实体如果使用的是一个基类的话,那么一定适用于其子类,而且它根本不能察觉出基类对象和子类对象的区别.只有衍生类可以替换基类，软件单位的功能才能不受影响，基类才能真正被复用，而衍生类也能够在基类的基础上增加新功能。
(3).反过来的代换不成立
(4).<墨子.小取中说:"白马,马也; 乘白马,乘马也.骊马(黑马),马也;乘骊马,乘马也."
(5).该类西方著名的例程为:正方形是否是长方形的子类(答案是"否")。类似的还有椭圆和圆的关系。
(6).应当尽量从抽象类继承,而不从具体类继承,一般而言,如果有两个具体类A,B有继承关系,那么一个最简单的修改方案是建立一个抽象类C,然后让类A和B成为抽象类C的子类.即如果有一个由继承关系形成的登记结构的话,那么在等级结构的树形图上面所有的树叶节点都应当是具体类;而所有的树枝节点都应当是抽象类或者接口.
(7)."基于契约设计(Design By Constract),简称DBC"这项技术对LISKOV代换原则提供软件实现接口原则了支持.该项技术Bertrand Meyer伯特兰做过详细的介绍:
使用DBC,类的编写者显式地规定针对该类的契约.客户代码的编写者可以通过该契约获悉可以依赖的行为方式.契约是通过每个方法声明的前置条件(preconditions)和后置条件(postconditions)来指定的.要使一个方法得以执行,前置条件必须为真.执行完毕后,该方法要保证后置条件为真.就是说,在重新声明派生类中的例程(routine)时,只能使用相等或者更弱的前置条件来替换原始的前置条件,只能使用相等或者更强的后置条件来替换原始的后置条件.
3.依赖倒置原则(Dependence Inversion Principle),要求客户端依赖于抽象耦合.
(1)表述:抽象不应当依赖于细节,细节应当依赖于抽象.(Program to an interface, not an implementaction)
(2)表述二:针对接口编程的意思是说,应当使用接口和抽象类进行变量的类型声明,参量的类型声明,方法的返还类型声明,以及数据类型的转换等.不要针对实现编程的意思就是说,不应当使用具体类进行变量的类型声明,参量类型声明,方法的返还类型声明,以及数据类型的转换等.
要保证做到这一点,一个具体的类应等只实现接口和抽象类中声明过的方法,而不应当给出多余的方法.
只要一个被引用的对象存在抽象类型,就应当在任何引用此对象的地方使用抽象类型,包括参量的类型声明,方法返还类型的声明,属性变量的类型声明等.
(3)接口与抽象的区别就在于抽象类可以提供某些方法的部分实现,而接口则不可以,这也大概是抽象类唯一的优点.如果向一个抽象类加入一个新的具体方法,那么所有的子类型一下子就都得到得到了这个新的具体方法,而接口做不到这一点.如果向一个接口加入了一个新的方法的话,所有实现这个接口的类就全部不能通过编译了,因为它们都没有实现这个新声明的方法.这显然是接口的一个缺点.
(4)一个抽象类的实现只能由这个抽象类的子类给出,也就是说,这个实现处在抽象类所定义出的继承的登记结构中,而由于一般语言都限制一个类只能从最多一个超类继承,因此将抽象作为类型定义工具的效能大打折扣.
反过来,看接口,就会发现任何一个实现了一个接口所规定的方法的类都可以具有这个接口的类型,而一个类可以实现任意多个接口.
(5)从代码重构的角度上讲,将一个单独的具体类重构成一个接口的实现是很容易的,只需要声明一个接口,并将重要的方法添加到接口声明中,然后在具体类定义语句中加上保留字以继承于该接口就行了.
而作为一个已有的具体类添加一个抽象类作为抽象类型不那么容易,因为这个具体类有可能已经有一个超类.这样一来,这个新定义的抽象类只好继续向上移动,变成这个超类的超类,如此循环,最后这个新的抽象类必定处于整个类型等级结构的最上端,从而使登记结构中的所有成员都会受到影响.
(6)接口是定义混合类型的理想工具,所为混合类型,就是在一个类的主类型之外的次要类型.一个混合类型表明一个类不仅仅具有某个主类型的行为,而且具有其他的次要行为.
(7)联合使用接口和抽象类:
由于抽象类具有提供缺省实现的优点,而接口具有其他所有优点,所以联合使用两者就是一个很好的选择.
首先,声明类型的工作仍然接口承担的,但是同时给出的还有一个抽象类,为这个接口给出一个缺省实现.其他同属于这个抽象类型的具体类可以选择实现这个接口,也可以选择继承自这个抽象类.如果一个具体类直接实现这个接口的话,它就必须自行实现所有的接口;相反,如果它继承自抽象类的话,它可以省去一些不必要的的方法,因为它可以从抽象类中自动得到这些方法的缺省实现;如果需要向接口加入一个新的方法的话,那么只要同时向这个抽象类加入这个方法的一个具体实现就可以了,因为所有继承自这个抽象类的子类都会从这个抽象类得到这个具体方法.这其实就是缺省适配器模式(Defaule Adapter).
(8)什么是高层策略呢?它是应用背后的抽象,是那些不随具体细节的改变而改变的真理. 它是系统内部的系统____隐喻.
4.接口隔离原则(Interface Segregation Principle, ISP)
（1）一个类对另外一个类的依赖是建立在最小的接口上。
（2）使用多个专门的接口比使用单一的总接口要好.根据客户需要的不同,而为不同的客户端提供不同的服务是一种应当得到鼓励的做法.就像"看人下菜碟"一样,要看客人是谁,再提供不同档次的饭菜.
（3）胖接口会导致他们的客户程序之间产生不正常的并且有害的耦合关系.当一个客户程序要求该胖接口进行一个改动时,会影响到所有其他的客户程序.因此客户程序应该仅仅依赖他们实际需要调用的方法.

5.合成/聚合复用原则(Composite/Aggregate Reuse Principle,CARP)
在一个新的对象里面使用一些已有的对象,使之成为新对象的一部分;新的对象通过这些向对象的委派达到复用已有功能的目的.这个设计原则有另一个简短的表述:要尽量使用合成/聚合,尽量不要使用继承.
6.迪米特法则(Law of Demeter LoD)又叫做最少知识原则(Least Knowledge Principle,LKP),就是说,一个对象应当对其他对象有尽可能少的了了解.
迪米特法则最初是用来作为面向对象的系统设计风格的一种法则,与1987年秋天由Ian Holland在美国东北大学为一个叫做迪米特(Demeter)的项目设计提出的,因此叫做迪米特法则[LIEB89][LIEB86].这条法则实际上是很多著名系统,比如火星登陆软件系统,木星的欧罗巴卫星轨道飞船的软件系统的指导设计原则.
没有任何一个其他的OO设计原则象迪米特法则这样有如此之多的表述方式,如下几种:
(1)只与你直接的朋友们通信(Only talk to your immediate friends)
(2)不要跟"陌生人"说话(Don't talk to strangers)
(3)每一个软件单位对其他的单位都只有最少的知识,而且局限于那些本单位密切相关的软件单位.
就是说,如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用,如果其中的一个类需要调用另一个类的某一个方法的话,可以通过第三者转发这个调用。
7.单一职责原则(Simple responsibility pinciple SRP)
就一个类而言,应该仅有一个引起它变化的原因,如果你能想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责.应该把多于的指责分离出去,分别再创建一些类来完成每一个职责. 关于软件实现接口原则和软件实现接口原则有哪些的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 软件实现接口原则的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于软件实现接口原则有哪些、软件实现接口原则的信息别忘了在本站进行查找喔。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。