Фреймворк для валидации данных в iOS приложениях

[rule]

Почему вот эти два класса тоже не являются наследниками VLDRegExpValidator?:
VLDBoundaryNumberValidator
VLDBoundaryCharactersValidator

Для того чтобы решить эту проблему, не перегружая код обработкой методов делегатов UITextFieldDelegate и UITextViewDelegate, были созданы классы VLDTextField и VLDTextView, которые не позволят ввести в поле символов больше, чем требуется.

То-есть вы подменили стандартный эппловский шаблон делегирования, на наследование и считаете это хорошо? В Cocoa мире делегирование более предпочтительный подход, нежели наследование по ряду причин. В вашем случае точно лучше делегирование.
Я вижу только одну причину наследования — это не позволять вводить символы — если не проходит валидацию ввод.

[Streetmage]

Попробую ответить на возникшие вопросы:

1. Чтобы создать свой валидатор наследник от VLDRegExpValidator необходимо переопределить статический метод + (NSString *)regExpPattern. Как правило полей с разным количеством символов может быть много, поэтому создавать класс наследник под каждый случай не является хорошей идеей. Аналогичная ситуация и с валидацией числа. Допустим есть три отдельных поля с днем-месяцем-годом, то с текущей архитектурой создавать придется 3 класса наследника от VLDRegExpValidator, которые будут содержать лимиты чисел для дня-месяца-года.

Тут сразу напрашивается вопрос о том, почему была выбрана именно такая архитектура, с переопределением статического метода. Почему нельзя было просто создать свойство, которое бы могло принять строку-паттерн? Есть случаи, когда разработчик называет объект, в нашем случае валидатор, одним именем с одним паттерном, а потом меняет регулярное выражение и начинает использовать валидатор в других целях. В данном случае такую неоднозначность было решено устранить описанным способом. Наиболее часто встречаемые ситуации, для проверки которых, как правило, используется регулярное выражение, были реализованы в классах потомках VLDRegExpValidator

2. Первая причина, почему наследование было выбрано как инструмент расширения функциональности текстовых полей ввода, это удобство для разработчика в плане подключения фреймворка. То есть все сводится к замене названия класса и делегата и объявления правил проверки.

Второй целью является интеграция созданных валидаторов с полями ввода.

Третьей целью создания кастомных полей было ограничение вводимых символов. Как правило, если такое ограничение вводится на проекте согласно ТЗ, то разработчик реализует метод делегата — (BOOL)textField:(UITextField *)textField shouldChangeCharactersInRange:(NSRange)range replacementString:(NSString *)string. Чтобы избежать избыточного кода в контроллерах было решено перенести логику в класс наследник от текстового поля.

Четвертой целью для использования наследования является то, что делегаты UITextFieldDelegate и UITextViewDelegate срабатывают только на действия пользователя. Но есть случаи, когда используется форма с автозаполнением полей. Таким образом в поле нельзя присвоить программно больше символов, чем разрешено.