程序员小白如何理解面向对象?

程序员小白如何理解面向对象?,第1张

核心是封装状态和相应的过程。通常面向对象是通过改变内部状态实现最终目的。调用对象过程的衡厅主要目的是产生改变其内部状态这个副作用(side effect)。这样封装的初衷是避免多个主体访问、修改同一状态造成混乱。在不少场合这样的封装确实也达到了目的,所以面培咐向对象的方式才这么普配拦纯及。

类就是具备某些共同特绝碧征的实体的集合,它是一种抽象的数据类型,它是对所具有相同特征实体的抽象。在面向对象的程序设计语言中,类是对一类“事物”的属性与行为的抽象。举一个例子说明下类,比如Person(人)就是一个类,那么具体的某个人“张三”就是“人类”这个类的对象,哪轮而“姓名、身高、体重”等信息就是对象的属性,人的动作比如“吃饭、穿衣”等就是对象的方法。总之类就是有相同特征的事物的集合,而对象就是类的一个具体实例。同时类有多态和继承,例如“人类”可以分为“男人、女人”,“老人、小孩”那么“男人、女李宏信人”就是“人类”的子类等等。

Java语言中对类Person的定义往往如下:

public class Person {

private String name//属性:姓名

private int height//属性:身高

private int weight//属性:体重

public Person() {}

public Person(String name, int height, int weight) {

this.name = name

this.height = height

this.weight = weight

}

//... some methods...

public void doSth() { //行为:

//... do something

}}

Java中的类

类可以看成是创建Java对象的模板。

通过下面一个简单的类来理解下Java中类的定义:

public class Dog{

 String breed int age String color void barking(){

 }

 void hungry(){

 }

 void sleeping(){

 }}

一个类可以包含以下类型变量:

局部变量:在方法、构造方法或者语句块中定义的变量被称为局部变量。变量声明和初始化都是在方法中,方法结束后,变量就会自动销毁。

成员变量:成员变量是定义在类中,方法体之外的变量。这种变量在创建对象的时候实例化。成员变量可以被类中方法、构造方法和特定类的语句块访问。

类变量:类变量也声明在类中,方法体之外,但必须声明为static类型。

一个类可以拥有多个方法,在上面的例子中:barking()、hungry()和sleeping()都是Dog类的方法。

面向对象设计原则是OOPS编程的核心,学习面向对象编程像“抽象”、“封装”、“多态”、“继承”等基础知识是重要的,但同时为了创建简洁、模块化的设计,了解这些设计原则也同等重要。

(设计原则)底线是永远追求高内聚、低耦合的编码或设计。Apache和Sun的开源代码是学习和OOPS设计原则的良好范例。它们向我们展示了,设计原则在编程中是如何使用的。JDK使用了一些设计原则:BorderFactory类中的工厂模式、Runtime类中的单例模式、.io类中的装饰器模式。顺便说一句,如果您真的对编码原则感兴趣,请阅读JoshuaBloch的Effective,他编写过API。我个人最喜欢的关于面向对象设计模式的是KathySierra的HeadFirstDesignPattern(深入浅出设计模式),以及其它的关于深入浅出面向对象分析和设计。这些书对编写更好的代码有很大帮助,充分利用各种面向对象和SOLID的设计模式。

虽然学习设计模式(原则)最好的方法是正滑悔现实中的例子和理解违反设计原则带来的不便,本文的宗旨是向那些没有接触过或正处于学习阶段的程序员介绍面向对象设计原则。

DRY_Don’trepeatyourself

我们第一个面向对象设计原则是:DRY,从名称可以看出DRY(don’trepeatyourself)意思是不写重复代码,而是抽象成可复用的代码块。如果您有两处以上相同的代码块,请考虑把它们抽象成一个单独的方法;或者您多次使用了硬编码的值,请把它们设置成公共常量。这种面向对象设计原则的优点是易于维护。让闷重要的是不要滥用此原则,重复不是针对代码而是针对功能来说。它的意思是,如果您使用通用代码来验证OrderID和SSN,这并不意味着它们是相同的或者他们今后将保持不变。通过把通用代码用于实现两种不同的功能,或者您把这两种不同的功能密切地联系在一起;当您的OrderID格式改变时,您的SSN验证代码将会中断。所以要当心这种耦合,而且不要把彼此之间没有任何关系却类似的代码组合在一起。

封装经常修改的代码

EncapsulateWhatChanges

在软件领域永远不变的是“变化”,所以把您认为或怀疑将来要被修改的代码封装起来。这种面向对象设计模式的优点是:易于测试和维护恰当封装的代码。如果您在用编程,那么请遵守以下原则:变量和方法的访问权限默认设置为私有,并且逐步放开它们的访问权限,例如从“private”到“protected”、“notpublic”。中的一些设计模式使用了封装,工厂设计模式就是一个例子,它封装了创建对象的代码而且提供了以下灵活性:后续生成新对象不影响现有的代码。

打开/关闭设计原则

OpenClosedDesignPrinciple

类、方法/函数应当是对扩展(新功能)开放,对修改闭合。这是另外一个优雅的SOLID设计原则,以防止有人修改通过测试的代码。理想情况下假如您添加了举正新功能,那么您的代码要经过测试,这就是打开/关闭设计原则的目标。顺便说一句,SOLID中的字母“O”指的是打开/关闭设计原则。

单一职责原则

SingleResponsibilityPrinciple(SRP)

单一职责原则是另外一个SOLID设计原则,SOLID中的字母“S”指的就是它。按照SRP,一个类修改的原因应当有且只有一个,或者一个类应当总是实现单一功能。如果您在中的一个类实现了多个功能,那么这些功能之间便产生了耦合关系;如果您修改其中的一个功能,您有可能就打破了这种耦合关系,那么就要进行另一轮测试以避免产生新的问题。

依赖注入/反转原则

DependencyInjectionorInversionprinciple

不要问框架的依赖注入功能将会给你带来什么益处,依赖注入功能在spring框架里已经很好的得到了实现,这一设计原则的优雅之处在于:DI框架注入的任何一个类都易于用模拟对象进行测试,并且更易于维护,因为创建对象的代码在框架里是集中的而且和客户端代码是隔离的。有多种方法可以实现依赖注入,例如使用字节码工具,其中一些AOP(面向切面编程)框架如切入点表达式或者spring里使用的代理。想对这种SOLID设计原则了解更多,请看IOC和DI设计模式中的例子。SOLID中的字母“D”指的就是这种设计原则。

优先使用组合而非继承

ForCompositionoverInheritance

如果可以的话,要优先使用组合而非继承。你们中的一些人可能为此争论,但我发现组合比继承更有灵活性。组合允许在运行时通过设置属性修改一个类的行为,通过使用多态即以接口的形式实现类之间的组合关系,并且为修改组合关系提供了灵活性。甚至Effective也建议优先使用组合而非继承。

里氏替换原则

LiskovSubstitutionPrincipleLSP

根据里氏替换原则,父类出现的地方可以用子类来替换,例如父类的方法或函数被子类对象替换应该没有任何问题。LSP和单一职责原则、接口隔离原则密切相关。如果一个父类的功能比其子类还要多,那么它可能不支持这一功能,而且也违反了LSP设计原则。为了遵循LSPSOLID设计原则,派生类或子类(相对父类比较)必须增强功能,而非减少。SOLID中的字母“L”指的就是LSP设计原则。

接口隔离原则

接口隔离原则指,如果不需要一个接口的功能,那么就不要实现此接口。这大多在以下情况发生:一个接口包含多种功能,而实现类只需要其中一种功能。接口设计是一种棘手的工作,因为一旦发布了接口,您就不能修改它否则会影响实现该接口的类。在中这种设计原则的另一个好处是:接口有一个特点,任何类使用它之前都要实现该接口所有的方法,所以使用功能单一的接口意味着实现更少的方法。

编程以接口(而非实现对象)为中心

编程总是以接口(而非实现对象)为中心,这会使代码的结构灵活,而且任何一个新的接口实现对象都能兼容现有代码结构。所以在中,变量、方法返回值、方法参数的数据类型请使用接口。这是许多程序员的建议,Effective以及headfirstdesignpattern等书也这样建议。

代理原则

不要期望一个类完成所有的功能,电脑培训http://www.kmbdqn.com/认为可以适当地把一些功能交给代理类实现。代理原则的典范是:中的equals()和hashCode()方法。为了比较两个对象的内容是否相同,我们让用于比较的类本身完成对比工作而非它们的调用方。这种设计原则的好处是:没有重复编码而且很容易修改类的行为。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/12345135.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-24
下一篇 2023-05-24

发表评论

登录后才能评论

评论列表(0条)

保存