java面试提问:什么是OOP?
OOP全称Object Oriented Programming,是指面向对象程序设计,是一种计算机编程架构。OOP 的一条基本原则是计算机程序是由单个能够起到子程序作用的单元或对象组合而成。
面向对象编程技术的关键性观念是它将数据及对数据的操作行为放在一起,作为一个相互依存、不可分割的整体——对象。对于相同类型的对象进行分类、抽象后,得出共同的特征而形成了类。面向对象编程就是定义这些类。
扩展资料:
OOP的优缺点:
1、OOP 的优点:使人们的编程与实际的世界更加接近,所有的对象被赋予属性和方法,结果编程就更加富有人性化。
2、OOP 的也有缺点,就 C++ 而言,由于面向更高的逻辑抽象层,使得 C++ 在实现的时候,不得不做出性能上面的牺牲,有时候甚至是致命的 。
参考资料:
面向对象第一阶段,理解面向对象术语体系。楼主显然正在这样的阶段里徘徊。
-------------------------------------------------------------------------------------------------------------------------------
当然这也无怪楼主,比如楼下的回答。有些是所谓存在即合理的论调都抛出来了,这是要以道理压人啊——这分明是说,我虽然也不知道,但存在即合理。当然还是从抽象类与普通类的区别上来说了,一个强制重写,一个不强制重写,假定我们不用IDE而是用记事本编程,那么提示编程人员的重写功能似乎说不过去了,如果说编译时提醒,那么如果编译器不是那么完美呢?显然,并没有说中要害。
——————————————————————————————————————————
在面向对象的第一阶段确实不好理解,但在第二阶段,模式设计时,也许会有不少人告诉你,尽量不要用继承,因为继承的耦合性非常大,那么这时候可能自觉不自觉地去理解这些东西了。至于面向切面编程告诉你,如果你继承于一个普通类,那么一定是继承树有问题,也不会是质量较高的代码了。所以面向切面编程要求被继承的父类必须是抽象类。
——————————————————————————————————————————
先从原理说起:怎么去抽象?
如果多个类实现相同的方法,那么该方法体与签名应提升到父类中去,继承的子类就具有相同的行为,这一点可以保证被继承的子类在父类方法修改时可以同时修改。
但是如果有一些类与大多数类实现的行为不同,那么应将该方法体与签名提升到父类中,同时允许部分子类重写,也就是写成虚方法。虚方法修改时会影响到大部分类的行为,但不会影响到对虚方法重写类的行为。
如果大多数类实现有相同的签名,但几乎每个方法都不相同,则应将方法签名提升到父类,做抽象方法以提子类重写——这里有一个前提条件,就是在父类被调用或父类其他方法中对子类延迟实现的方法有调用。如果没有父类层的代替调用,那么这些完全不同行为的方法为何还要提升到父类中去呢?这样多此一举?
这句话可能难以理解一点,举个例子吧,抽象父类可能是框架结构上的元素,调用方根据迪米特法则(知识最少原则)只了解抽象父类,而各子类的实现是模块另外一个程序员开发组实现的。根据里氏代换,调用父类其实可以实现具体子类的功能,但子类的具体实现却不是调用方关心的。还有就是父类在调用层次上直接调用了某个保护函数(protected),这个函数延迟到子类实现。
现在,我们看到了这些功能上使用上区别,但显然虚方法与抽象方法似乎有着相同的功能,其实是抽象的方式不太一样,虚方法是大多子类要实现的功能,而抽象方法是几乎所有子类均实现不同的功能。这一点上似乎两者区别性不是很大,尤其是没有较高的面向对象编程经验的时候,两者看起来似乎是通用的。但是有个特定行为,更能决定两者的区别,子类重写时可能会执行base.XXX();同名方法,这个如果抽象方法是不被支持的。这里可以看到虚方法可能是部分类行为的实现(大多数类行为相同),也可能是大多数类行为的部分实现。
所以从抽象方式上可以看出,抽象方法与虚方法来源于不同抽象方式,两者其实是没有可比性的,该用到哪一种看抽象的行为一般是不会用错的。
-------------------------------------------------------------------------------------------------------------------------
再从框架说起,从原理其实是一种自底向上的分析方式,而框架则是自顶向下分析。那么接口与抽象类不能是简单的结构了,而是一个接口协议,也就是说我们使用接口或抽象类向业务实现编程人员定义协议,而由编程人员去编程实现,那么,抽象方法表示必须由实现人员实现的行为,而虚方法则是可由实现人员选择性实现的行为(这也是编译会让抽象方法不能通过编译的原因)。两者也有明显的区别。
所以框架编程上来说,两者也不会弄混,而造成误用。
————————————————————————————————————————
单纯语言层面上来,虚方法实现一个空的方法体,然后使用文档要求实现人员必须实现,其实未尝不可,也就是说虚方法单从语言方面来说,完全可以用虚方法来代替抽象方法的。当然我这里只是说单纯的语言层面上。
但一个项目工程是由易理解性(你真的能确定用虚方法代替抽象方法的理解是正确的么),易维护性(你确认其他编程人员对象的这种理解能达到同步么)等多种方面来衡量的,如果真是有较强的管理,完备的文档等那么单从语言层面上去代替是可行的。
————————————————————————————————————————
所以,如果做为程序员真着眼于语言层面,那么其实理解很多东西都是错的,就象readonly与const的区别一样,两者其实只是换种方式的实现,但对于软件工程来说,可能是一大漏洞。
————————————————————————————————————————
最后要说的是,真正的软件编程,必须保证最简继承树,或者尽量少用继承。一般情况下,继承树只要两层,除非有足够的必要,但除叶层外其他的均必须为抽象类(虽然普通类也可以继承)。所以其实继承上的问题不多,因为没有足够的理由是不用的。能提出这样的问题,至少说话程序员的态度是正确的,敏而好学,善于思考,但软件业是一个复杂行业,有些东西只有触到更高的层次才会理解,有些问题可以放一放,日后其实应该知道该怎么做,只不过可能自己也说不清楚为什么这么做而已。
本文由用户上传,如有侵权请联系删除!转转请注明出处:https://nongye.s666.cn/js/5_6571048595.html