I’m setting up a data validator that will iterate through the rows of a spreadsheet, and for each column, perform a validation check. I was thinking that this might be an appropriate task for the Strategy Pattern as follows:
interface IValidator:
public function isValid(rng as range) as boolean
end function
implementation validator_Number:
'checks whether or not value is a number
implements IValidator
public function IValidator_isValid(rng as range) as boolean
IValidator_isValid=isnumeric(rng.value)
end function
implementation validator_Capitalized:
'checks whether all letters are capitalized in value
implements IValidator
public function IValidator_isValid(rng as range) as boolean
IValidator_isValid=isnumeric(rng.value) and (ucase(rng.value)=rng.value)
end function
validation checker:
'iterates through worksheet cells, validating them and
public sub validationChecker()
dim headerRow as long
dim validator as IValidator
headerRow=1
for row=2 to maxRow
for column=1 to maxColumn
'check the column header name and instantiate
'validator using the appropriate implementation
select case sheet.cells(headerRow,column).value
case "NAME"
set validator=new validator_Capitalized
case "AGE"
set validator=new validator_Number
'etc.
end select
if validator.isValid(sheet.cells(row,column)) then
doSomething()
endif
next
next
I previously asked another question about using Strategy to validate Excel data, and the response was that I didn’t need to do that because there were only a few types of tests and so the rules could be held in a data store. But here there are going to be many different kinds of validation tests, some of which have several lines of code. Is the Strategy implementation that I outlined above the most appropriate pattern to use here?
1
isValid() could be a method implemented in a Strategy pattern. IMO, the benefit of the pattern is future modifiability. That is, there will be a future need for new implementations of isValid() and you don’t want to change your code that iterates and validates. In the definition of Strategy, that’s the Context class.
Your select block, which I believe would be in the Context class, isn’t flexible the way you proposed it, mainly because it “knows” the concrete implementations:
select case sheet.cells(headerRow,column).value
case "NAME"
set validator=new validator_Capitalized
case "AGE"
set validator=new validator_Number
'etc.
end select
To make Strategy work the way you want, you probably need a Simple Factory that encapsulates the new XXX. So, instead of a select/case, you just do:
set validator = Factory.create(sheet.cells(headerRow,column).value)
which effectively calls a create method with the argument “NAME”, “AGE”, etc. which will return the appropriate validator. The create() encapsulates the select/case logic.
The benefit of this is that you can add new validators without having to change the code in Context. Of course, you do have to update the Factory.create() method (essentially the new case for a new validator) and write a new IValidator implementation.
Here’s an updated diagram:
The factory class as well as the separate implementation classes are a lot of extra code which IMO won’t “pay off” if you only have two validators and a single Context. If you plan on adding lots of validators and really want the flexibility of keeping the details hidden from Context (which may appear in several places), then go for it!
If you aren’t “feeling pain” from repetition in maintaining code, then probably you don’t need a pattern.