 |
Принципы проектирования классов с наследованием
|
|
|
|
Объектно-ориентированное проектирование является самостоятельной темой, которая требует отдельного рассмотрения. Для ее изучения рекомендуется [4]. В этом разделе будет рассмотрено несколько полезных и простых правил, которыми нужно руководствоваться на первом этапе изучения объектно-ориентированного похода к программированию. Эти правила помогут избежать сложностей, возникающих при реализации системы классов, связанных наследованием.
Первое правило уже несколько раз применялось при разработке системы классов Employee, Person и Performer, когда мы использовали высказывание «служащий является индивидуумом и исполнителем контракта» для проверки правильности разделения классов на базовые и производные. По-другому это правило можно сформулировать так: базовый класс по своей семантике должен обобщать производные классы.
Нарушение второго правила привело к тому, что в рассматриваемой системе классов появились атрибуты-дубликаты. Поддерживать согласованные значения, которых бывает сложно, а порой и невозможно. Поэтому при проектировании следует придерживаться следующего правила: в системе классов не должно быть разных атрибутов (даже если они одинаково поименованы и находятся в разных классах), имеющих одинаковую семантику или функционально зависимых атрибутов. Под функционально зависимыми атрибутами подразумеваются атрибуты, значение которых могут быть вычислены на основе значений других атрибутов. Все функционально зависимые атрибуты должны быть заменены на функции члены, которые вычисляют их значения.
Третье и последнее правило требует семантически правильного распределения атрибутов по иерархии классов. Придерживаться этого правила наиболее сложно, так как для распределения атрибутов следует хорошо понимать предметную область, которая моделируется проектируемой системой классов. Это правило тоже нарушено в рассмотренной выше системе классов.
|
|
|
Попытаемся на примере продемонстрировать, как следовало бы рассуждать при распределении атрибутов BaseSalary (базовая зарплата), PercentAdd (процент надбавки за должность), PercentLength (процент за стаж), PercentBonus (премиальные) в системе классов.
Пусть в компании, моделью которой будет проектируемая система классов, существуют следующие принципы вознаграждения служащих.
1. Зарплаты всех служащих рассчитываются как сумма базовой зарплаты, надбавки за должность, набавки за стаж работы в компании и премиальных. Все надбавки и премии выражаются в процентном отношении к базовой зарплате.
2. Базовая зарплата для всех служащих одинакова и служит основой для расчета всех остальных надбавок и премий.
3. Набавка за стаж это процент от суммы базовой зарплаты, которая добавляется к вознаграждению за каждый год работы в компании. Например, если базовая зарплата равна 200 единиц, а процент надбавки за стаж равен 1%, то через сеть лет, надбавка будет составлять 14 единиц. Этот процент является общим для всех служащих компании.
4. Надбавка за должность зависит только от занимаемой должности и рассчитывается, как процент от суммы базовой зарплаты и надбавки за стаж.
5. Премиальные зависят только от личного вклада служащего и начисляются как процент от суммы всех других вознаграждений.
Очевидно, что два атрибута BaseSalary ( базоваязарплата ) PercentLength (процент надбавки за стаж) являются общими для всех служащих компании и, если значения этих атрибутов будут изменяться, то изменится зарплата всех служащих компании. Поэтому целесообразно выделить эти атрибуты в отдельный класс и сделать их статическими. На рис. 3.13 приведен пример такого класса с именем Stimulus. Класс содержит четыре статических метода для установки и считывания закрытых атрибутов, а также защищенный метод, позволяющий рассчитать сумму базовой зарплаты и надбавки.
|
|
|
Рис 3.13.Пример реализации класса Stimulus
Атрибут PercentAdd зависитот занимаемой должности и по всей видимости должен быть отражен в классе Performer. На рис. 3.13 представлен фрагмент файла Performer.h.
Рис 3.14.Пример реализации класса Performer
Обратите внимание, что теперь класс Performer наследует класс Stimulus и здесь установлено ключевое слово virtual перед именем базового класса. Установка virtual гарантирует наличие только одного экземпляра класса Stimulus, в том случае, если класс Performer будет выступать базовым вместе с другими классами, которые, может быть, тоже наследуют Stimulus. Кроме того, в классе Performer присутствует функция-член getSalary, имеющую одинаковую сигнатуру с одноименной функцией класса Stimulus. Для точного определения вызываемой функции следует использовать уточненную нотацию с применением оператора разрешения пространства имен.
Последний атрибут PercentBonus относится к конкретному служащему и очевидно должен располагаться в класса Employee (рис. 3.15). Информация о стаже работы в компании тоже относится к конкретному работнику, поэтому атрибут Stagelength (величина стажа) целесообразно разместить тоже здесь.
Рис 3.15.Пример реализации класса Employee
Окончательно вычислить вознаграждение служащего можно с помощью открытой функции getSalary класса Employee. На рис. 3.16 демострируется программа, использующая объект, системы взаимосвязанных классов для расчета вознаграждения служащего. На рис. 3.17 приведен результат работы этой программы.
Рис 3.16.Пример расчета вознаграждения служащего
Рис 3.17.Результат работы программы, приведенной на рис. 3.16
|
|
|
