У меня есть опыт работы с C, и я новичок в C ++. У меня основной вопрос по дизайну. У меня есть класс (я назову его "повар", потому что проблема, с которой я столкнулся, очень похожа на эту, как с точки зрения сложности, так и с точки зрения проблем), который в основном работает следующим образом
class chef
{
public:
void prep();
void cook();
void plate();
private:
char name;
char dish_responsible_for;
int shift_working;
etc...
}
в псевдокоде это реализуется следующим образом:
int main{
chef my_chef;
kitchen_class kitchen;
for (day=0; day < 365; day++)
{
kitchen.opens();
....
my_chef.prep();
my_chef.cook();
my_chef.plate();
....
kitchen.closes();
}
}
Класс шеф-повара здесь кажется классом монстров и может им стать. chef также, похоже, нарушает принцип единой ответственности, поэтому вместо этого у нас должно быть что-то вроде:
class employee
{
protected:
char name;
int shift_working;
}
class kitchen_worker : employee
{
protected:
dish_responsible_for;
}
class cook_food : kitchen_worker
{
public:
void cook();
etc...
}
class prep_food : kitchen_worker
{
public:
void prep();
etc...
}
и
class plater : kitchen_worker
{
public:
void plate();
}
и т.д...
По общему признанию, я все еще борюсь с тем, как реализовать это во время выполнения, так что, если, например, блюдо (или «шеф-повар в его качестве блюдца») решит пойти домой в середине обеда, то шеф-повар должен работать в новую смену. .
Кажется, это связано с более широким вопросом, который у меня есть: если один и тот же человек неизменно занимается приготовлением, приготовлением и сервировкой блюд в этом примере, каково реальное практическое преимущество наличия этой иерархии классов для моделирования того, что делает один шеф-повар? Я предполагаю, что это наталкивается на «боязнь добавления классов», но в то же время, прямо сейчас или в обозримом будущем я не думаю, что поддержание класса повара в целом ужасно обременительно. Я также думаю, что наивному читателю кода проще увидеть три разных метода в объекте chef и двигаться дальше.
Я понимаю, что это может грозить стать громоздким, когда / если мы добавим такие методы, как «cut_onions ()», «cut_carrots ()» и т. Д., Возможно, каждый со своими собственными данными, но кажется, что с ними можно справиться, сделав функция Prep (), скажем, более модульная. Более того, похоже, что SRP, доведенная до своего логического завершения, создаст класс "onion_cutters", "carrot_cutters" и т.д. один и тот же сотрудник режет лук и морковь, что помогает поддерживать одинаковую переменную состояния в разных методах (например, если сотрудник режет палец, режущий лук, он больше не имеет права резать морковь), тогда как в классе шеф-повара объекта-монстра кажется, что все, о чем позаботятся.
Конечно, я понимаю, что тогда речь идет не столько о содержательном «объектно-ориентированном дизайне», но мне кажется, что если мы должны иметь отдельные объекты для каждой из задач шеф-повара (что кажется неестественным, учитывая, что один и тот же человек является выполняет все три функции), то это, кажется, ставит во главу угла разработку программного обеспечения над концептуальной моделью. Я считаю, что объектно-ориентированный дизайн здесь полезен, если мы хотим иметь, скажем, "meat_chef", "sous_chef", "three_star_chef", которые, вероятно, представляют собой разные люди. Более того, проблема времени выполнения связана с накладными расходами, связанными со сложностью, при строгом применении принципа единой ответственности, который должен обеспечить изменение базовых данных, составляющих сотрудника базового класса, и что это изменение отражены в последующих временных шагах.
Поэтому у меня возникает соблазн оставить все как есть. Если бы кто-нибудь мог прояснить, почему это было бы плохой идеей (и если у вас есть предложения о том, как лучше всего действовать), я был бы очень признателен.
