Как определять новые методы в производных классах?

Question

[Symbi0t]

Приветствую.
Есть следующая задача. Существует список сотрудников двух типов: employee и manager.
Определил для них соответствующие классы:

class Person
{
public:
	virtual void show() = 0;
};

class Employee: public Person
{
public:
	void show()
	{
		std::cout << "Employee" << std::endl;
	}
};

class Manager: public Person
{
public:
	void show()
	{
		std::cout << "Manager" << std::endl;
	}
};

Также, создал фабрику:

class PersonFactory
{
public:
	static Person* create(const std::string &type)
	{
		if (type == "Employee")
			return new Employee();
		if (type == "Manager")
			return new Manager();

		return NULL;
	}
};

Теперь можем создавать объекты динамически необходимого типа:
Person* emp = PersonFactory::create("Manager");

У менеджера есть список подчиненных сотрудников. Соответственно, класс должен содержать метод getListEmployee().
Но если мы добавим его в класс Manager, то придется добавлять и в родительский класс Person.

emp->getListEmployee(); // Будет ошибка, т.к. метод не определен в родительском классе

Но согласно общей концепции, у обычного сотрудника не может быть подчиненных. Значит метод getListEmployee() не нужен родительскому классу Person.
Как быть в таком случае? Как определять новые методы в родительских классах?

Answer 1

[jcmvbkbc]

Но согласно общей концепции, у обычного сотрудника не может быть подчиненных. Значит метод getListEmployee() не нужен родительскому классу Person.

Нужен метод классу или не нужен зависит от его ответственности. Если вы собираетесь использовать Person для работы с сотрудниками любого типа (кстати, плохое название класса, не отражает сути), а у каких-то сотрудников в принципе могут быть подчинённые, то какой-то метод для этого должен присутствовать в Person. Удобство использования этого интерфейса будет зависеть от реализации.

Так, например, можно добавить метод getListEmployee(), возвращающий список подчинённых (кстати, опять плохое название метода, не отражает сути), а реализация этого метода в классе Employee может возвращать пустой список.
Или можно добавить метод getSubordinateEnumerator(), возвращающий интерфейс перечисления подчинённых, а в классе Employee возвращать из этого метода NULL.

Если же вы не собираетесь использовать единый интерфейс Person, а, например, будете пытаться привести Person* к типу Employee* или Manager* с помощью dynamic_cast, то метод в Person не нужен.

Comments

[Symbi0t]

Благодарю за отклик.
Класс Person я планировал использовать как абстрактный, содержащий все самые базовые поля и методы которые по определению должны быть у любого сотрудника. Правильно ли я понял вашу мысль, что класс Person можно использовать как интерфейс, в котором определены методы для сотрудников всех типов, а реализацию делегировать производным классам? Такое архитектурное решение не будет выходить за рамки главных принципов ООП?
Насчет приведения типов есть мнение, что обычно это не очень хорошо и лучше всего пересмотреть архитектурное решение. Потому и не стал прибегать к этому способу.
P.S. Согласен по поводу не самого удачного названия метода getListEmployee(), признаться, его выбрал на скорую руку. А чем не понравилось название класса Person? Любой сотрудник ведь в первую очередь человек, персона, индивид.

[jcmvbkbc]

класс Person можно использовать как интерфейс, в котором определены методы для сотрудников всех типов, а реализацию делегировать производным классам? Такое архитектурное решение не будет выходить за рамки главных принципов ООП?

Да.

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

Не очень хорошо -- это когда знаешь, что есть мнение, но не знаешь, почему оно сформировалось.
Бессистемно приводить типы где попало -- это одно дело, а приводить типы в рамках реализации паттерна visitor -- другое.

А чем не понравилось название класса Person? Любой сотрудник ведь в первую очередь человек, персона, индивид.

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

[Symbi0t]

jcmvbkbc: насчет определения методов для всех сотрудников в абстрактном классе. Подумалось, что возможно это не самый лучший вариант. Получается, что employee будет содержать все методы необходимые только для manager. Это разве не приводит к избыточности? Или это нормальная практика и иерархию классов нужно сделать следующим образом (кстати, Person переименовал в Worker):

class Employee: public Worker {}
class Manager: public Employee {}

Или лучше будет всё же воспользоваться приведением типов и не переносить все методы из класса в класс?

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

Тогда, чтобы не ошибиться назову базовый класс просто Energy ;)

[jcmvbkbc]

Или это нормальная практика и иерархию классов нужно сделать следующим образом... Или лучше будет всё же воспользоваться приведением типов и переносить все методы из класса в класс?

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

Тогда, чтобы не ошибиться назову базовый класс просто Energy ;)

Неправильный вывод. Базовый класс должен быть наиболее специфичным из возможных, но достаточно общим, чтобы охватить функциональность всех предполагаемых наследников.