我理解的结构化与面向对象

    在我的编程之旅中，我发现一些问题，做了一些思考，提出了本文中的观点，这些观点应该并不新颖，只是我自己的总结，另外，可能不是最新的观点，但应该是软件开发上的主流观点吧（还没来得及学过软件工程的知识，只能猜）。

    在当今面向应用的软件开发中，一般要面临如下两个非常基本而重要的问题：

    第一，你需要满足今天的用户需求，而且在此基础上把软件的复杂度设计的尽可能低，运行效率近可能高，编写成本也应该尽可能小。

    第二，你需要让今天写的程序能够在尽可能少的修改下满足未来的需求，并且同样要满足复杂度、运行效率与编写成本上的要求。

    现在解释下上面两个问题，或者目标：

    一方面，一个软件的诞生，直接的目的就是解决当前的需求，当然，如果它的功能足够简单，那么你直接按“直觉”设计编写，就可以写出简单高效的程序来满足这些功能，但是，如果这是一个中大型的软件，如果这个软件的不同部分由不同的人来分工合作完成，那么，“直觉”式的设计编写就很不适应了，或者说面向过程或未经考虑的面向对象的设计方式就都会遇到不小的问题，原因很简单也很直接，任何写过的人也都能发现，当问题复杂到一定程度后，不经组织的编写会产生逻辑上很混乱的代码，不利于编写的继续，也会产生很多bug。因此，可以看到，一个较为复杂的软件，为了满足今天的需求，都是需要一些更为科学的框架来协助设计。

    另一方面，一个真正的好软件，其生命周期并不是结束于第一版，而是不断地推陈出新，根据需求的变化不断重构、扩展。这种功能上的变化在软件编写的后期，也就是重构的时候，往往会带来两个问题：一是开发人员对于之前写的软件比较生疏了，很难找到下手的地发；二是原来的架构不适合添加新的功能，为了添加新的功能可能要对原来的程序进行重大的变化，重构复杂编写成本高。这些问题都不是我们希望的，我们总是希望一个软件的构架具备高的扩展性，能够很容易就添加新功能，对原来的功能与实现进行修改。

    那么，为了解决本文一开始就提出的两个问题，我的理解是，我们需要更好的架构、需要更强的模块、需要面向对象的管理。在所有的软件开发初期，都是要做需求分析，对于需求分析，我的理解是：写今天的程序，做后天的需求分析。这就像下棋，你不能只看当下，一定要看到几步以后，你不仅要分析你的软件在今天要具备的功能，也要思考它在未来的功能，把今天和后天的需求考虑清楚，分清哪些是今天的需求、哪些是明天的需求、哪些是后天的需求后，你就可以根据功能来设计软件的架构了，所谓架构，就是设置哪些类来完成哪些功能，类的水平关系（功能的并列）与垂直关系（继承），当然，架构设计的真正完成，还得等到类的方法与数据的设计完成后。从UML角度而言，当架构设计完成后，你应该要做出类图和流程图。整个过程中，你都要模拟时间来到了未来，考虑未来的需求。基于我的一点经验，我感觉为了使软件具有更高的扩展性、灵活性，应该将功能设计地尽可能的独立、模块清晰，这主要是通过类来实现，而类包括方法与数据，一般我们总是忘不掉函数与功能的对应，但数据在整个软件中的流动同样是很重要（特别是重要数据的流动），不同类之间的数据交互等等，都不应该被忽视。

   以上只是我的一点感想，只是分析了软件工程中我遇到的一些基本问题，提出了一些概念性的想法，系统的规律还得以后学习软件工程以及做了更多项目后才能获得。