最近做了几个小程序，大概都在1W-2W行代码。
然后发现了一个苦恼的问题，就是在“封装方法”的时候感觉到别扭。
通常这样一个小程序，我大概会封装10个方法类左右，模型类和静态类通常看需求，尽量去避免重复调用，尽量去重构方法方便调用，但是在回头看的时候，看到的是乱糟糟的代码，而且在需求变动的时候，我所做的代码量也是很大的。
比如，在两个地方需要用到的属性，我会写这么一个类：
比如，我有几个地方需要检查xml元素的时候，我会重构这些方法：
于是，我想到了接口和继承，但是面对这些垃圾代码，我根本无从下手。可能因为对接口和继承等其他高端方面的知识点相对薄弱，没办法写出优质量代码。
最近准备去琢磨一下23种设计模式，加强对框架和结构的逻辑思维和想法。
现，请各位大牛帮帮我，如何使我的代码能够让我看起来不再乱糟糟，能够利于维护和扩展？最好是能够推荐几本适合我的书籍，比如《大话设计模式》之类的，能够加强我对整个框架的掌握和构造。小弟不甚感激，请尽情言论，骂我都没有关系，我真的是受不了这种代码不再自己掌握中的现状了，渴望提升！
------解决方案--------------------
如果是要设计模式入门类的书，我推荐《Head First 设计模式》
不过我还建议楼主看一下进阶的书籍，比如《CLR via C#》，这本书是.NET程序员必看。
这是译者的一段话，完全赞同。
读完这本书，你的心灵会受到巨大的震撼。原因很简单，以前许多似懂非懂的关键概念，现在都变得清晰明了；以前自以为是的一些做法，现在都得到彻底纠正；以前艰苦摸索的一些编程技巧，现在变得就像1+1一样简单。
------解决方案--------------------
如果是想看设计模式，可以看一下《设计模式之禅》，它会通过一些常见的例子也解释设计模式，比较容易理解。
还有一个比较直接的方法：
为自己的代码写单元测试，每个方法都不要放过。通常测试起来很舒服的代码，都是写得不错的代码。
------解决方案--------------------
什么叫“而且在需求变动的时候，我所做的代码量也是很大的”呢？具体是指什么？
你的代码，谈不上“需求变动”，因为你的代码都是一个底层（相对你自己来说）实用小方法。如果需求变动了，你却去修改、重构这些，那么你口中的“需求变动”可能只是你消磨时光在底层代码上的借口。
“需求改变了”的时候，一个程序设计师应该设计出前后一致的系统设计。也就是原来的需求也能满足，随后新的需求也能满足。而绝对不是随便“推倒了之后去重构”。
需求变动是好事，它让你成熟。
那些找借口给自己“推倒了重来”的人，往往是不靠谱的莽夫。
------解决方案--------------------
看一下《重构与模式》，专门教你怎么把恶心代码变成优美代码的。
还有可以学一下TDD方面的书，比如《敏捷软件开发原则、模式与实践》，TDD方面有句话写的很好：我们愿意被第一颗子弹击中，然后我们会确保自己不再被同一只枪发射的其他任何子弹击中。
就是说，我们写代码时，开始可以假设变化不会发生，即不要去妄想一些可能以后存在的需求。只有当真正的变化发生（新需求）时，我们再来做抽象做重构，保证以后这类问题都不需要做代码修改