封装抽象才是编程的精髓？

[TeacherYoung]

“封装”名列oo的三大特性之首，没有封装，就不会有“面向对象”的说法，而后面的继承和多态，都是建立在封装的基础之上。

封装实体很简单，基本上有什么都已经是确定的了，比如需要采集的数据，把数据归归类那需要的对象和表结构自然就会出来，还有代码，实现这样的需求就需要这么多代码，把这些代码归归类，让一堆代码只完成一个事情，这就是函数的封装。


而封装抽象感觉好难，抽象类，是如此的抽象，以至于不知道如何下手。

我对抽象类和接口的理解，自认为已经很深刻了，但是建立在没有多少代码经验的基础上，接口在抽象工厂里还实战过，抽象类就完全没有实战经验。

抽象类，还是类吗？我以前觉得抽象类还是类啊，只不过不是实实在在的，比如生物，我觉得生物就是个抽象类，它是一个东西，但很抽象。为什么很抽象呢？也许是因为能描述它的属性太少了吧，你不能描述它是什么颜色，也不能说它有几条腿，这些都是不确定的，唯一确定的是：它是一个活的东西。因为属性太少，所以很抽象，是一个抽象类。

而再往下分：动物，也是一个抽象类。
再分：哺乳动物，还是一个抽象类。
再分：人，还是一个抽象类吗？

到人的时候，已经有很多属性可以确定了，比如四条腿啦，一个鼻子两只眼睛等等。但依然有很多不确定的，比如肤色……

那抽象类和非抽象类，就是属性的多少来决定的吗？

在看《大话设计模式》的时候，里面有一个抽象类竟然是“结算”，结算是一个动作啊，我一直会把它弄成一个接口，从来没有想过会建这样的抽象类的……

封装实体很容易，而封装抽象……感觉好难啊

也许这就是架构设计的精髓所在吧，而我显然只是编程入门了还没有入架构的门。

封装实体容易就容易在：有一方式确定的
而封装抽象难就难在：两边都不确定，你如何封装抽象，决定了你怎么写代码去用；而你想如何去写代码，也反过来影响你对抽象的封装和设计……

唉，这个世界就是阴阳互生的呀，有型的东西很好掌握，而无形的能量才是本源所在，可难以捉摸呀。

我的太极图何时才能补上那另一半，良性转起来呢？


各位大神求对抽象封装、抽象类的解读，最好有项目实例。

[以专业开发人员为伍]

你把抽象类、接口，都升级到设计中去理解了。 实际上，在设计中，根本不需要怎么去考虑（某种编程语言的）接口和抽象类。你只需要考虑类类型，包括接口也是体现了类型系统。它们只是在编程实现上有所区别，没有必要提前到设计中去考虑。 于是，假设一个类型没有什么本质特性，那么就不需要定义这个类型（顶多用一个字符串作为其关联的其它对象的属性去定义）。你不需要按照“抽象”这个字眼儿去理解抽象，而应该从实务角度去理解。 我们在设计中自然是越少用类型越好，编程中自然是越少设计类型、接口等等越好，自然是越少写代码越好。之所以要定义类型、接口、“抽象类”，纯粹是工程扩展的需要。也就是说，并不是我们要走套路，是套路确实起了超乎相像地好用，在经济上特别有价值，那时候我们才接受了新的概念。然后我们的OOPL 代码要跟 OOAD 设计保持一致，这时候在代码中才会用到相关概念。最后仅仅在代码实现时，我们才考虑“抽象类可以进一步抽离扩展实现中的一些代码、接口可以在实在是不知道内部实现时做一些约束”等等技术问题。但是在设计上，都是类型，不需要区分“实际的类型、抽像类、接口”，在设计上也应该支持多重继承而不用管.net和java不支持多重继承的实现。 类型本来就是越少用越好、代码本来就是越少写越好。尽管如此，我们还是可以做出清晰且容易扩展的设计。如果死读书本而设计类、接口、抽象等等，则容易过度滥用类型和接口，是劳民伤财的，甚至会带来诡异的设计。

[以专业开发人员为伍]

我们应该善用抽象、一般化、分层扩展等等机制。我们要回答“没有它又能怎样？”的问题，你能给出比较好的回答，你就使用抽象。只有灭掉一些多余的浮躁，先能够清静地看待概念，才能萌生创意。在编程中，假设你不需要考虑“生物、动物、哺乳动物”，你就不应该考虑他们，你可以直接考虑“店主、领班、顾客”等等，而根本不用考虑“店主算不算是人、顾客算不算是人”的问题。不滥用类型系统，不做不必要的事情，根据实际项目需要来设计，才能善用类型设计手段。

[hiose89]

越抽象的东西，越是要架构师来弄。因为如果你达不到那个高度，你没有他的那种上帝视角，你是看不清整个框架的需求的。 就好像接口 当你定下后，就不会轻易的去变动，因为那会让所有的代码都被推翻。

[threenewbee]

可以这么说，封装防止代码外部更改代码的实现和状态，从而有利于创建高内聚的代码。