C#防止回溯辦法心得。本站提示廣大學習愛好者:(C#防止回溯辦法心得)文章只能為提供參考,不一定能成為您想要的結果。以下是C#防止回溯辦法心得正文
本文實例講述了C#防止回溯辦法,分享給年夜家供年夜家參考之用。詳細剖析以下:
起首,回溯法是弗成控的,有時刻會超越我們料想以外發生不妙的成果,最多見的也就是內存洩露。。
回溯辦法是很輕易想到,又不輕易想到的,常常,我們思想更輕易進入的是回溯法。然則回溯法有著它的弊病,異常顯著的弊病是感化域內發生的變量和援用在回溯法挪用未完成時,不克不及釋放(關於年夜部門編纂器來講,消除有著優化才能的編纂器)。假如我們在某一辦法中應用極多的回溯挪用,在辦法中不克不及實時的對辦法感化域內的變量和援用釋放,終究會形成內存缺乏和cpu的盤算負荷增年夜(內存機制中可以將多余的數據轉存到虛擬內存、硬盤,這個就不說了)。應用棧(隊)式的輪回,可以隨意馬虎防止回溯法,並且棧(隊)式的數據再應用以後可以很便利的拋出移除。某些時刻就是如許,一個小小的修改,可讓一個法式在某種特定的情況中妙手回春。(之前做過一個數獨運算器的算法,後來的優化改良就是為了不回溯)
示例代碼以下:
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.IO;
namespace 防止回溯辦法
{
class Program
{
static void Main(string[] args)
{
string path = AppDomain.CurrentDomain.BaseDirectory;
List<string> fileList1 = new List<string>();
FunctionHuishuo(path, ref fileList1);
List<string> fileList2 = new List<string>();
FunctionQueue(path, ref fileList2);
List<string> fileList3 = new List<string>();
FunctionStack(path, ref fileList3);
}
/// <summary>
/// 回溯法
/// </summary>
/// <param name="path"></param>
/// <param name="fileList"></param>
private static void FunctionHuishuo(string path, ref List<string> fileList)
{
if (true)
{
string[] files = null;
try
{
files = Directory.GetFiles(path);
}
catch { }
if (files != null && files.Length > 0)
{
fileList.AddRange(files);
}
}
if (true)
{
string[] folders = null;
try
{
folders = Directory.GetDirectories(path);
}
catch { }
if (folders != null && folders.Length > 0)
{
foreach (string folder in folders)
{
FunctionHuishuo(folder, ref fileList);
}
}
}
}
/// <summary>
/// 客棧法
/// </summary>
/// <param name="path"></param>
private static void FunctionStack(string path, ref List<string> fileList)
{
Stack<string> stack = new Stack<string>();
stack.Push(path);
while (stack.Count > 0)
{
string dir = stack.Pop();
string[] files = null;
try
{
files = Directory.GetFiles(dir);
}
catch { }
if (files != null && files.Length > 0)
{
fileList.AddRange(files);
}
string[] folders = null;
try
{
folders = Directory.GetDirectories(dir);
}
catch { }
if (folders != null && folders.Length > 0)
{
foreach (string folder in folders)
{
stack.Push(folder);
}
}
}
}
/// <summary>
/// 隊列法
/// </summary>
/// <param name="path"></param>
private static void FunctionQueue(string path, ref List<string> fileList)
{
Queue<string> queue = new Queue<string>();
queue.Enqueue(path);
while (queue.Count > 0)
{
string dir = queue.Dequeue();
string[] files = null;
try
{
files = Directory.GetFiles(dir);
}
catch { }
if (files != null && files.Length > 0)
{
fileList.AddRange(files);
}
string[] folders = null;
try
{
folders = Directory.GetDirectories(dir);
}
catch { }
if (folders != null && folders.Length > 0)
{
foreach (string folder in folders)
{
queue.Enqueue(folder);
}
}
}
}
}
}
請細心比較下三種輪回構造的寫法,特殊留意下外面有效到 if(true){...} ,這類方法在某些編纂情況中可以發生異常美好的後果。
信任本文所述對年夜家C#法式設計的進修有必定的自創價值。
��@Override)時,JVM就是一個用戶,它在字節碼層面任務。到這裡,運用開辟人員還不克不及掌握也不克不及應用自界說的注解。是以,我們講授一下若何編寫自界說的Annotations。我們來逐一講述編寫自界說Annotations的要點。下面的例子中,你看到一些注解運用在注解上。
J2SE5.0版本在 java.lang.annotation供給了四種元注解,專門注解其他的注解:
@Documented–一個簡略的Annotations標志注解,表現能否將注解信息添加在java文檔中。
@Retention– 界說該注解的性命周期。
RetentionPolicy.SOURCE – 在編譯階段拋棄。這些注解在編譯停止以後就不再有任何意義,所以它們不會寫入字節碼。@Override, @SuppressWarnings都屬於這類注解。
RetentionPolicy.CLASS – 在類加載的時刻拋棄。在字節碼文件的處置中有效。注解默許應用這類方法。
RetentionPolicy.RUNTIME– 一直不會拋棄,運轉期也保存該注解,是以可使用反射機制讀取該注解的信息。我們自界說的注解平日應用這類方法。
@Target – 表現該注解用於甚麼處所。假如不明白指出,該注解可以放在任何處所。以下是一些可用的參數。須要解釋的是:屬性的注解是兼容的,假如你想給7個屬性都添加注解,僅僅消除一個屬性,那末你須要在界說target包括一切的屬性。
@Inherited – 界說該正文和子類的關系
那末,注解的外部究竟是若何界說的呢?Annotations只支撐根本類型、String及列舉類型。正文中一切的屬性被界說成辦法,並許可供給默許值。
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
@interface Todo {
public enum Priority {LOW, MEDIUM, HIGH}
public enum Status {STARTED, NOT_STARTED}
String author() default "Yash";
Priority priority() default Priority.LOW;
Status status() default Status.NOT_STARTED;
}
上面的例子演示了若何應用下面的注解。
@Todo(priority = Todo.Priority.MEDIUM, author = "Yashwant", status = Todo.Status.STARTED)
public void incompleteMethod1() {
//Some business logic is written
//But it's not complete yet
}
假如注解中只要一個屬性,可以直接定名為“value”,應用時無需再標明屬性名。
@interface Author{
String value();
}
@Author("Yashwant")
public void someMethod() {
}
但今朝為止一切看起來都還不錯。我們界說了本身的注解並將其運用在營業邏輯的辦法上。如今我們須要寫一個用戶法式挪用我們的注解。這裡我們須要應用反射機制。假如你熟習反射代碼,就會曉得反射可以供給類名、辦法和實例變量對象。一切這些對象都有getAnnotation()這個辦法用來前往注解信息。我們須要把這個對象轉換為我們自界說的正文(應用 instanceOf()檢討以後),同時也能夠挪用自界說正文外面的辦法。看看以下的實例代碼,應用了下面的注解:
Class businessLogicClass = BusinessLogic.class;
for(Method method : businessLogicClass.getMethods()) {
Todo todoAnnotation = (Todo)method.getAnnotation(Todo.class);
if(todoAnnotation != null) {
System.out.println(" Method Name : " + method.getName());
System.out.println(" Author : " + todoAnnotation.author());
System.out.println(" Priority : " + todoAnnotation.priority());
System.out.println(" Status : " + todoAnnotation.status());
}
}
注解用例
注解的功效很壯大,Spring和Hebernate這些框架在日記和有用性中年夜量應用了注解功效。注解可以運用在應用標志接口的處所。分歧的是標志接口用來界說完全的類,但你可認為單個的辦法界說正文,例如能否將一個辦法裸露為辦事。
在最新的servlet3.0中引入了許多新的注解,特別是和servlet平安相干的注解。
HandlesTypes –該注解用來表現一組傳遞給ServletContainerInitializer的運用類。
HttpConstraint – 該注解代表一切HTTP辦法的運用要求的平安束縛,和ServletSecurity正文中界說的HttpMethodConstraint平安束縛分歧。
HttpMethodConstraint – 指明分歧類型要求的平安束縛,和ServletSecurity 注解中描寫HTTP協定辦法類型的正文分歧。
MultipartConfig –該注解標注在Servlet下面,表現該Servlet願望處置的要求的 MIME 類型是 multipart/form-data。
ServletSecurity 該注解標注在Servlet繼續類下面,強迫該HTTP協定要求遵守平安束縛。
WebFilter – 該注解用來聲明一個Server過濾器;
WebInitParam – 該注解用來聲明Servlet或是過濾器的中的初始化參數,平日合營 @WebServlet 或許 @WebFilter 應用。
WebListener –該注解為Web運用法式高低文中分歧類型的事宜聲明監聽器。
WebServlet –該注解用來聲明一個Servlet的設置裝備擺設。
ADF (運用法式框架)和注解
如今我們開端評論辯論文章的最初一部門了。運用法式框架,被稱為ADF,由Oracle開辟用來創立Oracle融會運用。我們曾經懂得了注解的優缺陷,也曉得若何編寫自界說的注解,但我們應當將注解運用在ADF的哪部門呢?ADF能否供給了一些樸實的注解?很好的成績,確切在ADF中年夜量應用注解有一些限制。之條件到的運用框架如Spring和Hibernate應用AOP(面向正面的法式設計)。在AOP中,框架供給了一種機制,在事宜的預處置和後續處置中注入代碼。例如:你有一個鉤子用來在辦法履行之前和以後添加代碼,所以你可以在這些處所編寫你的用戶代碼。ADF不應用AOP。假如我們有任何注解的用例可用,我們能夠須要經由過程繼續的方法完成。
願望你愛好這篇文章,贊助年夜家更好的懂得注解的意義!