Url小写替换工具
--------- 开发过程随笔系列之一项目简介:
集团产品部在进行SEO的过程中,发现搜索引擎对大小写不同的相同Url认为是不同链接,所以提出建议:将url进行统一. 因为项目较多,手动替换比较费时,所以做了简单的小工具,可以批量进行替换。
开发周期:2天
源代码位置:
$root/J架构项目/研发类/2008/ Url小写批量替换 在此工具的开发过程中,遇到一些问题,有几处值得拿出来跟大家讨论一下的场景,因此整理了一下,感兴趣的可以跟帖讨论。
简单的代码重用:
此工具需要两个基本功能:备份,小写替换。因此开始时直接定义了两个方法 Backup(string dir)和LowercaseLink(string dir),开发完成后,查看了一下代码,发现一个问题: 即文件夹遍历,这两个方法都对文件夹进行了一次遍历,其代码是重复的(.Net虽好,但并不万能,例如文件夹的复制就没有实现。需要自己来开发。)。因此我在想有什么方法能够将遍历的代码只写一遍,后来发现Backup,LowercaseLink这两个方法参数和返回值相同,因此想到了委托(好东西呀,我也不是很懂),代码如下: public delegate void HandleMethod(string filepath);
public void Backup(string fileName)
{ //此处省略若干字
}
public void LowercaseLink(string filepath)
{ //此处省略若干字
}
public void Traversal(string dirName,HandleMethod method)
{
string[] subDirs = Directory.GetDirectories(dirName);
foreach (string subDir in subDirs)
{ Traversal(subDir, method);
} string[] files = Directory.GetFiles(dirName); foreach (string file in files)
{ method.Invoke(file);
}
} 调用如下: Traversal(selectedFolder, Backup); Traversal(selectedFolder, LowercaseLink); Traversal的第二个参数为委托类型(相当于函数指针),调用时需要将实际的方法名传递过去,然后通过Invoke来触发。 在.Net3.5 Linq语言和对列表的排序方法中,可以见到很多委托的影子。感兴趣的可以看下。
业务处理和表现层分离:
在第一版完成后,基本功能已经实现,能实现将文本中的所有链接的批量替换。此时所有的代码都放在了Form1.cs文件中,只是通过不同的方法和属性来区分。大致代码如下: public bool IsBackup;
public delegate void HandleMethod(string filepath);
public List<string> linkPatterns = new List<string>();
public string selectedFolder = string.Empty;
private void btnStart_Click(object sender, EventArgs e){}
private void btnSelectFolder_Click(object sender, EventArgs e){}
//方法代码
public void Backup(string fileName){}
public void Traversal(string dirName,HandleMethod method){} public void InitPattern(){} public void LowercaseLink(string filepath){} 在对代码进行了一些考虑以后,发现下面的四个方法和上面的两个方法是不同的。上面是界面代码的事件响应(属于表现层),下面的才是真正的业务处理(属于业务处理层)。后来又添加一次操作状态和信息的响应,此时仍然堆积在 Form1 中,代码体积开始变得庞大和混乱。 因此对代码进行了分离。 分离后代码如下: public class LowercaseManager public ProjectStatus DoTask(LowercaseManagerStartupInfo startInfo){} public bool CheckBackup(string folder){}; public void TraversalBackup(string dirName, LowercaseManagerStartupInfo startInfo){}; public void Traversal(string dirName, HandleMethod method){}; public void LowercaseLink(string filepath){} public class LowercaseManagerStartupInfo public bool IsBackup; public string BackupFolder; public string ProjectFolder;public enum ProjectStatus
{ NoProject, ProjectFolderNotExist, NeedBackupFolder,
Success
} public partial class Form1 : Form
public const string NEED_BACKUPFLODER = "请选择备份文件夹";
public const string MSG_TITLE = "提示";
public const string NEED_PROJECT = "请选择要替换的项目文件夹";
public const string PROJECT_FOLDER_NOT_EXIST = "项目文件夹不存在";
public const string SUCCESS = "替换成功"; private void btnStart_Click(object sender, EventArgs e) private void btnSelectFolder_Click(object sender, EventArgs e) private void btnBackup_Click(object sender, EventArgs e) private void cbIsBackup_CheckedChanged(object sender, EventArgs e) 这还有一个意外,刚开始时,并没有想到使用LowercaseManagerStartupInfo这个参数类,而是将参数放到了LowercaseManager里面,后来想到调用线程类时Thread,Process等类都将入口参数变为了类xxxxStartInfo,因此这里简单的模仿了一下,连名字都抄了过来((∩_∩)) 在进行拆分时,有一个想法:在面向过程的开发中,是以函数作为开发单元;而在面向对象的开发中,是以类作为开发单元的。
扩展与可配置化
截止此时,代码已经开发完毕。下午再次浏览代码时,突然想到,如果要实现将匹配的字符串替换为大写或者替换为其他要求(首字母大写,统一替换为xxx等),这时应该怎么做。
最开始的想法是直接在public void LowercaseLink(string filepath)方法中添加 switch来实现。代码可能如下:
foreach (string pattern in linkPatterns)
{
MatchCollection urls = Regex.Matches(fileContent, pattern);
foreach (Match url in urls)
{
switch(replaceType)
{
case "lower":
fileBuilder.Replace(url.Value, url.Value.ToLower());
break;
case "upper":
fileBuilder.Replace(url.Value, url.Value.ToUpper());
break;
...
}
}
} 但是这样的设计感觉并不是很好,同时不利于配置,扩展起来也不是特别严谨和清晰。忘了哪位大人物曾经说过:“当你看到switch分支过多的时候,可以想想策略,命令等模式”。 呵呵,策略模式来敲门了(那些大人物如果看到实现的并不是策略模式的话,别敲我头就好了)。 于是实现如下:
public interface IReplace
{
string ToDest(string src);
}
public class ReplaceFactory
{
public static IReplace lower = new LowerReplace(); public static IReplace CreateInstance()
{
//配置return (IReplace)Assembly.Load(path).CreateInstance(className);
return lower;
}
} public class LowerReplace : IReplace { // } public class UpperReplace : IReplace { // } 注意红色那行代码,当我们需要替换为不同的目的字符时,那么创建不同类的示例即可(path,className从配置文件加载)。如果没有你要的类,则需要继承 IReplace接口,建立自己的类。 这样便可规范类,方便管理和扩展,同时实现了可配置化 此时就会遇到一个问题:原来我们的类叫做:LowercaseManager和LowercaseManagerStartupInfo,只是为替换小写使用,现在可替换为不同的目标字符串,所以需要来类名已经不太合适。此时对类名进行了更改:ReplaceManager和ReplaceManagerStartupInfo 在配置方面新增加了一个类ConfigHelper.cs辅助读取配置文件。
设想(以下出现的代码暂时没写,只是预想) 至此,算是做了一些代码重码。在我把工具交给王泊、应龙进行简单的测试时,出现了一些问题: 1. 有些文件不需要进行过滤,例如扩展名为exe,dll等 2. 类似<a href="<%# Eval(Container, "Url")%>" > 类似的并没有考虑。 3. 原来的正则表达式区分了大小写。 因此对程序进行简单的更改。 针对问题1 ,直接在代码里进行了扩展名的判断。 public List<string> exts;
exts = new List<string>();
exts.Add(".cs");
exts.Add(".html"); …
if (exts.Contains(Path.GetExtension(filepath).ToLower())) //对指定文件进行替换
{ …}
但是如果做成一个简单过滤器似乎是更好的选择 , 代码可能如下:public interface IFilter
{
string DoFilter(string input);
} public class FileFilter : IFilter 针对问题2: 偷了个懒,直接将代码放到了LowerReplace里面,对包含eval,bind等关键字的情况进行了判断,包含此关键字的则不进行替换. 实际上不进行替换也是替换的一种,也可以做成类,叫做NoReplace,实现可能如下: public class NoReplace : IReplace 这样连同我们已经实现的替换类,现在已经有很多了: public class NoReplace : IReplace public class UpperReplace : IReplace public class LowerReplace : IReplace 以后可能更多。这时就会出现一个问题,在使用ReplaceFactory.CreateInstance()进行Replace实例创建时,到底要创建哪个类。配置文件只能解决单一类的情况,但是现在要根据字符串包含的某些字符或者其他特征判断后,动态的进行创建。 当然可以在Factory类型里面进行判断,也可以建立单独类 public class ReplaceRouter / ReplaceMap 将其路由到正确的Replace类。
(此处可能需要探讨,大家注意。) 针对问题3: 这个很好解决,忽略大小写即可。 现在我们可以做个简单的设想,如果要做成通用的字符串替换工具,在现有的基础上应该如何扩展?这个问题大家可以讨论下。 一路走来,就会发现,其实设计和架构并不是一开始就能确定的,而是随着问题的不断深入,设计的不断迭代而逐步成型的。这需要时间,精力和经验,更需要不断的自我否定,对代码艺术的不断追求,否则所谓的重构,设计只能是空谈。
(转载公司的一位架构师的,目的在于促使自己养成写开发随笔的好习惯)