非面向对象的软件有一些具体的标志，具体例如：

1. 方法接口是“无厘头”的。它没有表达所依赖的对象，包括内部计算所依赖的对象。往往它仅仅用一个空洞的“动词”来表示行为概念，却无法再接口上上说清楚行为针对哪一个对象、计算中需要的对象从哪里来。它把这些东西全都推卸给方法内部去“全局搜索”了。这种设计“臭味”是最典型的一种非面向对象设计习惯。

2. 当一个系统编写好、发布也成功之后，当处理方法需要处理更多的具体类型的对象，程序员使用switch这类分支结构，对源代码重新修改、编译。而面向对象设计方法讲求的是使用继承和多态方法进行扩展时并不去重新修改源代码。

3. 经不起类型回归检验。比如你说一个方法是针对用户进行的一个操作，但是这个用户用一个string值来代表。那么好，我随便胡乱输入一个string可以不可以用来测试这个方法是否还能正常工作？或者你定义了一个User类型，然后定义了一个OfficeMachine类型，你让后者从前者继承（目的是为了共享一些方法），那么好，我随便胡乱实例化一个OfficeMachine对象实例，然后带入所有关于User的测试程序中，还能正常工作么？

4. 代码中充斥着相互依赖、相互耦合，而很少有“客户-服务”概念存在。比如一个窗体（或者页面）中使用一个用户控件，现在用户控件上的一个行为要通知窗体（或者页面）来处理，所谓软件工程师就一门心思偏要设计为让用户控件去“查找”宿主窗体（或者）页面上的控件或者方法。他如果知道依赖倒置的概念，知道用户控件作为一个服务只需要抛出事件通知给自己的客户程序，而没有多余的职责，那么他就必须首先认识到对象这种东西才能建立这种职责分解的概念（而不是仅仅能看到方法调用）。

非面向对象的软件有一些具体的标志，具体例如：

1. 方法接口是“无厘头”的。它没有表达所依赖的对象，包括内部计算所依赖的对象。往往它仅仅用一个空洞的“动词”来表示行为概念，却无法再接口上上说清楚行为针对哪一个对象、计算中需要的对象从哪里来。它把这些东西全都推卸给方法内部去“全局搜索”了。这种设计“臭味”是最典型的一种非面向对象设计习惯。

2. 当一个系统编写好、发布也成功之后，当处理方法需要处理更多的具体类型的对象，程序员使用switch这类分支结构，对源代码重新修改、编译。而面向对象设计方法讲求的是使用继承和多态方法进行扩展时并不去重新修改源代码。

3. 经不起类型回归检验。比如你说一个方法是针对用户进行的一个操作，但是这个用户用一个string值来代表。那么好，我随便胡乱输入一个string可以不可以用来测试这个方法是否还能正常工作？或者你定义了一个User类型，然后定义了一个OfficeMachine类型，你让后者从前者继承（目的是为了共享一些方法），那么好，我随便胡乱实例化一个OfficeMachine对象实例，然后带入所有关于User的测试程序中，还能正常工作么？

4. 代码中充斥着相互依赖、相互耦合，而很少有“客户-服务”概念存在。比如一个窗体（或者页面）中使用一个用户控件，现在用户控件上的一个行为要通知窗体（或者页面）来处理，所谓软件工程师就一门心思偏要设计为让用户控件去“查找”宿主窗体（或者）页面上的控件或者方法。他如果知道依赖倒置的概念，知道用户控件作为一个服务只需要抛出事件通知给自己的客户程序，而没有多余的职责，那么他就必须首先认识到对象这种东西才能建立这种职责分解的概念（而不是仅仅能看到方法调用）。