写一个大型项目，需求是变化的，这时候最重要的是了解整个项目的大致规划，在程序中表达出来，这就是程序框架，某些情况下一个大型项目并不能清晰描述出项目本身的轮廓。这并不能抱怨项目本身，而需要将框架做的灵活便于任何倾向性产生而适应延伸。
在写项目时，并不需要构建很具体的接口（interface）和基类（super class）。因为即便你定义了，也很难描述它。但是你要应对改变和通用性，为了更好的扩展，这些类和接口是描述和扩展的前提。
举个例子，你有一个场景（scene），基于（view），无接口，这显然场景只是直接创建起来用于应对当前需求的扩展。而随着项目不断扩大，你可能存在几个，十几个，甚至几十个场景（scene），那么如果改其中一个，你也许无法立刻找到曾经修改的迹象，以及如果为了应付其他接口，这类场景（scene）需要适配新的变量（variable）和有统一的入场动画（animation），以及场景颜色（backgroud color）。那么你要对这么多场景（scene）一一去改么。十分不现实，而且对于程序员来说，任何能增加效率和减少出错率的行为（behaviour）都值得我们去付出。这有点像热力学定律。在项目进行过程中，不是把麻烦扩大化，而是将麻烦收敛起来，作为少部分甚至是单一问题来考虑。
我们把场景（scene）曾经的api提取出来，如果需要实现那么就放到父级（super class）中去实现，这样即便一个新的场景（scene）也能赋予这种能力，比如场景背景色（backgroud color）。当需要统一api，那么需要个接口（interface）统一定义。
父类的protected属性变量和函数都可以被子类利用，可以利用这一点封装api，而不影响外部调用和降低干扰。
一般语言的接口不可以定义变量，但是父类可以定义出来。
当你应对上面的问题，你应该很愿意用这类方法改善架构。当然如果为了偷懒省时间，最后麻烦会找到你。记住，任何修改都可能带来潜在的bug，我们的目标是制作一个bug尽量少的项目，而不是把bug深埋起来。
另外，亦不必为端口模块过于标准化去完善，对项目没有太多帮助的话，还是以项目为重点。过度标准化是对工程理想化的体现，不过会影响项目效率。
