Недавно у меня возник достаточно простой вопрос, ответ на которые я для себя пока так и не нашел, посему решил обратиться на форум винград. Итак, у меня есть форма, в которой представлено несколько текстовых поле и кнопка. По нажатию на кнопку "Добавить" данные из текстовых полей заносятся в таблицу. При этом логика добавления данных вынесена в отдельный метод Add, вызываемый при нажатии на кнопку. Метод очень простой:



После того как я это написал у меня возник следующий вопрос: имеет ли смысл выделить этот метод в отдельный класс? Например, чтобы вместо текстовых полей использовать в его коде простые текстовые переменные (хотя это можно и так сделать, просто добавив параметры в метод, а текстовые поля присваивать им в его вызове). Т.е. имеет ли смысл создавать класс ради этого одного метода или же его стоит оставить в теле класса-формы? 

Предлагаю сравнить два кода:


и

А теперь предлагаю немного изменить логику добавления, например, введя ещё одно поле 

Ну и я бы сдеал метод Add с параметрами, в которые передавал бы f_nametextBox.Text, l_nametextBox.Text и всё, что мне ещё понадобится.

1000000dollars:

Так метод Add как раз есть уже. Все как вы показали работает в первом примере. Просто я думаю насчет того, стоит ли этот метод Add вынести за класс-форму в отдельный класс. Что-то вроде класса, который будет отвечать только за добавление в базу данных. Например, если мы захотим поменять интерфейс нашей программы с Windows Forms на WPF будет удобно, что логика добавления находится отдельно от формы, которая нам больше не нужна. С другой стороны делать класс с одним методом странно...

Т.е. грубо говоря сейчас есть файл с классом-формой, в котором есть метод Add. А я думаю вынести этот метод в отдельный класс. И может даже в отдельный файл .cs для удобства.

Darkmaster, 1kdollars как бы намекает, что если ты захочешь этот метод повесить на другие события, то не копировать же его. Соответственно нужно абстрагироваться - разделить логику и представление. Подумать над структурой классов более глобально. 
Возможно имеет смысл сделать класс-диспетчер, методы которого будут дергаться из разных событий формы.

Darkmaster, ага, теперь понял в чём вопрос.

Прежде чем отвеать на него напомню определение одного из основных механизмов ООП - инкапсуляции. Как утверждает википедия, "Инкапсуля́ция — свойство языка программирования, позволяющее объединить и защитить данные и код в объект и скрыть реализацию объекта от пользователя (прикладного программиста)."
Ключевым моментом в этом механизме является объединение данных и кода, который их обрабатывает, в единую сущность - объект.

Из этого следуют такие ответы:

Да, потому что метод Add обрабатывает данные хранилища (сохраняет в нём информацию).


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


Не странно, если этот класс является частью архитектуры.

Теперь, если позволите, расскажу как я вижу предложенный кусок кода в архитектурном смысле.
Есть класс, представляющий базу данных (какое-то абстрактное хранилище, которое )
C_DataBase
{
public: 
 void Add (String firstname, String lastname, DateTime hiredate, DateTime termdate,  String phone);
 /// наверняка ещё какие-то методы, которые вне контекста задачи писать не могу
}

Есть форма, которая позволяет получить от пользователя ввод.
C_Form
{
 private:
 C_DataBase db;

 public:
 void ButtonClick()
  {
    db.Add(f_nametextBox.Text, l_nametextBox.Text, StrToDateTime(HireDateTextBox.Text), StrToDateTime(TermDatetextBox.Text));
  }
}

Хранилище и интерфейс пользователя получаются слабо связаны - получен желаемый результат. 

Как вариант подобные функции можно убирать в отдельный cpp файл. Тем самым можно логически отделить и дать удобную возможность использовать её повторно. Дополнительным бонусом получаем сокрытие реализации данной функции за .h  файлом.
PS В данном, конкретном, случае может быть логичней создать класс с более широкими возможностями