个人视角：抽象与实现
哲学或纯理论意义上的对象定义并不是方法字段加属性这种模式化的定义方法，对象这个概念，准确说应该是人类能够并识别提取出来概念标识。可以认为一个bit是一个对象，几个bit组成的一个字节也是一个字节也是一个对象。大凡只要能够认识并能提取出来辨认出它与其它事物有什么不同的特征的就可以称之为对象。
如果想要更加含糊一些的话，我们可以认为类也是对象，因为类是对象的结构描述，它自身这种描述集合是我们可以认识的，所以它也是一种对象。
通常意义上我们所说的类与对象有所区别，这是因为概念的范畴发生的变化，真正概念意义上的纯正类定义，在开发中，通常被我们称之为接口，因为它是真正的无数据实现定义的描述，这也是为什么接口在OO支持论者心目中是那么的重要。开发中的类，是一种提供了抽象概念与实现概念间的桥梁，它可以把抽象的定义与实现的方法都包括在里面，从成为一个对象的创建器。开发中的对象，通常是指的具体带有数据实现的对象。
清晰一些分别它们：可以认为，纯理论意义上，所有一切可认知的东西都可以称为对象。实际的开发意义上，将原始意义上的对象分为三大类，并重新命名：
1、可对其它对象进行定义与描述的对象，作为抽象工具，通常不带有数据，这以开发中的接口概念为代表
2、根据定义与描述实现的对象，作为实现个体，通常带有数据，这以开发中的对象概念为代表
3、提供定义与实现的对象，作为桥梁性手段，通常带有初始化数据及数据变化规则的描述，这以开发中的类为代表。
也就是说“一切皆对象”这种说法本身是没有错误的，但是如果意图用这种扩大的哲学化的概念来指导具体软件开发中的概念，就陷入了一种混乱。
分清了接口、类、对象后，下面皆沿用开发中的概念。
接口是一个很奇怪的东西，它只有一定义，而没有提供任何实现的方法，如果只是接口试图来摸拟世界运作而不依赖于任何实现的话，那不亚于你在纸上画画行星就能改变行星轨道一样有难度。所以必须采用类的概念，严格意义上来说，类并不是分类的定义与组合，它是接口与对象间如何过渡的规则描述。
接口在设计中，可以用来勾勒结构关系，类在设计中，是过渡抽象到实现的必要手段，对象则是在设计中具体数据载体及该对象对数据转化的操作形式。
Brooks认为“数据的表现形式是编程的根本. ”，这是因为，数据是开发中实现各种思想与方法最小单位，它就像我们这个世界中的基本粒子一样，我们同样可以认为，这个世界的根本就是基本粒子的运动。
很多时候，开发思想与实际开发中的实现遇到的问题，并不违反思想本身的要求。认为抽象出来的事物与现实事物间很多时候不符合，那不是抽象的问题，而是实现的问题。
从抽象角度来说，你看到了一架喷气式飞机，从个人化的世界观来说，你抽象它是会飞的，有翅膀，那么打算来用鸟定义它，实际上鸟并不会喷气，尽管它会拉屎，但还是有极大的不同。问题出在哪里呢？
问题出在采用了一个具体化的“鸟”这个有数据承载的对象来定义它，也就是一个并不纯净的定义，这不是抽象描述，这是模拟描述，这是根据不完全的信息进行的推测并人为强行认为它是一只鸟，这不是鸟这个定义的错，因为鸟这个定义只是最原始的纯净对象加上的定义。从客观认识的角度来说，你可以认为它是一只鸟，如果在你要采用的建模体系中，只关心的是它会飞，有翅膀两具特性的话，鸟与飞机是没有任何区别的。
其问题的关键在于，是否完全认知了系统的需求，明白系统中所定义的对象的最大的外延的概念是什么，这说明鸟与飞机间是否要具体区分，关键在于，在系统的需要中是如何处理的，这也是为什么设计后需求无限扩大这种行为是在软件工程中往往会带来不可估计的后果的原因。需求的扩大往往会导致对象定义外沿扩展，尤其涉及到系统中的重要对象概念扩大时，它及有可能会导致整体系统的概念意义上的崩溃。
在简单计算行星间的作用力关系时，我们通常不考虑一些微不足道的因素，一律把它们作为质点来考察，虽然比如某颗行星上有粒石子在滚动之类因素实际是有很微小的影响，但要更大的系统角度来考虑的话，我们可以采用忽略它们存在来进行脱脂建模。
正因为这种忽略性手法，我们才能知道地球的自转速率，才能知道行星间的距离，但在现实上，好像这一切与我们都不靠谱，似乎与我们无关，不清楚地球的转动速度，我们一样可以生存。
实际上，这也是因为一个人所处的系统环境所订的，如果一样事物与你无关或影响力非常微小，你就可以忽略它，如果你的系统进入了特定的环境，原本小的影响因素也许就会变大。假如你是一个狙击手，如果在2公里外开枪，除了枪本身的因素外，考虑了子弹飞行几秒种的时间，风力、温度影响，结果发现还是有偏差，有人就会质疑理论的准确性，实际上，这是因为没有考虑地球自转所带来的影响，也就是理论上的不完备性。
所以，通常看起来抽象与实现间的许多矛盾，实际上因为人类的认识问题，所导致的不完备的抽象定义所导致的，从软件开发来说，这些定义的制定原则，必须除了要考虑开发本身的问题外，还必须要考虑在具体实现上，硬件的条件，编译器环境等各种综合因素。
如果想要更加含糊一些的话，我们可以认为类也是对象，因为类是对象的结构描述，它自身这种描述集合是我们可以认识的，所以它也是一种对象。
通常意义上我们所说的类与对象有所区别，这是因为概念的范畴发生的变化，真正概念意义上的纯正类定义，在开发中，通常被我们称之为接口，因为它是真正的无数据实现定义的描述，这也是为什么接口在OO支持论者心目中是那么的重要。开发中的类，是一种提供了抽象概念与实现概念间的桥梁，它可以把抽象的定义与实现的方法都包括在里面，从成为一个对象的创建器。开发中的对象，通常是指的具体带有数据实现的对象。
清晰一些分别它们：可以认为，纯理论意义上，所有一切可认知的东西都可以称为对象。实际的开发意义上，将原始意义上的对象分为三大类，并重新命名：
1、可对其它对象进行定义与描述的对象，作为抽象工具，通常不带有数据，这以开发中的接口概念为代表
2、根据定义与描述实现的对象，作为实现个体，通常带有数据，这以开发中的对象概念为代表
3、提供定义与实现的对象，作为桥梁性手段，通常带有初始化数据及数据变化规则的描述，这以开发中的类为代表。
也就是说“一切皆对象”这种说法本身是没有错误的，但是如果意图用这种扩大的哲学化的概念来指导具体软件开发中的概念，就陷入了一种混乱。
分清了接口、类、对象后，下面皆沿用开发中的概念。
接口是一个很奇怪的东西，它只有一定义，而没有提供任何实现的方法，如果只是接口试图来摸拟世界运作而不依赖于任何实现的话，那不亚于你在纸上画画行星就能改变行星轨道一样有难度。所以必须采用类的概念，严格意义上来说，类并不是分类的定义与组合，它是接口与对象间如何过渡的规则描述。
接口在设计中，可以用来勾勒结构关系，类在设计中，是过渡抽象到实现的必要手段，对象则是在设计中具体数据载体及该对象对数据转化的操作形式。
Brooks认为“数据的表现形式是编程的根本. ”，这是因为，数据是开发中实现各种思想与方法最小单位，它就像我们这个世界中的基本粒子一样，我们同样可以认为，这个世界的根本就是基本粒子的运动。
很多时候，开发思想与实际开发中的实现遇到的问题，并不违反思想本身的要求。认为抽象出来的事物与现实事物间很多时候不符合，那不是抽象的问题，而是实现的问题。
从抽象角度来说，你看到了一架喷气式飞机，从个人化的世界观来说，你抽象它是会飞的，有翅膀，那么打算来用鸟定义它，实际上鸟并不会喷气，尽管它会拉屎，但还是有极大的不同。问题出在哪里呢？
问题出在采用了一个具体化的“鸟”这个有数据承载的对象来定义它，也就是一个并不纯净的定义，这不是抽象描述，这是模拟描述，这是根据不完全的信息进行的推测并人为强行认为它是一只鸟，这不是鸟这个定义的错，因为鸟这个定义只是最原始的纯净对象加上的定义。从客观认识的角度来说，你可以认为它是一只鸟，如果在你要采用的建模体系中，只关心的是它会飞，有翅膀两具特性的话，鸟与飞机是没有任何区别的。
其问题的关键在于，是否完全认知了系统的需求，明白系统中所定义的对象的最大的外延的概念是什么，这说明鸟与飞机间是否要具体区分，关键在于，在系统的需要中是如何处理的，这也是为什么设计后需求无限扩大这种行为是在软件工程中往往会带来不可估计的后果的原因。需求的扩大往往会导致对象定义外沿扩展，尤其涉及到系统中的重要对象概念扩大时，它及有可能会导致整体系统的概念意义上的崩溃。
在简单计算行星间的作用力关系时，我们通常不考虑一些微不足道的因素，一律把它们作为质点来考察，虽然比如某颗行星上有粒石子在滚动之类因素实际是有很微小的影响，但要更大的系统角度来考虑的话，我们可以采用忽略它们存在来进行脱脂建模。
正因为这种忽略性手法，我们才能知道地球的自转速率，才能知道行星间的距离，但在现实上，好像这一切与我们都不靠谱，似乎与我们无关，不清楚地球的转动速度，我们一样可以生存。
实际上，这也是因为一个人所处的系统环境所订的，如果一样事物与你无关或影响力非常微小，你就可以忽略它，如果你的系统进入了特定的环境，原本小的影响因素也许就会变大。假如你是一个狙击手，如果在2公里外开枪，除了枪本身的因素外，考虑了子弹飞行几秒种的时间，风力、温度影响，结果发现还是有偏差，有人就会质疑理论的准确性，实际上，这是因为没有考虑地球自转所带来的影响，也就是理论上的不完备性。
所以，通常看起来抽象与实现间的许多矛盾，实际上因为人类的认识问题，所导致的不完备的抽象定义所导致的，从软件开发来说，这些定义的制定原则，必须除了要考虑开发本身的问题外，还必须要考虑在具体实现上，硬件的条件，编译器环境等各种综合因素。
