有所为有所不为？在利用科学技术方面我们应该怎样做到有所为有所不为?
【菜科解读】
1、君子有所为有所不为是么意思？
来源于《周易》的两句话：一句是“天行健，君子以自强不息”（乾卦）；一句是“地势坤，君子以厚德载物”（坤卦）。
民国时期，梁启超在清华大学任教时，曾给当时的清华学子作了《论君子》的演讲，他在演讲中希望清华学子们都能继承中华传统美德，并引用了《易经》上的“自强不息”“厚德载物”等话语来激励清华学子。
此后，清华人便把“自强不息，厚德载物”8个字写进了清华校规，后来又逐渐演变成为清华校训。
“天行健，君子以自强不息”“地势坤，君子以厚德载物”两句意谓：天（即自然）的运动刚强劲健，相应于此，君子处世，应像天一样，自我力求进步，刚毅坚卓，发愤图强，永不停息；大地的气势厚实和顺，君子应增厚美德，容载万物。
译为：君子应该像天宇一样运行不息，即使颠沛流离，也不屈不挠；如果你是君子，接物度量要像大地一样，没有任何东西不能承载。
就是说有的事该做有的事不该做。
。
。
2、在利用科学技术方面我们应该怎样做到有所为有所不为?
1、科学技术作为先进生产力的标志，对于推动社会发展具有重要作用。
现代科学技术对人类的生产方式、生活方式、思维方式都产生了巨大的影响。
2、但科学技术的社会作用具有二重性，它既能通过促进经济和社会发展以造福于人类，也可能在一定条件下对人类的生存和发展带来消极后果。
其中不良影响之一就是在发展现代工业的过程中，违反自然规律，破坏生态环境，造成环境污染等，对人类的生存和发展造成不同程度的伤害。
3、对此，我们要用科学的自然观和发展观指导人们，树立全球观念、与自然和谐相处的观念和危机意识，克服眼前利益和局部利益的狭隘视野和急功近利的行为，正确对待自然和社会的关系，合理利用自然资源，合理控制各种生产活动与消费活动，直至变革不适合自然与社会和谐发展的社会形式。
有所为，有所不为，为人类摆脱困境创造新的物质手段。
科学技术是推动经济和社会发展的强大杠杆。
人类社会历史上，曾经发生过三次科学技术革命。
每一次科技革命都冲击着现实社会和意识形态中一切陈旧的生产方式、价值观念等等，以不可抗拒的磅礴之势，在物质生活方面为人类开辟了一个辉煌的前景。
首先，科学技术对生产方式产生的深刻影响，改变了社会生产力的构成要素；改变了人们的劳动形式；也改变了社会经济结构，特别是导致产业结构发生变革。
其次，对生活方式产生了巨大的影响。
再次，促进了人们思维方式的变革。
然而，科学技术像一把双刃剑，它一方面极大地开阔了人们的视域和活动范围，增强了人们的创造力，另一方面也使人类的破坏能力空前地增长，并且使人类与周围的环境处于一种紧张的矛盾关系之中。
人们逐渐发现自己正在陷入某种困境：全球气候变暖，土壤过分流失和土地沙漠化扩大，自然资源急剧减少，生物物种加速灭绝，环境污染和生态危机等问题日益突出，这些都是由于人类不合理和不负责任地利用科学技术来掠夺自然所造成的恶果，都是人类以自然主宰的身份自居而与自然发生冲突的结果。
正如恩格斯所言：“我们不要过分陶醉于我们人类对自然界的胜利。
对于每一次这样的胜利，自然界都对我们进行报复。
”
在我国，1998年，长江、松花江等大江大河，爆发了特大洪灾，及黄河年年断流，断流的时间与河段不断延长，加之沿河两岸的环境污染，使得黄河流域的活力不断减弱。
这些都是人们人们对森林资源的乱采乱伐，导致了自然植被的严重破坏，造成的结果。
几十年来愈演愈烈的沙尘暴，让首都北京甚至黄河以南的城市居民都领略到塞外风暴的威力。
几年前爆发的非典，以及近两年的禽流感和最近的猪流感，都无不表明生态环境的日益恶化。
因此，面对人口、资源、环境方面的国情，实施可持续发展战略是我们的基本国策。
可持续发展就是既能满足当代人的需求，又不损害后人满足其需求的能力。
可持续发展要求人们与自然和谐共处，能够认识到自己对自然、对社会和子孙后代应负的责任。
我们要依靠科技进步、节约能源、减少废物排放和文明消费,建立经济、社会、资源与环境协调、持续、发展的新模式。
要强调科学技术发展的"生态化",强调整体性思维,把人类、社会和自然看作是一个有机整体加以认识和对待。
不断完善科学技术成果的应用,使整个科学技术沿着符合生态保护的方向发展。
通过采用绿色技术进行清洁生产,通过提高资源利用率减少废弃物排放,达到提高经济效率和保护环境的双重目的。
这样的经济同传统浪费型经济有区别,是一种节约型经济。
如何利用C#实现标准的Dispose模式
我们已经知道了处置那些占用非受控（unmanaged）资源的对象的重要性，现在应该编写资源管理代码来处置那些包含非内存资源的类型了。
整个.NET框架组件都使用一个标准的模式来处理非内存资源。
使用你建立的类型的用户也希望你遵循这个标准的模式。
标准的处理模式的思想是这样的：当客户端记得的时候使用IDisposable接口释放你的非受控资源，当客户端忘记的时候防护性地使用终结器（finalizer）。
它与垃圾收集器（Garbage Collector）一起工作，确保只在必要的时候该对象才受到与终结器相关的性能影响。
这是处理非受控资源的一条很好的途径，因此我们应该彻底地认识它。
类层次体系中的根基类（root base class）必须实现IDisposable接口以释放资源。
这个类型还必须添加一个作为防御机制的终结器。
所有这些程序都把释放资源的工作委托给一个虚拟的方法，衍生的类可以根据自己的资源管理需求来重载该方法。
只要衍生的类必须释放自己的资源，并且它必须调用该函数的基类版本的时候，它才需要重载这个虚拟方法。
开始的时候，如果你的类使用了非内存资源，它就必须含有一个终结器。
你不能依赖客户端总是调用Dispose()方法。
因为当它们忘记这样做的时候，你就面临资源泄漏的问题。
没有调用Dispose是它们的问题，但是你却有过失。
用于保证非内存资源被正确地释放的唯一途径是建立终结器。
当垃圾收集器运行的时候，它立即从内存中删除所有不带终结器的垃圾对象。
所有带有终结器的对象仍然存在于内存中。
这些对象都被添加到终结队列，垃圾收集器引发一个新线程，周期性地在这些对象上运行终结器。
在这些终结程序线程完成自己的工作之后，就可以从内存中删除垃圾对象了。
需要终结的对象在内存中停留的时间比没有终结器的对象停留的时间长很多。
但是你别无选择。
如果要使程序有防护性，在类型包含非受控资源的时候，你必须编写一个终结器。
但是也不用担心性能问题。
下一步确保了客户端避免与终结相关的性能开销。
实现IDisposable接口是一种标准的途径，它通知用户和运行时系统持有资源的对象必须及时地释放。
IDisposable接口仅仅包含一个方法： public interface IDisposable { void Dispose( ); } 你对IDisposable.Dispose()方法的实现（implementation）负责下面四个事务： 1、释放所有的非受控资源。
2、释放所有的受控资源（包括未解开事件）。
3、设置标志表明该对象已经被处理过了。
你必须在自己的公共方法中检查这种状态标志并抛出ObjectDisposed异常（如果某个对象被处理过之后再次被调用的话）。
4、禁止终结操作（finalization）。
你调用GC.SuppressFinalize(this)来完成这种事务。
通过实现IDisposable接口你完成了两个事务：你为客户端及时地释放自己持有的所有受控资源提供了机制；你为客户端提供了一种释放非受控资源的标准途径。
这是一个很大的进步。
当你在类型中实现了Idisposable接口的时候，客户端可以避免终结操作的开销，你的类就成为.NET世界中的"良民"了。
但是在你建立的这种机制中仍然存在一些问题。
怎样在衍生类清理自己资源的时候同时也让基类能够清理资源？如果衍生类重载了终结操作，或者添加了自己的IDisposable实现，那么这些方法必须调用基类，否则，基类就不能正确地进行清理操作。
同样，finalize（终结操作）和Dispose参与分担了一些相同的职责。
Finalize方法和Dispose方法的代码几乎相同。
而且在重载接口函数后并不像你预料的那样工作。
标准的Dispose模式中的第三个方法是一个受保护的虚拟辅助函数，它分解出这些共同的事务，并给衍生类添加一个用于释放资源的"钩子（hook）"。
基类包含了核心接口的代码。
作为对Dispose()或终结操作的响应，该虚拟函数为衍生类清除资源提供了"钩子"： protected virtual void Dispose( bool isDisposing ); 这个重载的方法实现支持finalize和Dispose的必要事务，由于它是虚拟的，它为所有的衍生类提供了一个入口点。
衍生类可以重载这个方法，为清除自己的资源提供适当的实现，同时还可以调用基类版本。
当isDisposing为真（true）的时候，你可以清除受控和非受控资源，当isDisposing为假（false）的时候，你只能清除非受控资源。
在这两种情况下，你都可以调用基类的Dispose(bool)方法，让它清除自己的资源。
下面有一个简短的例子，它演示了你在实现这种模式的时候所提供的代码框架。
MyResourceHog类演示了实现IDisposable接口、终结器的代码，并建立了一个虚拟的Dispose方法： public class MyResourceHog : IDisposable { // 已经被处理过的标记 private bool _alreadyDisposed = false; // 终结器。
调用虚拟的Dispose方法 ~MyResourceHog() { Dispose( false ); } // IDisposable的实现 // 调用虚拟的Dispose方法。
禁止Finalization（终结操作） public void Dispose() { Dispose( true ); GC.SuppressFinalize( true ); } // 虚拟的Dispose方法 protected virtual void Dispose( bool isDisposing ) { // 不要多次处理 if ( _alreadyDisposed ) return; if ( isDisposing ) { // TODO: 此处释放受控资源 } // TODO: 此处释放非受控资源。
设置被处理过标记 _alreadyDisposed = true; } } 如果衍生类需要执行另外的清除操作，它应该实现受保护的Dispose方法： public class DerivedResourceHog : MyResourceHog { // 它有自己的被处理过标记 private bool _disposed = false; protected override void Dispose( bool isDisposing ) { // 不要多次处理 if ( _disposed ) return; if ( isDisposing ) { // TODO: 此处释放受控资源 } // TODO: 此处释放所有受控资源 // 让基类释放自己的资源。
基类负责调用GC.SuppressFinalize( ) base.Dispose( isDisposing ); // 设置衍生类的被处理过标记 _disposed = true; } } 请注意，基类和衍生类都包含该对象的被处理过（disposed）标记。
这纯粹是起保护作用。
复制这个标记可以封装构成某个对象的所有类释放资源时产生的任何可能的错误。
你必须编写防护性的Dispose和finalize。
对象的处理可以按任意次序进行，你可能会遇到在调用自己类型的成员对象的Dispose()方法之前，该对象已经被处理过了。
你不应该认为这是问题，因为Dispose()方法会被多次调用。
如果它在已经被处理过的对象上被调用，它就不执行任何事务。
Finalizer（终结器）也有类似的规则。
如果你引用的对象仍然存在于内存中，你就没有必要检查空引用（null reference）。
但是，你引用的任何对象都可能被处理了，它也可能已经被终结了。
这为我带来了与处理或清除相关的任何方法的最重要的建议：你应该仅仅释放资源，在dispose方法中不要执行任何其它操作。
如果你在Dispose或finalize方法中执行其它操作，都可能给对象的生命周期带来严重的不良影响。
对象在被构造的时候才"出生"，当垃圾收集器收回它们的时候才"死亡"。
当你的程序再也不能访问它们的时候，你可以认为它们处于"昏睡"状态。
如果你不能到达（reach）某个对象，你就不能调用它的方法，对于所有的意图和目的来说，它是死的。
但是带有终结器的对象被宣布死亡之前还有最后一口气。
终结器除了清理非受控资源之外不应该执行其它任何操作。
如果某个终结器由于什么原因使某个对象又可以到达了，那么该对象就恢复（resurrected）了。
即使它是从"昏睡"状态醒来的，它也是"活着"的。
下面是一个很明显的例子： public class BadClass { // 保存某个全局对象的引用 private readonly ArrayList _finalizedList; private string _msg; public BadClass( ArrayList badList, string msg ) { // 缓冲该引用 _finalizedList = badList; _msg = (string)msg.Clone(); } ~BadClass() { // 把该对象添加到列表中。
这个对象是可到达的，不再是垃圾了。
它回来了！ _finalizedList.Add( this ); } } 当某个BadClass对象执行自己的终结器的时候，它向全局列表上添加了对自己的引用。
这仅仅使自己可到达了，它活了过来！但是这样操作所带来的问题使任何人都会感到胆怯。
该对象已经被终结了，因此垃圾收集器相信不用再次调用它的终结器了。
你真的需要终结一个被恢复的对象的时候，终结操作却不会发生了。
其次，你的一些资源可能不能用了。
GC不会把终结器队列中的对象可以到达的任何对象从内存中移除，但是它可能已经终结了这些对象。
如果是这样的话，那些对象一定不能再次使用了。
尽管BadClass的成员仍然存在于内存中，它们却像被处理过或被终结了一样。
在C#语言中没有控制终结次序的途径。
你不能使这种构造工作更可靠。
不要尝试！ 除了学院的练习作业之外，我从来没有见到过如此明显地使用被恢复对象的代码。
但是我看到有些代码有这个倾向，它们在终结器中试图执行某些实际工作，当终结器调用的某些函数保存了对该对象的引用的时候，它就正在把对象变成活动的状态。
原则上我们必须非常仔细地检查finalizer和Dispose方法中任何代码。
如果有些代码除了释放资源之外还执行了其它的操作，我们就需要再检查一次。
这些操作在未来可能引起程序bug。
请移除这些操作，并确保finalizer和Dispose()方法只释放资源，不作其它任务事务。
在受控环境中，你不必为自己建立的每个类型编写终结器，你只需要为存储非受控类型，或者包含了实现IDisposable接口的成员的类型编写终结器。
即使你只需要Disposable接口，不需要finalizer，也应该同时实现整个模式。
否则，你会使衍生类的标准Dispose思想的实现变得很复杂，从而限制了衍生类的功能。
请遵循前面谈到的标准的Dispose思想，这将使你、你的类的用户、从你的类型建立衍生类的用户的生活更加轻松。
如何,利用,实现,标准,的,Dispose,模式,本文,
