面向对象的核心

与题目名称一样，何为面向对象，只要是搞过java或者了解java的朋友都应该明白，在这里就不多说了哈哈(^,.^)，但是面向对象的核心又是什么呢？或者说它的精髓所在又是什么呢？貌似这个问题就值的朋友们深究了。
在面向对象的世界里，一切皆为对象，已是大家公知的了，在这里不再强调，而基于面向对象本身的核心又是什么呢？这里讲的并不是基于java的核心技术或者周边一些经典的第3方插件或者经典框架。当然也只是一些个人见解，因为在下也是才疏学浅，有望指点呵呵（不废话了。。。GOGO ^,.^）
核心的重要性，完全取决于你对OO思想的理解程度（OO思想：我们谈的 想的 编的 做的 都是围绕一个个对象，即对象编程），而在我看来，编程的核心就是解决问题的能力，也是章显一位程序设计人员的能力，而OO的核心则是抽象，我想这个也不会有太大的争议，由于入行比较浅，最低也就接触过jdk1.4呵呵。何为抽象：就是抽取事物一些本质的东西，剔除次要的表面东西，但是千万别忘了后面那个象字，那就是抽取之后还得让事物象原来的事物，我们很多人在软件设计中抽取类的时候往往就是抽而不象，变了形，最终不能满足用户的需求。而我们的抽象往往只是抽而不象，就是缺少或者忽视了后一个环节的原因，而且我们的抽象也往往是孤立的，没有发散性地从多个角度进行抽象，所以无论是’抽’还是’象’，都缺一不可，一般大师们都是运用逆向思维方法，找出系统不变的，相对较为固定的东西，沉淀出来即为框架，而且是灵活的框架，只不过在这里不叫抽象了，而称之为框架。有很多朋友，我相信不光是我，大家都目睹过java的变化，从最开始的面向抽象编程，经历面向接口编程，到现在的面向切面编程，无疑都是一步一步的再进化，在思想层次上的飞跃，到现在为止，AOP是抽象到及至的一种编程思路（当然这篇文章也不是力捧AOP啦哈哈 ^,.^），未知的世界不知道还会有哪位大师又推出一种更高端的思路，当然我是想不出来了哈哈，但是他们的本质都没有改变，抽象，在程序中的运用又称之为分散关注，正因为AOP连这一点的分散关注的问题都给解决了，所以现在AOP得到大家的极力认可，因为代码清洁了，思路清晰了等等，抽象--好好运用，大家会变的很强。
可能有人会说，编程核心就是分层+解藕+中间件，但是有没有想过为什么会作这么一系列的工作？是因为什么？难道一拿到需求文挡就要从分几层架构，如何解藕，如果通过接口加上中间件或者多个dao层多个service层来解决么？当然答案都在各自心中，但是我想阐述的只是我单方面的疑惑：可能这一切来自在我们这里不太流行的对象数据库吧（我这里不也不是力捧对象数据库哈哈^,.^） ，因为我们一直在用的都是关系型数据库．跟关系数据库匹配的貌似Hibernate的追捧人比较多（ibatis先不说哈），当然这里我也不敢对Hibernate指指点点，毕竟现在的我也在用Hibernate,虽然底层会按照我的意愿去作些改动，但总体它还是一个不错的ORM框架，不管是Criteria还是Query，终究没有脱离sql的阴影，仍然是sql的思维，而对于对象数据库不普及的原因呢　大致可以分为以下３种情况：
1. 从分析设计方法来讲,对象化的分析方法比数据化分析方法更自然方便,而且这两种方式存在不匹配,不能互相替代,所以,就存在0和1的取舍问题,很难调和在一起.对象数据库很难让人明白,到底是对象呢还是数据库呢?
　　2.使用对象化的中间件在性能扩展上比较廉价,可以防止单点风险和进行集群,这是分布式计算发展,而围绕数据库容易走上集中式中大型机,这是过去cobol/db2等形式,已经存在严重瓶颈.
　　3.关键我们需要重新看待对象和数据库关系,数据库只是对象存储的地方,一个技术介质,几乎和业务概念一点关系没有,精通业务流程的人以前必须了解数据库这些具体技术才能做出软件,而现在和将来就不需要了,他只要用对象表达他的分析概念就可以了.
正因为以上的３点，才造就了现在的关系型数据库的普及，就有如环境造就一个人，使惯了关系型数据库，那么无疑下一个选择有绝大部分还是关系型数据库。假想一下，当你拿到一份需求文档，你要设计的时候，你会从哪方面开始着手？概要设计—详细设计—库设计？大体上在详细设计的同时就已经会牵扯各个对象之间的关系是如何如何了，因为我们这些java同僚门都知道，对象与对象之间会有着某种特殊的关联---依赖,也就是说靠一个对象根本作不了所有的事情，所以会分很多很多的对象，各干各的事情，各自负责属于自己的版块，对象之间依赖是天生的，因此粒度这条路走下去，会遇到“依赖”这堵墙，这样必不可少的会在彼此之间（库中）产生牵连，简单的逻辑还好说，如果碰到非常复杂的逻辑，是不是要N个多对多关系表？如果是的话，那是不是如果发生了一点需求上的变动，就要更改原本设计好的或者已经写好的代码？当然需求不可能不变，除非贵公司的需求分析师非常的出色，否则这种系统重构是不可避免的，我相信系统的重构大家都经历过，烦啊。。刚写完的东西又要改来改去的。。无限的分层无限的解藕无限的中间件，貌似都要改一遍，如果某些接口已经是发布的接口，那修改起来无疑会给系统带来的巨大隐患以及造成公司的亏损，后果可想而知。所以这个依赖性的拿捏就相当的重要，或者我大胆的想一下是否可以无依赖性的库设计？当然有人可能会问，面向对象本来就是对现实事物的抽象，那就肯定会存在联系的，但是我想说的是，既然抽象是OO的核心思想，那我们就尽可能的利用抽象概念，不只是针对某某A或者B接口来作，直接是针对所有的Object或者Class来操作是不是会好一点呢，那样会不会对依赖有所改善呢？
而总体来说大致上面所说的都归功于面向对象的核心编程思想，其实最重要的’核心’还是解决问题的新思维，遇到一个问题，你是否能够多层次多方面的去考虑解决的问题，或者在多个问题之中考虑到最理想，对系统性能最好，最优越的一套解决方案？或者考虑到最后是否这套解决方案比较便于维护，或者说’可以’维护，当然一套最棒的解决方案不可能适用于所有的软件开发。所以无论发生的问题粒度有多大，希望都能从根本上解决总体的问题，不要忽略要盖个100层楼时，5层就开始偏差的那0.1厘米的差距。所以说不必因为了解了解藕就去盲目的作解藕，不要因为熟悉AOP或者熟知AOP就哪儿都用到AOP，和面向对象的核心----抽象一样，需要拿捏一个度的问题，每人心中有把尺。可能说了这么多也未必说的清楚，因为本来这些话题就是比较抽象的，非一言两语说的清的。可能有些不足的地方或者思维不成熟的地方，还请各位朋友们谅解，只希望共同探讨，只有探讨才能进步，希望我们可以推动中国的软件业发展．