我有5个Perl文件,它们是我环境中5种不同状态的验证脚本。
每个人都至少有几个子程序。
到目前为止,州的数量限制在5个,这些工作正常。但是现在,根据当前的设计,我有20个以上的环境状态,因此还有20个Perl脚本。
我想将所有五个脚本移动到一个脚本中,该脚本将状态作为参数,并为5种不同的状态提供5个不同的子程序。
这样,当我需要为另一个状态添加验证时,我只需要定义一个新的子例程而不是一个全新的Perl脚本。
问题在于它将意味着使用嵌套子例程(known to run into issues),或者自己展开子例程。
例如,
原始剧本
$ cat verify1.pl
sub a1 {
...
}
sub b1 {
...
}
a1(); b1(); a1();
$ cat verify2.pl
sub a2 {
...
}
sub b2 {
...
}
sub c2 {
...
}
a2(); b2(); c2(); a2();
$
合并脚本
$ cat verify.pl
sub one {
...
}
sub two {
...
}
my ($arg) = @ARGV;
if ($arg == 1) {
one(); # should do what verify1.pl did
}
elsif ($arg == 2) {
two(); # should do what verify2.pl did
}
$
我该怎么做才能解决这个问题?
答案 0 :(得分:6)
sub one {
do 'verify1.pl';
}
sub two {
do 'verify2.pl';
}
然而,从长远来看,最好将脚本转换为模块,以便以现代和理智的方式管理复杂性。
答案 1 :(得分:2)
您可以按照应有的方式正常放置子程序。
sub a1 {
...
}
sub b1 {
...
}
sub a2 {
...
}
sub b2 {
...
}
sub c2 {
...
}
sub one {
a1(); b1(); a1();
}
sub two {
a2(); b2(); c2(); a2();
}
my ($arg) = @ARGV;
if ($arg == 1) {
one(); # should do what verify1.pl did
}
elsif ($arg == 2) {
two(); # should do what verify2.pl did
}
答案 2 :(得分:1)
我只需将所有子程序放在一个文件中并重命名任何冲突即可解决此问题。
然而,听起来您的问题是您正在为可能遇到的每种可能的验证情况进行硬编码。更好的方法是提出一个可以动态构建验证管道的过程。由于我不知道您需要什么,我不知道Data::Constraint或其他验证模块是否适合您。在问题中提供的信息很少,提供任何有用的建议是非常困难的。