本篇文章给大家谈谈java继承破坏封装，以及java异常统一处理 封装对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。
本文目录一览：
1、java中子类虽然能继承父类的成员，请简述子类对父类哪些能访问？哪些不能访问 急急急！！！！！！！！！！2、java 中的继承的 优点和缺点 主要是缺点3、JAVA中，继承为什么打破封装4、java中继承的好处是什么,在组合和继承中该如何取舍?5、JAVA23种设计模式6、继承是否真的会破坏类的封装性？
java中子类虽然能继承父类的成员，请简述子类对父类哪些能访问？哪些不能访问 急急急！！！！！！！！！！
子类extends父类时，子类可以从父类继承得到属性和方法，在访问权限允许的情况下，子类可以直接访问父类的属性和方法，也即是说子类可以直接复用父类的属性和方法。
但同时，继承破坏了父类的封装性，可以通过重写来恶意改变父类方法实现。
所以，尽量在创建父类的时候把所有属性都设置成private访问类型，必须被外类调用又不想被子类重写的方法加上final修饰符。在父类的构造方法中不要有子类重写的方法。
java 中的继承的 优点和缺点 主要是缺点
java 中的继承的 优点和缺点如下：
优点：1.可以使用父类的所有非私有方法；而且单继承可由接口来弥补。
2.可以继承父类中定义的成员方法以及成员变量，使得子类可以减少代码的书写。还可以重写父类的方法以增加子类的功能。
缺点：1.耦合性太大
2.就是破坏了类的封装性，其实继承一般多用于抽象方法的继承和接口的实现
JAVA中，继承为什么打破封装
并没有打破封装啊~ 因为继承的只是父类的public 和protectde成员变量和方法啊 并没有继承private成员变量和方法。 class A{ private int a = 1; public int b =2; // private int getA(){return a;} public int geta(){return a;} public int getB(){return b;} }class B extends A{ public int getnumber ( a = super.getA(); //错误的啊~不能继承父类的私有成员 a = super.geta(); b = super.getB(); } } public class test{ public static void main(String [] agur){ B frame =new A(); //多态性 System.out.println(frame.getnumber); } }
java中继承的好处是什么,在组合和继承中该如何取舍?
1，继承提高了代码的重复利用性；
2，继承是面向对象的，一类事物可以独立存在，解藕了类与类之间的斗联系。
3，继承更利于程序的设计。
5，在组合中，一定要把同一类事物放在一起，和现实生活中一样，每一类事物都是有自己的共性和自己的特性，按毛主席的矛盾论说是：矛盾的普遍性与特殊性，普遍性就是继承来的。
6，在写代码之前，分析和设计是关键的一步，这一步解决的就是哪些类是同类的，哪些东西是公共的。
JAVA23种设计模式
一、大约分为三类：
1、创建型模式（5种）：工厂方法模式，抽象工厂模式，单例模式，建造者模式，原型模式。
2、结构型模式（7种）：适配器模式，装饰器模式，代理模式，外观模式，桥接模式，组合模式，享元模式。
3、行为型模式（11种）：策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。
二、设计模式遵循的原则有6个：
1、开闭原则（OpenClosePrinciple）
对扩展开放，对修改关闭。
2、里氏代换原则（LiskovSubstitutionPrinciple）
只有当衍生类可以替换掉基类，软件单位的功能不受到影响时，基类才能真正被复用，而衍生类也能够在基类的基础上增加新的行为。
3、依赖倒转原则（DependenceInversionPrinciple）
这个是开闭原则的基础，对接口编程，依赖于抽象而不依赖于具体。
4、接口隔离原则（InterfaceSegregationPrinciple）
使用多个隔离的借口来降低耦合度。
5、迪米特法则（最少知道原则）（DemeterPrinciple）
一个实体应当尽量少的与其他实体之间发生相互作用，使得系统功能模块相对独立。
6、合成复用原则（CompositeReusePrinciple）
原则是尽量使用合成/聚合的方式，而不是使用继承。继承实际上破坏了类的封装性，超类的方法可能会被子类修改。
继承是否真的会破坏类的封装性？
当时以为这是正确答案，也没怎么想就带过去了。但是今天，我又碰到了同样的问题（真是冤家路窄:P），而我已经真正接触过了面向对象设计与编程，设计模式等东西。那么我现在不禁产生了这个疑问，类的继承真的会破坏类的封装性吗？
要解答这个问题，首先要明确的两个概念就是类的继承和封装。按照Java中对于封装（Encapsulation）的概念，其是指：隐藏属性,方法或实现细节的过程，仅对外公开接口。继承（Inheritance）的概念是指：在父类和子类之间存在着继承和扩展关系；子类继承父类的属性和方法的同时，子类还可以扩展出新的属性和方法，并且还可以覆盖父类中方法的实现方式。其实无论是Java还是其他的面向对象的编程语言，这两个概念以及由此衍生出的其他的诸如方法的重载、重写等概念几乎大同小异。不过由这两个概念我们可以看出，子类只不过是在父类的基础上进行的扩充。用数学的语言来说，是对关系集合的非最小化闭包运算（扯远了）。如此说来，父类中封装好的对外界隐藏的东西，子类继承过来后当然也应该是对外界隐藏。而子类中扩充的东西是否对外界隐藏，完全由子类说了算。就算是C++中的public继承方式，其子类继承了父类后，父类中的私有方法还是不能被外界直接调用。这样看的话，继承怎么就破坏了类的封装性了呢？难不成子类继承了父类的东西后，父类中的私有属性和方法在子类中就全成了公开的了，可以被所有的人随便调用了？我想这既不是我们这些开发人员想看到的，同样也不是那些编程语言的设计者们所希望的。
那么下面再来看看所谓的“继承破坏类的封装性”的说法：父类常常会定义一部分子类的表现特征，使得父类和子类之间的实现代码产生相互依赖。我就挺奇怪的，儿子的事情为什么要让老子来管，这不是多此一举吗？谁会这么傻呢，让父类和子类之间产生这样不必要的耦合？还有的同志说，继承会失去灵活性。对于这一点，我就更不明白了，为什么会这么说呢？难不成是因为“明确的使用具体类名将你固定到特定的实现，给底层的改变增加了不必要的困难”？如果是因为类之间有强耦合关系的问题，那把基类写成抽象类不可以吗？就像我们都是人，所以“人”就是一个抽象类。人要吃东西，所以有一个eat方法。而我们大家吃东西的方式都不一样，于是我们都可以去重写这个eat方法，自己喜欢怎么吃就怎么吃（比如站着吃、坐着吃、躺着吃等）。这怎么就失去了灵活性了呢？
其实说到底，继承在适当的时候使用，会极大地加快开发速度和提高开发的效率。其他任何的东西也是如此（比如设计模式中的flyweight模式）。但是，继承破坏类的封装性的说法，我绝对不敢认同。
java继承破坏封装的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于java异常统一处理 封装、java继承破坏封装的信息别忘了在本站进行查找喔。
微信扫一扫 
支付宝扫一扫 
