здраствуйте. прошу помощи с логикой организации программы.
прошу не пинать сильно. Очень много букв.

вообщем, ситуация такая.

есть n-е количество записей например в базе, у всех записей примерно одинаковая структура полей,
и к ним применюятся одинаковые по смыслу действия.
но, в зависимости от типа записи, действия различаются по реализации.

также в зависимости от типа записи, некоторые действия требуют обязательного заполнения полей,
а некоторые поля отпускаются.
Поля имеют разный тип.
обьясню подробней на абстрактном примере:

имя:должность:возраст:телефон:город:зарплата:почта:знает ли Фотошоп

для всех имя, должность,город возраст — обязательны.

для инженера:
обязательны параметры зарплата, почта.
сайт, фотошоп — опционально.

для дизайнера:
почта, фотошоп обязательны, зарплата — опционально

для курьера
зарплата: опционально, почта обязательно,
фотошоп: параметр отсутствует.

коля:дизайнер:25:2135476:Москва:500:k@m.ru:да
вася:инженер:25:1234567:Москва:1000:v@m.ru:нет
дима:курьер:20:1234567:Москва:400:d@m.ru:

действие:написать письмо
перед этим нужно проверить, все ли поля заполнены, и вернуть незаполненные поля, причем, имена полей
и хотелось бы это делать автоматически, не делая обработчик для каждого свойства.

количество типов в дальненейшем будет увеличиваться, а количество полей будет больше 50.

скажу сразу, с классами я раньше не сталкивался, потому все то что ниже, может быть неверно...

я предположил, что лучше все вынести в класс.
шаблон класса профессий

TProf=class(TObject)

public
  property name:string read GetName write SetName;
    ...    
  property photoshop:boolean read GetPS write SetPs;
    ...        
  function Send:Boolean;virtual;    
каждая профессия наследует класс proff
TIng=class(TProf)
      
...
  
   function Send:Boolean;override;
...

далее делается класс контроллер, как я его назвал

TContr=class(Tobject)

  constuctor Create(typeProf:Byte);            
  data:TProf;
..
constructor TContr.Create(typeProf:Byte);
...
  case typeProfof
    1:
      Data:=TIng.Create;

с этим более-не менее я разобрался, а как проверить заполнены ли нужные property, и узнать необходимые для каждого класса, чтобы, например сгенерить форму для заполнения,
вообщем, как организовать всю эту логику по правильному?

не заводить же

MyString=record;
  enabled:Boolean;    
  sure:Boolean;
  optional:Boolean;
  Value:String;

к тому же поля могут быть разных типов....

Очень жду советов, еще раз прошу не пинайте сильно...

Здравствуйте, good07, Вы писали:

G>здраствуйте. прошу помощи с логикой организации программы.
G>прошу не пинать сильно. Очень много букв.

G>вообщем, ситуация такая.

G>есть n-е количество записей например в базе, у всех записей примерно одинаковая структура полей,
G>и к ним применюятся одинаковые по смыслу действия.
G>но, в зависимости от типа записи, действия различаются по реализации.

G>также в зависимости от типа записи, некоторые действия требуют обязательного заполнения полей,
G>а некоторые поля отпускаются.
G>Поля имеют разный тип.
G>обьясню подробней на абстрактном примере:

[...]

G>Очень жду советов, еще раз прошу не пинайте сильно...

— Цель мероприятия (Сдача летней практики?)?
— Задача?

А уже потом:
— Нахрена классы?
— Что они будут делать?
— Нахрена контроллер?

Здравствуйте, good07, Вы писали:

G>имя:должность:возраст:телефон:город:зарплата:почта:знает ли Фотошоп

G>количество типов в дальненейшем будет увеличиваться, а количество полей будет больше 50.

G>я предположил, что лучше все вынести в класс.
G>шаблон класса профессий

В общем на примере БД:
1) Делаем первую таблицу таким образом, чтобы одна запись (строка) содержала все необходимые поля (т.е. покрывала собой все сочетания).
Например PERSONS:
ID integer, /* уникальный идентификатор */
PROFID integer, /* идентификатор профессии */
FIO varchar(100), /* фамилия */
EMAIL varchar(100) /* мыло */
//...... и т.п.
2) Делаем вторую таблицу, которая является справочником "необходимости заполнения".
Что-то вроде:
ID
PROFID — /* идентификатор профессии */
FIELDNAME -/* поле таблицы PERSONS */
REQUIRED — /* требуется для заполнения 0/1, Y/N и т.п.*/

Например берем 2 профессии (для одной нужен email, для другой — нет):

В первой табличке у тебя будет:
12343, 1, Иванов , ivanov@mail.ru
12344, 2, Сидоров, <NULL>

Во второй:
123 , 1, FIO, 1
124 , 1, EMAIL, 1
125 , 2, FIO, 1
126 , 2, EMAIL, 0

На основе этих 2-х таблиц может спокойно строить интерфейс. На основе чего угодно — классов, записей, DataSet и т.п. и т.д...

G> к тому же поля могут быть разных типов....

Не критично, поверь. Можешь дополнительно хранить еще информацию о типе поля. И даже о маппинге полей (например в поле email можешь для каких-то специфичных условий писать что-то другое, чтобы немного сэкономить место)..