问题描述
名字叫re@son是一个方法库，通过引用这个东西，可以方便的写出很多东西、截个图我是想请大家试用一下，给点建议。这将有助于提高技术水平……同时也方便大家其实我一直都在学习VS环境和.NET技术，当然也包括C#就是没有逛论坛的习惯，我以后会常来的。下载在这里：http://www.yes-iam.com/reason/re@son.zip现在正在完善reason的同时，也在制作网站程序，不要喷我没做网站……
解决方案
解决方案二：
我想说我是个新手，就算我是来显摆的吧可也是为了提高水平并和网友们分享技术成果千万别喷……值得一提的是reason里面我还集成了远程发送字符和下载，这两个东西挺好玩的。
解决方案三：
解决方案四：
支持总结学习方法并分享
解决方案五：
不算喷，给你点建议。看了你的类库，如果是为了学习，做类库无可厚非，可以作为经验的积累，但非常不建议你将类库拿来实用，尤其是这个学习阶段。我公司里就有这种“架构师”非常热衷于写这种类库，被我严厉批评，这不仅对他人无益，而且对自己也非常有害。一看这种封装的类库的特征，基本上就是把.Net类库中的已有功能再封装一遍，貌似是更适合自己使用，其实不然。.1、Net类库具有极其丰富的方法重载，适用于各种不同的使用场景，而你封装了以后，实际上只用到了其中一个重载方法，而且你未来也再没有机会去了解其他重载的方法。结果是本来能写的很简单的代码，封装以后，写的更加复杂了，因为你会发现你要么需要不断的封装，要么勉强用现在的封装，然后搭配其他方法来达到你的目的，结果本来使用重载的方法，一行代码能解决的，反而写出了10行代码。2、这种封装的方法，一看里边就只有几行代码的居多，本来封装意义不大。而且随着你技术的深入，最后你往往会发现，你的封装还是复杂化了，你最终可能发现封装的方法里，只有一两行代码是有效代码。封装变得没有意义3、最有害的就是禁锢了你的思想，觉得自己的类库“好用”了，却不知道你觉得的好用只是你现在这个水平下的理解。而因为“好用”，你自然就失去了继续探索.Net类库的动力。在旁观者看来，就是刚学会5%的技术就沾沾自喜，结果是捡个芝麻，丢了个西瓜。4、同样，这种类库对开发团队也是非常有害的，大家开发了半天，只是熟悉了你的类库，还是很糟糕的类库，而被禁锢在这种类库上无法脱身，再过一年两年，都没有可能有技术进步。而真相就是，只有团队技术进步了，效率提升了，后面就会获得技术红利带来的好处。我写框架，都抱着开放的心态，几乎没有Helper类封装，只使用Extend扩展，封装一般只限于业务层面和架构层面。结果是，原来架构的代码，只要充分利用.Net类库的功能，代码量可缩减三分之二，得到的是更干净更灵活的一个框架。
解决方案六：
引用4楼daixf_csdn的回复:
不算喷，给你点建议。看了你的类库，如果是为了学习，做类库无可厚非，可以作为经验的积累，但非常不建议你将类库拿来实用，尤其是这个学习阶段。我公司里就有这种“架构师”非常热衷于写这种类库，被我严厉批评，这不仅对他人无益，而且对自己也非常有害。一看这种封装的类库的特征，基本上就是把.Net类库中的已有功能再封装一遍，貌似是更适合自己使用，其实不然。.1、Net类库具有极其丰富的方法重载，适用于各种不同的使用场景，而你封装了以后，实际上只用到了其中一个重载方法，而且你未来也再没有机会去了解其他重载的方法。结果是本来能写的很简单的代码，封装以后，写的更加复杂了，因为你会发现你要么需要不断的封装，要么勉强用现在的封装，然后搭配其他方法来达到你的目的，结果本来使用重载的方法，一行代码能解决的，反而写出了10行代码。2、这种封装的方法，一看里边就只有几行代码的居多，本来封装意义不大。而且随着你技术的深入，最后你往往会发现，你的封装还是复杂化了，你最终可能发现封装的方法里，只有一两行代码是有效代码。封装变得没有意义3、最有害的就是禁锢了你的思想，觉得自己的类库“好用”了，却不知道你觉得的好用只是你现在这个水平下的理解。而因为“好用”，你自然就失去了继续探索.Net类库的动力。在旁观者看来，就是刚学会5%的技术就沾沾自喜，结果是捡个芝麻，丢了个西瓜。4、同样，这种类库对开发团队也是非常有害的，大家开发了半天，只是熟悉了你的类库，还是很糟糕的类库，而被禁锢在这种类库上无法脱身，再过一年两年，都没有可能有技术进步。而真相就是，只有团队技术进步了，效率提升了，后面就会获得技术红利带来的好处。我写框架，都抱着开放的心态，几乎没有Helper类封装，只使用Extend扩展，封装一般只限于业务层面和架构层面。结果是，原来架构的代码，只要充分利用.Net类库的功能，代码量可缩减三分之二，得到的是更干净更灵活的一个框架。
代码的封装是为了让前台写程序更简单，方便为目的，如果脱离这个目的，当然是不封装为好。一般人刚开始封装时，会犯一个毛病：过度封装。封装一般会针对应用场景。例如：对WCF的代理，封装后让前台觉得就象直接访问数据库一样。这类的封装是必要的。而且，作为写"架构“的人，其经验一定比别人丰富。例如，他可以把这个代理封装成一个POOL。可以将压缩，解压，安全等等。封装的难点往往是难以把握度。过度和不及都不好。
解决方案七：
解决方案八：
好方法,感謝你
解决方案九：
引用楼主sheanjohn的回复:
名字叫re@son是一个方法库，通过引用这个东西，可以方便的写出很多东西、
关于是否“方便”的问题，抱着“我自己用着，貌似长进了一点点”的态度就行了。100个人搞开发，可能有99个人不在意一些他感觉当时对他并没有什么明显效益的类库，这其实也是常事儿。要抱着比较宽容、理解的心态。实际上一直坚持好几年都去推广一些类库的人，也很少的。csdn上发布东西，肯定是不叫“座”的。是不是叫好这就不好说了。但叫好的人未必帮你推广什么代码，不叫好的人未必不与你讨论技术。毕竟这是一个技术论坛，而研发技术并不是那种单纯地“从网上收集一些简单的语句”的思路，肯定有不同层面的技术。真正的技术甚至可能不是代码的，而是方法。所以论坛上以技术讨论、分析总结为主。基本上不打广告。
解决方案十：
引用4楼daixf_csdn的回复:
不算喷，给你点建议。看了你的类库，如果是为了学习，做类库无可厚非，可以作为经验的积累，但非常不建议你将类库拿来实用，尤其是这个学习阶段。我公司里就有这种“架构师”非常热衷于写这种类库，被我严厉批评，这不仅对他人无益，而且对自己也非常有害。一看这种封装的类库的特征，基本上就是把.Net类库中的已有功能再封装一遍，貌似是更适合自己使用，其实不然。.1、Net类库具有极其丰富的方法重载，适用于各种不同的使用场景，而你封装了以后，实际上只用到了其中一个重载方法，而且你未来也再没有机会去了解其他重载的方法。结果是本来能写的很简单的代码，封装以后，写的更加复杂了，因为你会发现你要么需要不断的封装，要么勉强用现在的封装，然后搭配其他方法来达到你的目的，结果本来使用重载的方法，一行代码能解决的，反而写出了10行代码。2、这种封装的方法，一看里边就只有几行代码的居多，本来封装意义不大。而且随着你技术的深入，最后你往往会发现，你的封装还是复杂化了，你最终可能发现封装的方法里，只有一两行代码是有效代码。封装变得没有意义3、最有害的就是禁锢了你的思想，觉得自己的类库“好用”了，却不知道你觉得的好用只是你现在这个水平下的理解。而因为“好用”，你自然就失去了继续探索.Net类库的动力。在旁观者看来，就是刚学会5%的技术就沾沾自喜，结果是捡个芝麻，丢了个西瓜。4、同样，这种类库对开发团队也是非常有害的，大家开发了半天，只是熟悉了你的类库，还是很糟糕的类库，而被禁锢在这种类库上无法脱身，再过一年两年，都没有可能有技术进步。而真相就是，只有团队技术进步了，效率提升了，后面就会获得技术红利带来的好处。我写框架，都抱着开放的心态，几乎没有Helper类封装，只使用Extend扩展，封装一般只限于业务层面和架构层面。结果是，原来架构的代码，只要充分利用.Net类库的功能，代码量可缩减三分之二，得到的是更干净更灵活的一个框架。
公司内有N套项目，扣除一些特定业务逻辑所需要的业务代码外，项目的很多非业务层代码其实很多是有公用需求的，我个人觉得封装一些常用类库来作为公司的整体统一框架Utils也没啥一定对或错说法、也没啥严重到害人害己这类程度。。。毕竟项目开发考虑的基础点首先就不是纯为了技术而技术-----老觉得程序猿多手写一行多一行代码就是牛逼哄哄、自豪感，一个项目开发我们要考虑开发周期、维护成本、团队的高低水平等等。假设像楼主提供的类库md5这个来说团队有10个程序猿，不一定每个人都会懂.net具体怎么个写法，然后呢，每个人开始造轮子又各自项目各写一套？
解决方案十一：
引用9楼tiancaolin的回复:
Quote: 引用4楼daixf_csdn的回复:
不算喷，给你点建议。看了你的类库，如果是为了学习，做类库无可厚非，可以作为经验的积累，但非常不建议你将类库拿来实用，尤其是这个学习阶段。我公司里就有这种“架构师”非常热衷于写这种类库，被我严厉批评，这不仅对他人无益，而且对自己也非常有害。一看这种封装的类库的特征，基本上就是把.Net类库中的已有功能再封装一遍，貌似是更适合自己使用，其实不然。.1、Net类库具有极其丰富的方法重载，适用于各种不同的使用场景，而你封装了以后，实际上只用到了其中一个重载方法，而且你未来也再没有机会去了解其他重载的方法。结果是本来能写的很简单的代码，封装以后，写的更加复杂了，因为你会发现你要么需要不断的封装，要么勉强用现在的封装，然后搭配其他方法来达到你的目的，结果本来使用重载的方法，一行代码能解决的，反而写出了10行代码。2、这种封装的方法，一看里边就只有几行代码的居多，本来封装意义不大。而且随着你技术的深入，最后你往往会发现，你的封装还是复杂化了，你最终可能发现封装的方法里，只有一两行代码是有效代码。封装变得没有意义3、最有害的就是禁锢了你的思想，觉得自己的类库“好用”了，却不知道你觉得的好用只是你现在这个水平下的理解。而因为“好用”，你自然就失去了继续探索.Net类库的动力。在旁观者看来，就是刚学会5%的技术就沾沾自喜，结果是捡个芝麻，丢了个西瓜。4、同样，这种类库对开发团队也是非常有害的，大家开发了半天，只是熟悉了你的类库，还是很糟糕的类库，而被禁锢在这种类库上无法脱身，再过一年两年，都没有可能有技术进步。而真相就是，只有团队技术进步了，效率提升了，后面就会获得技术红利带来的好处。我写框架，都抱着开放的心态，几乎没有Helper类封装，只使用Extend扩展，封装一般只限于业务层面和架构层面。结果是，原来架构的代码，只要充分利用.Net类库的功能，代码量可缩减三分之二，得到的是更干净更灵活的一个框架。公司内有N套项目，扣除一些特定业务逻辑所需要的业务代码外，项目的很多非业务层代码其实很多是有公用需求的，我个人觉得封装一些常用类库来作为公司的整体统一框架Utils也没啥一定对或错说法、也没啥严重到害人害己这类程度。。。毕竟项目开发考虑的基础点首先就不是纯为了技术而技术-----老觉得程序猿多手写一行多一行代码就是牛逼哄哄、自豪感，一个项目开发我们要考虑开发周期、维护成本、团队的高低水平等等。假设像楼主提供的类库md5这个来说团队有10个程序猿，不一定每个人都会懂.net具体怎么个写法，然后呢，每个人开始造轮子又各自项目各写一套？
这个是要管理了,每个类都有一个很好的分类.如果某个功能有三次以上被调用,那这个功能就可以考虑入到类库里了.楼主提供的个MD5,如果是仅仅是用NET代码里封装一下的MD5或没有做任何技术变化的MD5,没有多少意义.MD5的生成很慢,但MD5在系统里却用得很多.所以,生成一个MD5很容易,关建的问题是:快.第二.是否有MD5的其变种(不是加盐加了几个字符串的变种).第三,既然考虑了MD5,那就要考虑到其它和MD5同性质的东西,MD5的本质可以看成是HAS128,那要考虑HAS160,HAS256....然后要加入CRC16/32/40.../64...再加入各种HASCODE的生成法.这样,这个就不再叫MD5了,这个叫HAS了.这更有通用性.
解决方案十二：
该回复于2016-05-31 23:16:09被版主删除
解决方案十三：
没什么用。........
解决方案十四：
该回复于2016-05-24 00:07:32被版主删除
解决方案十五：
虽然我没下载，但估计很烂，或者说没虾米用处——看源文件的文件名就知道个大概了。
解决方案：
解决方案：
为啥你们发的帖子都这么多人来评论
解决方案：
该回复于2016-05-31 23:16:25被版主删除
解决方案：
该回复于2016-05-31 23:16:43被版主删除
解决方案：
该回复于2016-05-24 00:07:54被版主删除
解决方案：
想了一下，说好或者不好都很正常。我若高手，我将帮助他人；若新手，发一些自己看起来感觉不错的作品也没错。我还是感谢各位关注，吸取广大意见，改善需改善部分，完善该完善的地方。有句话说得好，谁曾经年少没二过……继续讨论，继续讨论……
解决方案：
你们是大神，我们是小学生。既然我们讨论到了这个话题，那就继续下去话题是：方法库将以什么形态存在让公司的项目快速开发时，让自己的程序开发便捷时让全国码农都学习并使用时，比如thinkPHP难道你说他们错了么……我也说不好应不应该提倡类库、框架一说有的人觉得方便，还有人觉得多此一举也正常不过……你参与讨论的那一段话，只代表你自己的看法难道不是么……我完全是抛开REASON而说的……
解决方案：
引用21楼sheanjohn的回复:
你们是大神，我们是小学生。既然我们讨论到了这个话题，那就继续下去话题是：方法库将以什么形态存在让公司的项目快速开发时，让自己的程序开发便捷时让全国码农都学习并使用时，比如thinkPHP难道你说他们错了么……我也说不好应不应该提倡类库、框架一说有的人觉得方便，还有人觉得多此一举也正常不过……你参与讨论的那一段话，只代表你自己的看法难道不是么……我完全是抛开REASON而说的……
做一个项目或者产品，框架是必须的，类库也是必须的。关键是大家对类库的理解不同。我的观念其实是这样：1、.Net框架做了的事情，我们不需要再做，比如把它们的方法库重新组织后再封装，像你的File，Ini，DateTime等功能，等你真正精通了c#，你会发现.Net已经做到极致了，我已经想不出有任何再封装它的理由，封装它的唯一结果，是弱化它的功能2、承接第一点，我不赞成通过封装弱化功能。当然有些公司有现实情况，说通过封装降低学习难度，让初级程序员不用思考太多，就能编程，这可能也是一种现实吧3、我倾向于在.Net框架上进行扩展，多用Extend模式少用Helper模式4、涉及到框架层面，我同样会封装5、最后说一个我的准则，我在考虑要封装一个方法时，都会考虑下，.Net框架有没有类似功能？有的话我基本上不会再去封装
解决方案：
引用22楼daixf_csdn的回复:
Quote: 引用21楼sheanjohn的回复:
你们是大神，我们是小学生。既然我们讨论到了这个话题，那就继续下去话题是：方法库将以什么形态存在让公司的项目快速开发时，让自己的程序开发便捷时让全国码农都学习并使用时，比如thinkPHP难道你说他们错了么……我也说不好应不应该提倡类库、框架一说有的人觉得方便，还有人觉得多此一举也正常不过……你参与讨论的那一段话，只代表你自己的看法难道不是么……我完全是抛开REASON而说的……做一个项目或者产品，框架是必须的，类库也是必须的。关键是大家对类库的理解不同。我的观念其实是这样：1、.Net框架做了的事情，我们不需要再做，比如把它们的方法库重新组织后再封装，像你的File，Ini，DateTime等功能，等你真正精通了c#，你会发现.Net已经做到极致了，我已经想不出有任何再封装它的理由，封装它的唯一结果，是弱化它的功能2、承接第一点，我不赞成通过封装弱化功能。当然有些公司有现实情况，说通过封装降低学习难度，让初级程序员不用思考太多，就能编程，这可能也是一种现实吧3、我倾向于在.Net框架上进行扩展，多用Extend模式少用Helper模式4、涉及到框架层面，我同样会封装5、最后说一个我的准则，我在考虑要封装一个方法时，都会考虑下，.Net框架有没有类似功能？有的话我基本上不会再去封装
我同意你观点，并且也要反驳。CSS的框架，PHP，甚至JS的框架数不胜数……bootstrap连菜单都给你定义好了，所有用它默认的方式开发出的前台样式都一样。但是却能通过它编写出不同风格的网站，然而，人们却还乐死不疲的去使用它……按照你的思路，难道css并不高级，难道CSS本身就很弱化，还是bootstrap把CSS给弱化了……越深入，越觉得这个话题很有哲理啊，我们应该吃鸡，还是应该吃蛋……换句话说，是鸡生蛋快，还是蛋孵鸡来的快的问题了……
解决方案：
我感觉，你说的大概不过就是讲框架把人们封装在了有限的空间里。想干点儿外边的事儿很难。这没错啊，但是你换位思考一下大工程师：我甚至可以摆脱HTML的束缚，再创建一种超文本协议，我可以解释其他语言成为网页……小程序员：有了HTML5这东西，开发网页简单多了……应用，并不意为适用
解决方案：
引用14楼mlxwl2013的回复:
虽然我没下载，但估计很烂，或者说没虾米用处——看源文件的文件名就知道个大概了。
简直就是赤裸裸的批评……我接受==
解决方案：
引用23楼sheanjohn的回复:
Quote: 引用22楼daixf_csdn的回复:
Quote: 引用21楼sheanjohn的回复:
你们是大神，我们是小学生。既然我们讨论到了这个话题，那就继续下去话题是：方法库将以什么形态存在让公司的项目快速开发时，让自己的程序开发便捷时让全国码农都学习并使用时，比如thinkPHP难道你说他们错了么……我也说不好应不应该提倡类库、框架一说有的人觉得方便，还有人觉得多此一举也正常不过……你参与讨论的那一段话，只代表你自己的看法难道不是么……我完全是抛开REASON而说的……做一个项目或者产品，框架是必须的，类库也是必须的。关键是大家对类库的理解不同。我的观念其实是这样：1、.Net框架做了的事情，我们不需要再做，比如把它们的方法库重新组织后再封装，像你的File，Ini，DateTime等功能，等你真正精通了c#，你会发现.Net已经做到极致了，我已经想不出有任何再封装它的理由，封装它的唯一结果，是弱化它的功能2、承接第一点，我不赞成通过封装弱化功能。当然有些公司有现实情况，说通过封装降低学习难度，让初级程序员不用思考太多，就能编程，这可能也是一种现实吧3、我倾向于在.Net框架上进行扩展，多用Extend模式少用Helper模式4、涉及到框架层面，我同样会封装5、最后说一个我的准则，我在考虑要封装一个方法时，都会考虑下，.Net框架有没有类似功能？有的话我基本上不会再去封装
我同意你观点，并且也要反驳。CSS的框架，PHP，甚至JS的框架数不胜数……bootstrap连菜单都给你定义好了，所有用它默认的方式开发出的前台样式都一样。但是却能通过它编写出不同风格的网站，然而，人们却还乐死不疲的去使用它……按照你的思路，难道css并不高级，难道CSS本身就很弱化，还是bootstrap把CSS给弱化了……越深入，越觉得这个话题很有哲理啊，我们应该吃鸡，还是应该吃蛋……换句话说，是鸡生蛋快，还是蛋孵鸡来的快的问题了……
不是的，是因为设计CSS，JQuery的，BootStrap的人，水平太高了，我还没达到他们的10%，所以我把我的目标定在使用好他们的工具，而不是自己发明轮子
解决方案：
各人开发各人的方式。只要不影响开发效率，不影响程序稳定性。个人倾向类库的方式。比较不喜欢Extend
解决方案：
该回复于2016-05-31 23:16:58被版主删除
解决方案：
该回复于2016-05-24 00:07:32被版主删除
解决方案：
楼主辛苦
解决方案：
引用22楼daixf_csdn的回复:
Quote: 引用21楼sheanjohn的回复:
最后说一个我的准则，我在考虑要封装一个方法时，都会考虑下，.Net框架有没有类似功能？有的话我基本上不会再去封装此言有同感。层次吧，每个阶段感受不一样的。
解决方案：
此言有同感。层次吧，每个阶段感受不一样的。
解决方案：解决方案：
该回复于2016-05-31 23:17:13被版主删除
解决方案：
很好非常好，鼓励!
解决方案：
一百个人有一百种口味，首先当然是满足自己的口味，当然也应该偶尔尝尝其它口味。说句实在话，就.NET自身那些东西，离实际应用可能差个十万八千里，不自己封装那真是搬砖的节奏。
解决方案：
能提升开发效率的东西就是好东西，支持，加油。
解决方案：
下载了，还没打开看，但我知道对我肯定有用，谢谢楼主！
解决方案：
简单的做了个网站，现在可以通过点击链接来下载了……www.yes-iam.com
解决方案：
引用39楼sheanjohn的回复:
简单的做了个网站，现在可以通过点击链接来下载了……www.yes-iam.com域名不错。
解决方案：
引用40楼u010227555的回复:
Quote: 引用39楼sheanjohn的回复:
简单的做了个网站，现在可以通过点击链接来下载了……www.yes-iam.com域名不错。
想要便宜卖给你
解决方案：
很恶心所谓的重复造轮子论调，不过自己写的库除非在多个项目中长期实践过，不然都不会拿出来给人用.
解决方案：
羡慕，学习了
解决方案：
楼主可以把这些东西写进一个.h文件里头（封装），添加进编程软件的头文件路径，在进行一些设置，就可以用了。比如我要写一个test.h#ifndef_test_h_intsum(inta,intb){returna+b;}#endif添进Dev_C++头文件的路径，就可以写出如下代码：#include<test.h>intmain(){inta=5,b=6,c;c=sum(a,b);return0;}
解决方案：
引用44楼qq_34896694的回复:
楼主可以把这些东西写进一个.h文件里头（封装），添加进编程软件的头文件路径，在进行一些设置，就可以用了。比如我要写一个test.h#ifndef_test_h_intsum(inta,intb){returna+b;}#endif添进Dev_C++头文件的路径，就可以写出如下代码：#include<test.h>intmain(){inta=5,b=6,c;c=sum(a,b);return0;}超出范围…….H不是C就是C++来着==
解决方案：
新手小白，没弄懂啥封装，特感汗颜！
解决方案：
收下以备后用
解决方案：
小平同志说，不管白猫黑猫，能抓到老鼠的就是好猫啊
解决方案：
我以为分享的是源码，结果是编译好的dll……
解决方案：
引用49楼u012523524的回复:
我以为分享的是源码，结果是编译好的dll……请允许我少有保留……
时间： 2024-11-14 18:01:40