Композиция или наследование: как выбрать? / Хабр

В начале…

… не было ни композиции, ни наследования, только код.

И был код неповоротливым, повторяющимся, нераздельным, несчастным, избыточным и измученным.

Основным инструментом для повторного использования кода была копипаста. Процедуры и функции были редкостью, подозрительными новомодными штучками. Вызов процедур был дорогим удовольствием. Части кода, отделенные от основной логики, вызывали недоумение!

Мрачные были времена.

Но вот лучик ООП воссиял над миром… Правда, несколько десятилетий¹ никто этого не замечал. Покуда не появился графический интерфейс², которому, как выяснилось, очень-очень не хватало ООП. Когда нажимаешь на кнопку в окне, что может быть проще, чем отправить кнопке (или ее представителю) сообщение «Нажатие»³ и получить результат?

И вот тут ООП взлетел. Было написано множество⁴ книг, расплодились бесчисленные⁵ статьи. Так что сегодня-то каждый может в объектно-ориентированное программирование, так?

Увы, код (и интернет) говорит, что не так

Самые жаркие споры и наибольшее непонимание, похоже, вызывает выбор между композицией и наследованием, зачастую выраженный мантрой «предпочитайте композицию наследованию». Вот об этом и поговорим.

Когда мантры вредят

В житейском плане «предпочитать композицию наследованию» в целом нормально, хоть я и не любитель мантр. Несмотря на то, что они зачастую и несут зерно истины, слишком легко поддаться соблазну и бездумно следовать лозунгу, не понимая, что за ним скрывается. А это всегда выходит боком.

Желтушные статьи с заголовками вроде «Наследование — зло»⁶ тоже не по мне, особенно если автор пытается обосновать свои набросы, сначала неправильно применяя наследование, а потом делая вывод, что оно во всем виновато. Ну типа «молотки — отстой, потому что ими нельзя завинтить шуруп.»

Начнем с основ.

Определения

Далее в статье я буду понимать под ООП «классический» объектный язык, который поддерживает классы со свойствами, методами и простое (одиночное) наследование. Никаких вам интерфейсов, примесей, аспектов, множественного наследования, делегатов, замыканий, лямбд, — ничего, кроме самых простых вещей:

• Класс: именованная сущность из предметной области, возможно, имеющая предка (суперкласс), определенная как набор полей и методов.
• Поле: именованное свойство с определенным типом, которое может, в частности, ссылаться на другой объект (см. композиция).
• Метод: именованная функция или процедура, с параметрами или без них, реализующая какое-то поведение класса.
• Наследование: класс может унаследовать — использовать по умолчанию — поля и методы своего предка. Наследование транзитивно: класс может наследоваться от другого класса, который наследуется от третьего, и так далее вплоть до базового класса (обычно — Object), возможно, неявного. Наследник может переопределить какие-то методы и поля чтобы изменить поведение по умолчанию.
• Композиция: если поле у нас имеет тип Класс, оно может содержать ссылку на другой объект этого класса, создавая таким образом связь между двумя объектами. Не влезая в дебри различий между простой ассоциацией, агрегированием и композицией, давайте «на пальцах» определим: композиция — это когда один объект предоставляет другому свою функциональность частично или полностью.
• Инкапсуляция: мы обращаемся с объектами как с единой сущностью, а не как с набором отдельных полей и методов, тем самым скрываем и защищаем реализацию класса. Если клиентский код не знает ничего, кроме публичного интерфейса, он не может зависеть от деталей реализации.

Наследование фундаментально

Наследование — это фундаментальное понятие ООП. В языке программирования могут быть объекты и сообщения, но без наследования он не будет объектно-ориентированным (только основанным на объектах, но все еще полиморфным).

… как и композиция

Композиция это тоже фундаментальное свойство, причем любого языка. Даже если язык не поддерживает композицию (что редкость в наши дни), люди все равно будут мыслить категориями частей и компонентов. Без композиции было бы невозможно решить сложные задачи по частям.

(Инкапсуляция тоже вещь фундаментальная, но сейчас речь не о ней)

Так от чего весь сыр-бор?

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

А дело в том, что можно подумать, что одно всегда может заменить другое, или что первое лучше или хуже второго. Разработка ПО — это всегда выбор разумного баланса, компромисс.

С композицией все более-менее просто, мы с ней постоянно сталкиваемся в жизни: у стула есть ножки, стена состоит из кирпичей и цемента и тому подобное. А вот наследование, несмотря на свое простое определение, может все усложнить и запутать, если хорошенько не поразмыслить над тем, как его применять. Наследование это весьма абстрактная штука, о нем можно рассуждать, но так просто его не потрогаешь. Мы, конечно, можем сымитировать наследование, используя композицию, но это, как правило, слишком много возни. Для чего нужна композиция — очевидно: из частей собрать целое. А вот с наследованием сложнее, потому что оно сразу о двух вещах: о смысле и о механике.

Наследование смысловое

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

Наследование механическое

Говоря о наследовании в механическом плане, мы имеем в виду, что наследование берет данные (поля) и поведение (методы) базового класса и позволяет использовать их повторно или же дополнить в наследниках. С точки зрения механики, если потомок унаследует реализацию (код) предка, то неизбежно получит и его интерфейс.

Я уверен, что в недопонимании виновата именно эта двойственная природа наследования⁷ в большинстве ОО-языков. Многие считают, что наследование — это чтобы повторно использовать код, хотя оно не только для этого. Если придавать повторному использованию чрезмерное значение — жди беды в архитектуре. Вот пара примеров.

Как не надо наследовать. Пример 1

class Stack extends ArrayList {
    public void push(Object value) { … }
    public Object pop() { … }
}

Казалось бы, класс Stack, все хорошо. Но посмотрите внимательно на его интерфейс. Что должно быть в классе с именем Stack? Методы push() и pop(), что же еще.

Можно было бы переопределить все нежелательные методы, а некоторые (например, clear()) даже и адаптировать под наши нужды, но не многовато ли работы из-за одной ошибки в дизайне? На самом деле трех: одной смысловой, одной механической и одной комбинированной:

1. Утверждение «Stack это ArrayList» ложно. Stack не является подтипом ArrayList. Задача стека — обеспечить выполнение правила LIFO (последним пришел, первым ушел), которое легко удовлетворяется интерфейсом push/pop, но никак не соблюдается интерфейсом ArrayList.
2. Механически наследование от ArrayList нарушает инкапсуляцию. Клиентскому коду не должно быть известно, что мы решили использовать ArrayList для хранения элементов стека.
3. Ну и наконец, реализуя стек через ArrayList мы смешиваем две разные предметные области: ArrayList — это коллекция с произвольным доступом, а стек — это понятие из мира очередей, со строго ограниченным (а не произвольным) ⁸ доступом.

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

Как не надо наследовать. Пример 2

Частая ошибка при наследовании — это создать модель из предметной области, унаследовав ее от готовой реализации. Вот, скажем, нам надо выделить некоторых наших клиентов (класс Customer) в определенное подмножество. Легко! Наследуемся от ArrayList<Customer>, называем это CustomerGroup и понеслась.

Не тут-то было. Поступив так мы опять спутаем две предметные области. Старайтесь избегать этого:

1. ArrayList<Customer> это уже наследник списка, утилиты типа «коллекция», готовой реализации.
2. CustomerGroup это совсем другая штука — класс из предметной области (домена).
3. Классы из предметной области должны использовать реализации, а не наследовать их.

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

Дело не в одиночном наследовании

Одиночное наследование пока остается самой популярной моделью ООП. Оно неизбежно влечет наследование реализации, которое приводит к сильному зацеплению (coupling — прим. пер.) между классами. Может показаться, что беда в том, что ветка наследования у нас только одна на обе потребности: и смысловую и механическую. Если использовали для одного, то для другого уже нельзя. А раз так, может быть множественное наследование все исправит?

Нет. Отношение наследования не должно пересекать границы между предметными областями: инструментальной (структуры данных, алгоритмы, сети) и прикладной (бизнес-логика). Если CustomerGroup будет наследовать ArrayList<Customer> и одновременно, скажем, DemographicSegment, то две предметные области переплетутся между собой, а «видовая принадлежность» объектов станет неочевидна.

Предпочтительно (по крайней мере, с моей точки зрения) делать так. Наследуемся от имеющихся в языке инструментальных классов по минимуму, ровно настолько, чтобы реализовать «механическую» часть вашей логики. Потом соединяем получившиеся части композицией, но не наследованием. Иными словами:

От инструментов можно наследовать только другие инструменты.

Это очень частая ошибка новичков. Что не удивительно, ведь так просто взять и унаследовать. Редко где встретишь обсуждения, почему именно это неправильно. Еще раз: бизнес-сущности должны пользоваться инструментами, а не быть ими. Мухи (инструменты) — отдельно, котлеты (бизнес-модели) — отдельно.

Так когда же нужно наследование?

Наследуемся как надо

Чаще всего — и при этом с наибольшей отдачей — наследование применяют для описания объектов, незначительно отличающихся друг от друга (в оригинале используется термин «differential programming» — прим. пер.) Например, нам нужна особенная кнопка с небольшими дополнениями. Нормально, наследуемся от существующего класса Кнопка. Потому что наш новый класс, это все еще кнопка, а мы полностью наследуем API класса Кнопка, его поведение и реализацию. Новая функциональность только добавляется к существующему. А вот если в наследнике часть функциональности убирается, это повод задуматься, а нужно ли наследование.

Наследование полезнее всего для группировки сходных сущностей и понятий, определения семейств классов, и вообще для организации терминов и понятий, описывающих предметную область. Зачастую, когда значительная часть предметной логики уже реализована, исходно выбранные иерархии наследования перестают работать. Если всё к тому идет, не бойтесь разобрать и заново сложить эти иерархии⁹ так, чтобы они лучше соответствовали и работали друг с другом.

Композиция или наследование: что выбрать?

В ситуации, когда вроде бы подходит и то и другое, взгляните на дизайн в двух плоскостях:

1. Структура и механическое исполнение бизнес-объектов.
2. Что они обозначают по смыслу и как взаимодействуют.

Пока наследование остается внутри одной плоскости, все нормально. Но если иерархия проходит через две плоскости сразу, это плохой симптом.

Например, у вас есть один объект внутри другого. Внутренний объект реализует значительную часть поведения внешнего. У внешнего объекта куча прокси-методов, которые тупо пробрасывают параметры во внутренний объект и возвращают от него результат. В этом случае посмотрите, а не стоит ли унаследоваться от внутреннего объекта, хотя бы частично.

Разумеется, никакие инструкции не заменят голову на плечах. Когда строишь объектную модель, вообще полезно думать. Но если вам хочется конкретных правил, то пожалуйста.

Наследуем, если:

1. Оба класса из одной предметной области
2. Наследник является корректным подтипом (в терминах LSP — прим. пер.) предка
3. Код предка необходим либо хорошо подходит для наследника
4. Наследник в основном добавляет логику

Иногда все эти условия выполняются одновременно:

• в случае моделирования высокоуровневой логики из предметной области
• при разработке библиотек и расширений для них
• при дифференциальном программировании (автор снова использует термин «differential programming», очевидно, понимая под ним нечто, отличное от DDP — прим. пер.)

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

Надеюсь, эти правила помогут вам понять разницу между двумя подходами.

Приятного кодинга!

Послесловие

Отдельная благодарность сотрудникам ThoughtWorks за их ценный вклад и замечания: Питу Хогсону, Тиму Брауну, Скотту Робинсону, Мартину Фаулеру, Минди Ор, Шону Ньюхэму, Сэму Гибсону и Махендре Кария.

1

Первый официальный ОО-язык, SIMULA 67, появился в 1967 году.

2

Системные и прикладные программисты приняли на вооружение C++ в середине 1980-х, но перед тем, как ООП стал общепринятым, прошел еще десяток лет.

3

Я намеренно упрощаю, не говорю про паб/саб, делегатов и тому подобное, чтобы не раздувать статью.

4

На момент написание этого текста Амазон предлагает 24777 книг по ООП.

5

Поиск в гугле по фразе «объектно-ориентированное программирование» дает 8 млн результатов.

6

Поиск в гугле выдает 37600 результатов по запросу «наследование это зло».

7

Смысл (интерфейс) и механику (исполнение) можно разделить за счет усложнения языка. См. пример из спецификации языка D.

8

С грустью замечу, что в Java Stack унаследован от Vector.

9

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

Переводчик выражает благодарность ООП-чату в Telegram, без которого этот текст не смог бы появиться.

Композиция изображения. Теория и практика

В учебном пособии излагаются основные вопросы, связанные с процессом создания и бытия художественной формы в изобразительном искусстве. Рассматриваются вопросы психофизиологии зрительного восприятия, художественного мышления и творческой практики в живописи и графике, на практических примерах исследуются изобразительные возможности средств художественного выражения, проводится анализ композиционных структур ряда известных произведений искусства. Соответствует актуальным требованиям Федерального государственного образовательного стандарта высшего образования. Издание адресовано студентам художественных вузов и факультетов искусства и всем тем, кто занимается изобразительным искусством.

Укажите параметры рабочей программы

Дисциплина

Композиция

07.00.00 «АРХИТЕКТУРА»54.00.00 «ИЗОБРАЗИТЕЛЬНОЕ И ПРИКЛАДНЫЕ ВИДЫ ИСКУССТВ»09.00.00 «ИНФОРМАТИКА И ВЫЧИСЛИТЕЛЬНАЯ ТЕХНИКА»50.00.00 «ИСКУССТВОЗНАНИЕ»51.00.00 «КУЛЬТУРОВЕДЕНИЕ И СОЦИОКУЛЬТУРНЫЕ ПРОЕКТЫ»53.00.00 «МУЗЫКАЛЬНОЕ ИСКУССТВО»44.00.00 «ОБРАЗОВАНИЕ И ПЕДАГОГИЧЕСКИЕ НАУКИ»43.

Направление подготовки

Сомов, Ю.С. Композиция в технике 1977 — покупайте на Auction.ru по выгодной цене

Сомов, Ю.С.
Композиция в технике
Издательство: М.: Машиностроение; Издание 2-е, перераб. и доп.
Переплет: твердый + суперобложка; 271 страниц; 1977 г.
ISBN: [не указан]; Формат: увеличенный
Язык: русский
Аннотация

Промышленный дизайн. В книге изложены теоретические основы композиции в технике, непосредственно связанные с повышением качества промышленных изделий — станков, приборов, транспортных средств. предметов культурно-бытового назначения.
Книга предназначена для инженеров- конструкторов, технологов и дизайнеров.
Книга прекрасно иллюстрирована.

Важно! В описании к лоту указана примерная стоимость доставки, прошу уточнять стоимость доставки конкретной книги ДО покупки.

Смотрите другие мои лоты

Вопросы, связанные с интересующим Вас лотом задавайте до покупки, в разделе Задать вопрос продавцу!

Покупатель, купивший лот, первым выходит на связь в течение 3 дней и высказывает свои предпочтения по способам оплаты и доставки!

Способы оплаты:
Предоплата, возможен наложенный платеж. НО покупателям с рейтингом 0 (нулевой) только предоплата.
Варианты предоплаты:
— Карта Сбербанк
— ЯндексДеньги, Webmoney, Контакт (+5%)
— Почтовый перевод Почты России (+10%) — наиболее дорогой и затратный по времени вариант оплаты.

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

Доставка — почта, расходы + к цене лота. Указанные здесь расходы на пересылку являются минимальными и могут увеличиваться в зависимости от выбранных Вами опций доставки, тарифной политики Почты России, суммарного веса и расстояния. Приобретая несколько лотов, Вы можете сократить свои расходы на пересылку! Страховка — по желанию, стоимость посылки +4% от объявленной стоимости.

Обратите внимание на другие мои лоты!! Желаю успеха!

Все лоты высылаются в течение недели после получения оплаты или зачисления денег на счет.

Возможно рассмотрение вашей цены

Композиция 355 | LABYKET — доставка цветов в Красноярске 24/7

Инструкция свежести

Каждому человеку хочется, чтобы букет, подаренный близким человеком или приобретенный для украшения интерьера и поднятия настроения, радовал как можно дольше. Но к сожалению, цветы недолговечны, и стоимость букета непропорциональна длительности его жизни. Важно знать, что срезанные цветы — живые и остро реагируют на температурный режим и влажность воздуха. Оптимальная температура для максимальной сохранности срезанных цветов +2…+7 градусов. Каждый сорт имеет свой срок жизни, соответственно, разные компоненты сборного букета имеют разный срок увядания. Если Вы хотите, чтобы букет или композиция радовали максимальное количество времени, Вам помогут наши рекомендации по уходу:

1. Сделайте косой срез стеблей, под углом, примерно, 45 градусов, на 2-3 см острым ножом или секатором. Такой срез значительно увеличит поверхность для адсорбции воды растением.
2. Обновляйте косой срез стеблей при каждой смене воды, которая должна проводится ежедневно, если не используется специальная подкормка для срезанных цветов. Мойте вазу с антибактериальным моющим средством при каждой смене воды.
3. Наполните вазу чистой прохладной водой таким образом, чтобы примерно 1/3 часть стеблей оказалась в воде. Если листья попадают в воду, то их необходимо удалить, т.к. они способствуют загниванию воды, и, соответственно, увяданию цветов. Можно использовать специальную подкормку для срезанных цветов. Не добавляйте в воду сахар или другие вещества, это может привести к размножению бактерий, и порче цветов.
4. Выберете наиболее удачное место для расположения вазы с цветами или композиции. Идеальное место- прохладное, с притоком свежего воздуха, вдали от прямых солнечных лучей, сквозняков, обогревательных приборов, фруктов и овощей.
5. Следите за количеством воды в вазе, многие цветы, например, тюльпаны и пионы, потребляют ее в больших объемах.
6. Подливайте воду в центр цветочной композиции раз в 1-2 дня по мере высыхания флористической губки.
7. При наличии в букете цветов на флористических удлинителях, необходимо подливать воду в колбу, по мере выпивания ее цветком.
8. Не оставлять букет без воды на время, более 15 минут.
9. Не оставлять букеты и композиции в автомобиле с неработающим двигателем на длительное время, в особенности, в жаркое и холодное время года.
10. Не переносить букеты и композиции по улице без утепления при температуре ниже +2 градусов.
11. Декоративные элементы на деревянных удлинителях и короткие ветки зелени в букете не требуют специального ухода и водного питания.

Друзья, если букет завял частично или полностью слишком быстро, убедитесь насколько тщательно Вы соблюдали наши рекомендации.

Мы, команда Labyket тщательно следим за свежестью и качеством наших букетов и хотим, чтобы они радовали Вас как можно дольше!

антикоррозионная композиция на основе высокомолекулярного синтетического полимера и алюминиевой пудры

Алпол (ТУ 2313-014-12288779-99) – антикоррозионная композиция на основе высокомолекулярного синтетического полимера и алюминиевой пудры, одноупаковочная.

Композиции Алпол содержит антикоррозионный пигмент в виде алюминиевой пудры, который повышает барьерные свойства покрытия и срок его службы. Характеризуется высокой атмосферостойкостью. ВАЖНО! Покрытие Алпол не устойчиво в бензине и ряде органических растворителей.
 

Информация о покупке

Продажа за наличный и безналичный расчет. Доставка по Екатеринбургу и РФ.

Для заказа звоните по телефону +7(343)351-78-01 или отправляйте запрос на почту [email protected]

Материал ВСЕГДА в наличии!
 

Акции и скидки

БЕСПЛАТНАЯ доставка от 100 кг
 

Алпол используется как:

• самостоятельное покрытие
• финишное покрытие
• для ремонта старых покрытий

Алпол используется в качестве покрывного слоя по цинкнаполненной композиции Цинол.
 

Преимущества композиции Алпол

• удобство использования – одноупаковочная, полностью готова
• время высыхания – не более 30 мин
• обладает повышенной барьерной защитой
• можно наносить при температуре от -25 ^oC до +40 ^oC

Области применения

• гражданское строительство
• дорожное строительство
• промышленное строительство
• электроэнергетика
   

Фасовка и хранение

Алпол упакован в металлические ведра и банки весом 0. 8, 2.8 и 18 кг.

Тара с композицией не должна подвергаться воздействию атмосферных осадков и прямых солнечных лучей. Допускается кратковременное хранение тары с композицией под прямыми солнечными лучами, но не более 3 ч.
В случае хранения при отрицательных температурах перед нанесением композицию необходимо выдержать в тёплом помещении в течение суток.
Гарантийный срок хранения композиции в герметично закрытой таре (при температуре окружающего воздуха от минус 40 °С до плюс 40 °С) – 24 месяцев с даты изготовления.
 

Технические характеристики

Покрытие

Композиция

► Подробная характеристика, PDF (Скачать)

​► Подготовка поверхности и нанесение, PDF (Скачать)
 

ЕСЛИ У ВАС ЕСТЬ ВОПРОСЫ ПО ЭТОМУ МАТЕРИАЛУ — ПОЗВОНИТЕ ИЛИ НАПИШИТЕ НАМ​

телефон: +7 (343) 351-78-01
e-mail: info@centr-zinc. ru

Новогодняя композиция 27 | LABYKET STUDIO — доставка цветов в Ейске 24/7

Инструкция свежести

Каждому человеку хочется, чтобы букет, подаренный близким человеком или приобретенный для украшения интерьера и поднятия настроения, радовал как можно дольше. Но к сожалению, цветы недолговечны, и стоимость букета непропорциональна длительности его жизни. Важно знать, что срезанные цветы — живые и остро реагируют на температурный режим и влажность воздуха. Оптимальная температура для максимальной сохранности срезанных цветов +2…+7 градусов. Каждый сорт имеет свой срок жизни, соответственно, разные компоненты сборного букета имеют разный срок увядания. Если Вы хотите, чтобы букет или композиция радовали максимальное количество времени, Вам помогут наши рекомендации по уходу:

1. Сделайте косой срез стеблей, под углом, примерно, 45 градусов, на 2-3 см острым ножом или секатором. Такой срез значительно увеличит поверхность для адсорбции воды растением.
2. Обновляйте косой срез стеблей при каждой смене воды, которая должна проводится ежедневно, если не используется специальная подкормка для срезанных цветов. Мойте вазу с антибактериальным моющим средством при каждой смене воды.
3. Наполните вазу чистой прохладной водой таким образом, чтобы примерно 1/3 часть стеблей оказалась в воде. Если листья попадают в воду, то их необходимо удалить, т.к. они способствуют загниванию воды, и, соответственно, увяданию цветов. Можно использовать специальную подкормку для срезанных цветов. Не добавляйте в воду сахар или другие вещества, это может привести к размножению бактерий, и порче цветов.
4. Выберете наиболее удачное место для расположения вазы с цветами или композиции. Идеальное место- прохладное, с притоком свежего воздуха, вдали от прямых солнечных лучей, сквозняков, обогревательных приборов, фруктов и овощей.
5. Следите за количеством воды в вазе, многие цветы, например, тюльпаны и пионы, потребляют ее в больших объемах.
6. Подливайте воду в центр цветочной композиции раз в 1-2 дня по мере высыхания флористической губки.
7. При наличии в букете цветов на флористических удлинителях, необходимо подливать воду в колбу, по мере выпивания ее цветком.
8. Не оставлять букет без воды на время, более 15 минут.
9. Не оставлять букеты и композиции в автомобиле с неработающим двигателем на длительное время, в особенности, в жаркое и холодное время года.
10. Не переносить букеты и композиции по улице без утепления при температуре ниже +2 градусов.
11. Декоративные элементы на деревянных удлинителях и короткие ветки зелени в букете не требуют специального ухода и водного питания.

Друзья, если букет завял частично или полностью слишком быстро, убедитесь насколько тщательно Вы соблюдали наши рекомендации.

Мы, команда Labyket тщательно следим за свежестью и качеством наших букетов и хотим, чтобы они радовали Вас как можно дольше!

ПЛАМКОР-2: акриловая огнезащитная композиция

Одноупаковочная. Цвет — белый.
Допускает всесезонное нанесение.

Защита от воздействия огня металлических конструкций внутри помещений при относительной влажности воздуха не более 80 %. Обеспечивает предел огнестойкости до 120 минут. Используется в качестве огнезащитного слоя в комплексных системах защитных покрытий с антикоррозионными и другими грунтовками.

Основные сферы применения

Промышленное и гражданское строительство.

Огнезащитная эффективность

Огнезащитная эффективность покрытия:
— при приведенной толщине металла 3,4 мм и толщине покрытия 0,8 мм – 45 мин;
— при приведенной толщине металла 5,8 мм и толщине покрытия 1,5 мм – 90 мин;
— при приведенной толщине металла 7,2 мм и толщине покрытия 2,1 мм – 120 мин.

Сертификация

Свидетельство о государственной регистрации
№ RU.66.01.40.015.E.000016.02.14 от 07.02.2014;

Сертификаты соответствия
№ C-RU.ПБ34.В.00937 от 01.06.2012 г.,
№ C-RU.ПБ34.В.01099 от 25.02.2013 г.,
№ C-RU.ПБ34.В.01459 от 18.04.2014 г.,
№ C-RU.ПБ34.В.01733 от 15.05.2015 г.,
№ C-RU.ПБ34.В.01762 от 09.07.2015 г.,
№ C-RU. ПБ34.В.01507 от 19.06.2015 г.,      
№ C-RU.ПБ34.В.01871 от 24.02.2016 г.

Технические характеристики

Покрытие

Композиция

Расход

Теоретический расход на однослойное покрытие толщиной от 400 до 800 мкм составляет 600 — 1200 г/м2.

Подготовка поверхности

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

Все повреждённые участки грунтовочного покрытия должны быть отремонтированы.

Инструкции по применению

Композицию ПЛАМКОР-2 следует наносить на грунтовочное покрытие (ЦИНОТАН, ЦВЭС, ЦИНЭП, ИЗОЛЭП-primer, Виникор-061, ВИНИКОР-экопрайм-01) не ранее чем через 24 часа, на покрытие ГФ-021 – не ранее чем через 7 суток после его нанесения (при температуре (20±2) °С).

Нанесение композиции на невысохшее грунтовочное покрытие (по грунтовке ГФ-021) может привести к растрескиванию огнезащитного покрытия или его оплыванию.

Условия нанесения композиции – при температуре от минус 25 до плюс 40 °С и относительной влажности воздуха не более 80 % (при окраске при пониженной температуре рекомендуется консультация с производителем материала).

При нанесении и эксплуатации покрытия следует устранить воздействие влаги, в том числе, в виде конденсата!

Подготовка композиции к применению:
— перемешать до однородного состояния, используя миксер;
— при необходимости разбавить разбавителем до рабочей вязкости непосредственно перед применением.

Рекомендуемые способы нанесения:

Композицию следует наносить в 2 — 5 слоев в зависимости от требуемой группы огнезащитной эффективности покрытия, приведенной толщины металла и выбранного способа нанесения.

Толщина первого слоя сухого покрытия не должна превышать 200 мкм (толщина мокрого слоя не более 400 мкм). Каждый последующий слой следует наносить стандартной рекомендованной толщиной сухого покрытия (в зависимости от способа нанесения). При значительном превышении рекомендуемой толщины одного слоя возможно появление на сухом покрытии дефектов в виде трещин или кратеров.

Сушка покрытия – естественная, покрытие ремонтопригодно.

Время выдержки покрытия ПЛАМКОР-2 до нанесения последующего слоя композиции и до нанесения покрывных эмалей – не менее 24 ч (при температуре (20±2) °С), при пониженных температурах время межслойной сушки покрытия следует увеличить.

Время полного высыхания покрытия ПЛАМКОР-2 при температуре (20±2) °С — не менее 10 суток (зависит от температуры воздуха, при её повышении сокращается).

Упаковка и хранение

Композиция упакована в жестяные ведра или банки.

Условия хранения – в соответствии с ГОСТ 9980. 5 (в закрытом помещении при температуре воздуха от минус 40 до плюс 40 °С). Композиция должна храниться в герметично закрытой таре изготовителя вдали от источников тепла. Тара с композицией не должна подвергаться воздействию атмосферных осадков и прямых солнечных лучей.

Гарантийный срок хранения композиции в герметично закрытой таре изготовителя – 12 месяцев с даты изготовления.

Меры безопасности

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

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

Композиция относится к пожароопасным материалам.

Совместимость с другими материалами

Рекомендуется наносить по грунтовкам ЦИНОТАН (ТУ 2312-017-12288779), ЦВЭС (ТУ 2312-004-12288779), ЦИНЭП® (ТУ 2312-022-12288779), ИЗОЛЭП-primer (ТУ 2312-067-12288779), ИЗОЛЭП-mastic (ТУ 2312-065-12288779), ВИНИКОР-061 (ТУ 2312-001-54359536), ВИНИКОР-ЭКОПРАЙМ-01 (ТУ 20. 30.12-010-67503963-2017) и ГФ-021. В качестве покрывного слоя могут использоваться эмали: ПОЛИТОН-УР (ТУ 2312-029-12288779), ПОЛИТОН-УР (УФ) (ТУ 2312-03312288779) и ВИНИКОР-62 (ТУ 2312-001-54359536).

Применение композиции в комплексных системах покрытий с грунтовками и покрывными эмалями других производителей — по согласованию с производителем композиции ПЛАМКОР-2.

Предоставленная информация носит общий характер и не учитывает специфику конкретного объекта.

Подробная характеристика продукта.

 Технология нанесения огнезащитной композиции ПЛАМКОР-2.

Заказать продукцию и получить консультацию по вопросам применения огнезащитных материалов Вы можете по телефону +7 (343) 357-30-97 либо отправив On-line запрос.

Узнать цену Вы можете, отправив нам официальный запрос на бланке вашего предприятия — [email protected]

Купить огнезащитные краски ПЛАМКОР можно непосредственно у производителя со склада в Екатеринбурге, в региональных представительствах или у официальных дилеров.

Подробная информация о дилерской сети Научно-производственного холдинга «ВМП» содержится в разделе Контакты.

композиционных словосочетаний | Коллокации предложений по Кембриджскому словарю

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

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

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

Новый интерес к поддержке классической композиции в традиционных «публицистических» жанрах коснулся концертного зала, а также оперного театра.

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

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

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

Это «возвращение к устной речи» нашло свое отражение в перформансе, электронной композиции, сэмплировании и интерактивных звуковых инсталляциях.

Основной элементный состав верхней мантии, оцененный по составу лерцолитов.

Для этого мы нанесли на карту основной элементный состав характерных областей внутри каждого образца.

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

Таким образом, окончательный состав фокус-групп был основан на успешном контакте, готовности и доступности.

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

Они обнаружили, что время воздействия стресса, наряду с генетическим составом, были важны для формирования нейроэндокринной реакции на будущий вызов.

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

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

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

Темп общей композиции — это только отправная точка; он может значительно отличаться в зависимости от контекста.

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

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

Руководство по ООП Python — Настоящий Python

В Python все является объектом. Модули — это объекты, определения классов и функции — это объекты, и, конечно же, объекты, созданные из классов, тоже являются объектами.

Наследование является обязательной функцией каждого объектно-ориентированного языка программирования. Это означает, что Python поддерживает наследование, и, как вы увидите позже, это один из немногих языков, поддерживающих множественное наследование.

Когда вы пишете код Python с использованием классов, вы используете наследование, даже если вы не знаете, что используете его.Давайте посмотрим, что это значит.

Объект Суперкласс

Самый простой способ увидеть наследование в Python — это перейти в интерактивную оболочку Python и написать небольшой фрагмент кода. Вы начнете с написания простейшего из возможных классов:

  >>> класс MyClass:
...     проходить
...
  

Вы объявили класс MyClass , который мало что делает, но он иллюстрирует самые основные концепции наследования. Теперь, когда у вас объявлен класс, вы можете использовать функцию dir () для вывода списка его членов:

  >>> c = MyClass ()
>>> dir (c)
['__class__', '__delattr__', '__dict__', '__dir__', '__doc__', '__eq__',
'__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__',
'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',
'__str__', '__subclasshook__', '__weakref__']
  

dir () возвращает список всех членов в указанном объекте. Вы не указали участников в MyClass , так откуда берется список? Вы можете узнать с помощью интерактивного переводчика:

  >>> o = object ()
>>> dir (o)
['__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__',
'__ge__', '__getattribute__', '__gt__', '__hash__', '__init__',
'__init_subclass__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__',
'__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__',
'__subclasshook__']
  

Как видите, два списка почти идентичны.В MyClass есть несколько дополнительных членов, например __dict__ и __weakref__ , но каждый отдельный член класса объекта также присутствует в MyClass .

Это связано с тем, что каждый класс, который вы создаете в Python, неявно является производным от объекта . Вы могли бы быть более явным и написать class MyClass (object): , но это излишне и ненужно.

Примечание: В Python 2 необходимо явно наследовать от объект по причинам, выходящим за рамки данной статьи, но вы можете прочитать об этом в разделе «Классические классы нового стиля» документации Python 2.

Исключения являются исключением

Каждый класс, который вы создаете в Python, будет неявно производным от объекта . Исключением из этого правила являются классы, используемые для индикации ошибок путем создания исключения.

Вы можете увидеть проблему с помощью интерактивного интерпретатора Python:

  >>> класс MyError:
...     проходить
...
>>> поднять MyError ()

Отслеживание (последний вызов последний):
  Файл "", строка 1, в 
TypeError: исключения должны быть производными от BaseException
  

Вы создали новый класс, чтобы указать тип ошибки.Затем вы попытались использовать его, чтобы вызвать исключение. Возникает исключение, но в выходных данных указано, что исключение имеет тип TypeError , а не MyError , и что все исключения должны быть производными от BaseException .

BaseException — это базовый класс, предоставляемый для всех типов ошибок. Чтобы создать новый тип ошибки, вы должны унаследовать свой класс от BaseException или одного из его производных классов. По соглашению в Python пользовательские типы ошибок выводятся из исключения Exception , которое, в свою очередь, является производным от BaseException .

Правильный способ определить тип ошибки следующий:

  >>> класс MyError (Исключение):
...     проходить
...
>>> поднять MyError ()

Отслеживание (последний вызов последний):
  Файл "", строка 1, в 
__main __. MyError
  

Как видите, когда вы вызываете MyError , в выходных данных правильно указывается тип возникшей ошибки.

Создание иерархии классов

Наследование — это механизм, который вы будете использовать для создания иерархий связанных классов.Эти связанные классы будут иметь общий интерфейс, который будет определен в базовых классах. Производные классы могут специализировать интерфейс, предоставляя конкретную реализацию там, где это применимо.

В этом разделе вы начнете моделировать систему управления персоналом. В этом примере будет продемонстрировано использование наследования и то, как производные классы могут предоставить конкретную реализацию интерфейса базового класса.

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

Вы начинаете с реализации класса PayrollSystem , который обрабатывает расчет заработной платы:

  # В часах в год

класс PayrollSystem:
    def calculate_payroll (самостоятельно, сотрудники):
        print ('Расчет заработной платы')
        print ('===================')
        для сотрудника в составе сотрудников:
            print (f'Payroll for: {employee.id} - {employee.name} ')
            print (f'- Проверить сумму: {employee. calculate_payroll ()} ')
            Распечатать('')
  

Система расчета заработной платы реализует .calculate_payroll () метод, который берет коллекцию сотрудников и печатает их id , имя и проверяет сумму с помощью метода .calculate_payroll () , доступного для каждого объекта сотрудника.

Теперь вы реализуете базовый класс Employee , который обрабатывает общий интерфейс для каждого типа сотрудника:

  # В часах в год

класс Сотрудник:
    def __init __ (я, идентификатор, имя):
        self.id = id
        self.name = имя
  

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

Система HR требует, чтобы каждый обработанный Сотрудник предоставлял интерфейс . calculate_payroll () , который возвращает еженедельную зарплату для сотрудника. Реализация этого интерфейса различается в зависимости от типа Сотрудник .

Например, у административных работников фиксированная зарплата, поэтому каждую неделю они получают одинаковую сумму:

  # В час.ру

class SalaryEmployee (Сотрудник):
    def __init __ (self, id, name, weekly_salary):
        super () .__ init __ (идентификатор, имя)
        self.weekly_salary = weekly_salary

    def calculate_payroll (самостоятельно):
        return self.weekly_salary
  

Вы создаете производный класс SalaryEmployee , который наследует Employee . Класс инициализируется идентификатором id и именем , требуемым базовым классом, и вы используете super () для инициализации членов базового класса.Вы можете прочитать все о super () в Supercharge Your Classes With Python super ().

SalaryEmployee также требуется параметр инициализации weekly_salary , который представляет сумму, которую сотрудник зарабатывает в неделю.

Класс предоставляет требуемый метод .calculate_payroll () , используемый системой HR. Реализация просто возвращает сумму, хранящуюся в weekly_salary .

В компании также работают рабочие, получающие почасовую оплату, поэтому вы добавляете HourlyEmployee в систему управления персоналом:

  # В час.ру

class HourlyEmployee (Сотрудник):
    def __init __ (self, id, name, hours_worked, hour_rate):
        super () .__ init __ (идентификатор, имя)
        self.hours_worked = hours_worked
        self.hour_rate = часовой_рейт

    def calculate_payroll (самостоятельно):
        вернуть self.hours_worked * self.hour_rate
  

Класс HourlyEmployee инициализируется идентификатором id и именем , как и базовый класс, плюс hours_worked и hour_rate , необходимых для расчета заработной платы. Метод .calculate_payroll () реализуется путем возврата количества отработанных часов, умноженного на часовую ставку.

Наконец, в компании работают торговые партнеры, которым выплачивается фиксированная заработная плата плюс комиссионные, основанные на их продажах, поэтому вы создаете класс CommissionEmployee :

  # В часах в год

class CommissionEmployee (SalaryEmployee):
    def __init __ (self, id, name, weekly_salary, Commission):
        super () .__ init __ (идентификатор, имя, недельная_ зарплата)
        себя.комиссия = комиссия

    def calculate_payroll (самостоятельно):
        fixed = super (). calculate_payroll ()
        возврат фиксированный + self.commission
  

Вы выводите CommissionEmployee из SalaryEmployee , потому что оба класса должны учитывать weekly_salary . В то же время CommissionEmployee инициализируется значением комиссии , которое основано на продажах для сотрудника.

.calculate_payroll () использует реализацию базового класса для получения фиксированной зарплаты и добавляет значение комиссии.

Поскольку CommissionEmployee происходит от SalaryEmployee , у вас есть доступ напрямую к свойству weekly_salary , и вы могли бы реализовать .calculate_payroll () , используя значение этого свойства.

Проблема с прямым доступом к свойству заключается в том, что если реализация SalaryEmployee.calculate_payroll () изменится, вам также придется изменить реализацию CommissionEmployee.calculate_payroll () .Лучше полагаться на уже реализованный метод в базовом классе и расширять функциональность по мере необходимости.

Вы создали свою иерархию первого класса для системы. UML-диаграмма классов выглядит так:

На схеме показана иерархия наследования классов. Производные классы реализуют интерфейс IPayrollCalculator , который требуется для системы PayrollSystem . Реализация PayrollSystem.calculate_payroll () требует, чтобы переданные объекты сотрудника содержали id , name и calculate_payroll () .

Интерфейсы представлены аналогично классам со словом interface над именем интерфейса. Имена интерфейсов обычно начинаются с заглавной буквы I .

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

  # В program.py

импортные часы

salary_employee = hr.SalaryEmployee (1, 'Джон Смит', 1500)
hourly_employee = hr.HourlyEmployee (2, 'Джейн Доу', 40, 15)
Commission_employee = hr.CommissionEmployee (3, 'Кевин Бэкон', 1000, 250)
payroll_system = час.Система начисления заработной платы()
payroll_system.calculate_payroll ([
    salary_employee,
    hourly_employee,
    Commission_employee
])
  

Вы можете запустить программу в командной строке и посмотреть результат:

  $ python program. py

Расчет заработной платы
===================
Заработная плата для: 1 - Джон Смит
- Сумма чека: 1500

Зарплата для: 2 - Джейн Доу
- Сумма чека: 600

Зарплата для: 3 - Кевин Бэкон
- Сумма чека: 1250
  

Программа создает три объекта сотрудников, по одному для каждого из производных классов.Затем он создает систему расчета заработной платы и передает список сотрудников своему методу .calculate_payroll () , который рассчитывает заработную плату для каждого сотрудника и распечатывает результаты.

Обратите внимание, что базовый класс Employee не определяет метод .calculate_payroll () . Это означает, что если вы создадите простой объект Employee и передадите его в PayrollSystem , то получите ошибку. Вы можете попробовать это в интерактивном интерпретаторе Python:

  >>> импорт ч.
>>> Сотрудник = час.Сотрудник (1, «Недействительный»)
>>> payroll_system = hr.PayrollSystem ()
>>> payroll_system. calculate_payroll ([сотрудник])

Заработная плата для: 1 - недействительна
Отслеживание (последний вызов последний):
  Файл "", строка 1, в 
  Файл "/hr.py", строка 39, в файле calculate_payroll
    print (f'- Проверить сумму: {employee.calculate_payroll ()} ')
AttributeError: объект "Сотрудник" не имеет атрибута "calculate_payroll"
  

Хотя вы можете создать экземпляр объекта Employee , этот объект не может использоваться системой PayrollSystem .Почему? Потому что не может .calculate_payroll () для Сотрудника . Чтобы соответствовать требованиям PayrollSystem , вам нужно преобразовать класс Employee , который в настоящее время является конкретным классом, в абстрактный класс. Таким образом, ни один сотрудник никогда не будет просто Сотрудником , а будет тот, который реализует .calculate_payroll () .

Абстрактные базовые классы в Python

Класс Employee в приведенном выше примере называется абстрактным базовым классом. Абстрактные базовые классы существуют для наследования, но никогда не создаются. Python предоставляет модуль abc для определения абстрактных базовых классов.

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

Модуль abc в стандартной библиотеке Python предоставляет функциональные возможности для предотвращения создания объектов из абстрактных базовых классов.

Вы можете изменить реализацию класса Employee , чтобы исключить возможность его создания:

  # В часах в год

from abc import ABC, abstractmethod

класс Сотрудник (ABC):
    def __init __ (я, идентификатор, имя):
        self.id = id
        self.name = имя

    @abstractmethod
    def calculate_payroll (самостоятельно):
        проходить
  

Вы наследуете Employee от ABC , что делает его абстрактным базовым классом. Затем вы украшаете .Calcul_payroll () с декоратором @abstractmethod .

У этого изменения есть два хороших побочных эффекта:

1. Вы сообщаете пользователям модуля, что объекты типа Employee создавать нельзя.
2. Вы говорите другим разработчикам, работающим над модулем hr , что если они являются производными от Employee , то они должны переопределить абстрактный метод .calculate_payroll () .

Вы можете видеть, что объекты типа Сотрудник не могут быть созданы с помощью интерактивного интерпретатора:

  >>> импорт ч.
>>> Сотрудник = час.Сотрудник (1, 'аннотация')

Отслеживание (последний вызов последний):
  Файл "", строка 1, в 
TypeError: невозможно создать экземпляр абстрактного класса Employee с абстрактными методами
Calcul_payroll
  

Выходные данные показывают, что нельзя создать экземпляр класса, поскольку он содержит абстрактный метод calculate_payroll () . Производные классы должны переопределять метод, чтобы разрешить создание объектов своего типа.

Наследование реализации и наследование интерфейса

Когда вы производите один класс от другого, производный класс наследует оба:

1. Интерфейс базового класса: Производный класс наследует все методы, свойства и атрибуты базового класса.

2. Реализация базового класса: Производный класс наследует код, реализующий интерфейс класса.

В большинстве случаев вам нужно унаследовать реализацию класса, но вы захотите реализовать несколько интерфейсов, чтобы ваши объекты можно было использовать в разных ситуациях.

Современные языки программирования разработаны с учетом этой базовой концепции. Они позволяют наследовать от одного класса, но вы можете реализовать несколько интерфейсов.

В Python нет необходимости явно объявлять интерфейс. Любой объект, реализующий желаемый интерфейс, может использоваться вместо другого объекта. Это известно как утка, набирающая . Утиный набор текста обычно объясняется так: «Если он ведет себя как утка, значит, это утка».

Чтобы проиллюстрировать это, вы теперь добавите класс DisgruntledEmployee в приведенный выше пример, который не является производным от Employee :

  # В disgruntled.py

класс DisgruntledEmployee:
    def __init __ (я, идентификатор, имя):
        себя.id = id
        self.name = имя

    def calculate_payroll (самостоятельно):
        возврат 1000000
  

Класс DisgruntledEmployee не является производным от Employee , но предоставляет тот же интерфейс, который требуется для PayrollSystem . PayrollSystem.calculate_payroll () требуется список объектов, реализующих следующий интерфейс:

• Свойство или атрибут id , который возвращает идентификатор сотрудника
• name свойство или атрибут, представляющий имя сотрудника
• А .Calcul_payroll () , который не принимает никаких параметров и возвращает сумму заработной платы процессу

Всем этим требованиям удовлетворяет класс DisgruntledEmployee , поэтому PayrollSystem все еще может рассчитывать свою заработную плату.

Вы можете изменить программу, чтобы использовать класс DisgruntledEmployee :

  # В program.py

импортные часы
недовольный импорт

salary_employee = hr.SalaryEmployee (1, 'Джон Смит', 1500)
hourly_employee = час.HourlyEmployee (2, 'Джейн Доу', 40, 15)
Commission_employee = hr.CommissionEmployee (3, 'Кевин Бэкон', 1000, 250)
disgruntled_employee = disgruntled.DisgruntledEmployee (20000, 'Анонимный')
payroll_system = hr.PayrollSystem ()
payroll_system.calculate_payroll ([
    salary_employee,
    hourly_employee,
    Commission_employee,
    disgruntled_employee
])
  

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

  $ python program.py

Расчет заработной платы
===================
Заработная плата для: 1 - Джон Смит
- Сумма чека: 1500

Зарплата для: 2 - Джейн Доу
- Сумма чека: 600

Зарплата для: 3 - Кевин Бэкон
- Сумма чека: 1250

Заработная плата для: 20000 - Аноним
- Сумма чека: 1000000
  

Как видите, PayrollSystem все еще может обрабатывать новый объект, потому что он соответствует желаемому интерфейсу.

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

• Используйте наследование для повторного использования реализации: Производные классы должны использовать большую часть своей реализации базового класса. Они также должны моделировать отношения как . Класс Customer также может иметь id и имя , но Customer не является Employee , поэтому вам не следует использовать наследование.

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

Теперь вы можете очистить приведенный выше пример, чтобы перейти к следующей теме. Вы можете удалить файл disgruntled.py , а затем изменить модуль hr в исходное состояние:

  # В часах в год

класс PayrollSystem:
    def calculate_payroll (самостоятельно, сотрудники):
        print ('Расчет заработной платы')
        print ('===================')
        для сотрудника в составе сотрудников:
            print (f'Payroll for: {employee.id} - {employee.name} ')
            print (f'- Проверить сумму: {сотрудник.Calcul_payroll ()} ')
            Распечатать('')

класс Сотрудник:
    def __init __ (я, идентификатор, имя):
        self.id = id
        self.name = имя

class SalaryEmployee (Сотрудник):
    def __init __ (self, id, name, weekly_salary):
        super () .__ init __ (идентификатор, имя)
        self.weekly_salary = weekly_salary

    def calculate_payroll (самостоятельно):
        return self.weekly_salary

class HourlyEmployee (Сотрудник):
    def __init __ (self, id, name, hours_worked, hour_rate):
        super () .__ init __ (идентификатор, имя)
        себя.hours_worked = hours_worked
        self.hour_rate = часовой_рейт

    def calculate_payroll (самостоятельно):
        вернуть self.hours_worked * self.hour_rate

class CommissionEmployee (SalaryEmployee):
    def __init __ (self, id, name, weekly_salary, Commission):
        super () .__ init __ (идентификатор, имя, недельная_ зарплата)
        self.commission = комиссия

    def calculate_payroll (самостоятельно):
        fixed = super (). calculate_payroll ()
        возврат фиксированный + self.commission
  

Вы удалили импорт модуля abc , поскольку класс Employee не должен быть абстрактным.Вы также удалили из него абстрактный метод calculate_payroll () , поскольку он не предоставляет никакой реализации.

По сути, вы наследуете реализацию атрибутов id и name класса Employee в ваших производных классах. Поскольку .calculate_payroll () — это просто интерфейс для метода PayrollSystem.calculate_payroll () , вам не нужно реализовывать его в базовом классе Employee .

Обратите внимание, как класс CommissionEmployee является производным от SalaryEmployee . Это означает, что CommissionEmployee наследует реализацию и интерфейс SalaryEmployee . Вы можете увидеть, как метод CommissionEmployee.calculate_payroll () использует реализацию базового класса, поскольку он полагается на результат super (). Calculate_payroll () для реализации своей собственной версии.

Проблема взрыва класса

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

Вы начали построение иерархии классов из типов сотрудников , используемых системой PayrollSystem для расчета заработной платы. Теперь вам нужно добавить к этим классам некоторые функции, чтобы их можно было использовать с новой ProductivitySystem .

Система ProductivitySystem отслеживает производительность в зависимости от ролей сотрудников. Существуют разные роли сотрудников:

• Менеджеры: Они ходят и кричат ​​на людей, говорящих им, что делать.Они наемные работники и зарабатывают больше денег.
• Секретарши: Они делают всю бумажную работу для менеджеров и следят за тем, чтобы все счета и платежи были выставлены вовремя. Они тоже наемные работники, но зарабатывают меньше денег.
• Сотрудников отдела продаж: Они много звонят по телефону, чтобы продать товары. У них есть зарплата, но они также получают комиссионные с продаж.
• Заводских рабочих: Производят продукцию для предприятия. Оплата им почасовая.

С этими требованиями вы начинаете видеть, что Employee и его производные классы могут принадлежать не к модулю hr , а где-то еще, потому что теперь они также используются ProductivitySystem .

Вы создаете модуль сотрудников и перемещаете туда классы:

  # В employee.py

класс Сотрудник:
    def __init __ (я, идентификатор, имя):
        self.id = id
        self.name = имя

class SalaryEmployee (Сотрудник):
    def __init __ (self, id, name, weekly_salary):
        супер().__init __ (идентификатор, имя)
        self.weekly_salary = weekly_salary

    def calculate_payroll (самостоятельно):
        return self.weekly_salary

class HourlyEmployee (Сотрудник):
    def __init __ (self, id, name, hours_worked, hour_rate):
        super () .__ init __ (идентификатор, имя)
        self.hours_worked = hours_worked
        self.hour_rate = часовой_рейт

    def calculate_payroll (самостоятельно):
        вернуть self.hours_worked * self.hour_rate

class CommissionEmployee (SalaryEmployee):
    def __init __ (self, id, name, weekly_salary, Commission):
        супер().__init __ (id, name, weekly_salary)
        self.commission = комиссия

    def calculate_payroll (самостоятельно):
        fixed = super (). calculate_payroll ()
        возврат фиксированный + self.commission
  

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

  # В program.py

импортные часы
импортные сотрудники

salary_employee = сотрудники.SalaryEmployee (1, 'Джон Смит', 1500)
hourly_employee = сотрудники.HourlyEmployee (2, 'Джейн Доу', 40, 15)
Commission_employee = employee.CommissionEmployee (3, 'Кевин Бэкон', 1000, 250)
payroll_system = hr.PayrollSystem ()
payroll_system.calculate_payroll ([
    salary_employee,
    hourly_employee,
    Commission_employee
])
  

Вы запускаете программу и проверяете, что она по-прежнему работает:

  $ python program.py

Расчет заработной платы
===================
Заработная плата для: 1 - Джон Смит
- Сумма чека: 1500

Зарплата для: 2 - Джейн Доу
- Сумма чека: 600

Зарплата для: 3 - Кевин Бэкон
- Сумма чека: 1250
  

Когда все готово, вы начинаете добавлять новые классы:

  # У сотрудников.ру

Менеджер класса (SalaryEmployee):
    def работа (самостоятельно, часы):
        print (f '{self.name} кричит и кричит {hours} часов.')

классный секретарь (SalaryEmployee):
    def работа (самостоятельно, часы):
        print (f '{self.name} тратит {hours} часов на оформление офисных документов.')

class SalesPerson (CommissionEmployee):
    def работа (самостоятельно, часы):
        print (f '{self.name} тратит на телефон {hours} часов.')

класс FactoryWorker (HourlyEmployee):
    def работа (самостоятельно, часы):
        print (f '{self.name} производит гаджеты в течение {часов} часов.')
  

Сначала вы добавляете класс Manager , производный от SalaryEmployee . Класс предоставляет метод work () , который будет использоваться системой повышения производительности. Метод занимает часов, отработал сотрудник.

Затем вы добавляете Secret , SalesPerson и FactoryWorker , а затем реализуете интерфейс work () , чтобы их можно было использовать в системе повышения производительности.

Теперь вы можете добавить ProductivitySytem class:

  # По производительности.ру

class ProductivitySystem:
    def track (я, сотрудники, часы):
        print ('Отслеживание производительности сотрудников')
        print ('==============================')
        для сотрудника в составе сотрудников:
            employee.work (часы)
        Распечатать('')
  

Класс отслеживает сотрудников с помощью метода track () , который берет список сотрудников и количество часов для отслеживания. Теперь вы можете добавить в свою программу систему повышения производительности:

  # В program.py

импортные часы
импортные сотрудники
производительность импорта

менеджер = сотрудники.Менеджер (1, 'Мэри Поппинс', 3000)
secretary = сотрудники.Secretary (2, 'Джон Смит', 1500)
sales_guy = сотрудники.SalesPerson (3, 'Кевин Бэкон', 1000, 250)
factory_worker = employee.FactoryWorker (2, 'Джейн Доу', 40, 15)
сотрудники = [
    менеджер,
    секретарь,
    sales_guy,
    рабочий,
]
performance_system = продуктивность.ProductivitySystem ()
performance_system.track (сотрудников, 40)
payroll_system = hr.PayrollSystem ()
payroll_system.calculate_payroll (сотрудники)
  

Программа формирует список сотрудников разного типа.Список сотрудников отправляется в систему продуктивности для отслеживания их работы в течение 40 часов. Затем тот же список сотрудников отправляется в систему расчета заработной платы для расчета их заработной платы.

Вы можете запустить программу, чтобы увидеть результат:

  $ python program.py

Отслеживание производительности сотрудников
==============================
Мэри Поппинс кричит и кричит 40 часов.
Джон Смит тратит 40 часов на оформление офисных документов.
Кевин Бэкон проводит по телефону 40 часов.
Джейн Доу производит гаджеты 40 часов.Расчет заработной платы
===================
Заработная плата для: 1 - Мэри Поппинс
- Сумма чека: 3000

Зарплата для: 2 - Джон Смит
- Сумма чека: 1500

Зарплата для: 3 - Кевин Бэкон
- Сумма чека: 1250

Зарплата для: 4 - Джейн Доу
- Сумма чека: 600
  

Программа показывает сотрудников, работающих по 40 часов, через систему продуктивности. Затем он рассчитывает и отображает платежную ведомость для каждого из сотрудников.

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

На следующей диаграмме показана новая иерархия классов:

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

Наследование нескольких классов

Python — один из немногих современных языков программирования, поддерживающих множественное наследование.Множественное наследование — это возможность одновременно наследовать класс из нескольких базовых классов.

Множественное наследование имеет плохую репутацию, поскольку большинство современных языков программирования не поддерживают его. Вместо этого современные языки программирования поддерживают концепцию интерфейсов. В этих языках вы наследуете от одного базового класса, а затем реализуете несколько интерфейсов, поэтому ваш класс можно повторно использовать в разных ситуациях.

Этот подход накладывает некоторые ограничения на ваши проекты.Вы можете унаследовать реализацию одного класса только путем прямого наследования от него. Вы можете реализовать несколько интерфейсов, но не можете наследовать реализацию нескольких классов.

Это ограничение хорошо подходит для разработки программного обеспечения, поскольку оно заставляет вас разрабатывать классы с меньшим количеством зависимостей друг от друга. Позже в этой статье вы увидите, что с помощью композиции можно использовать несколько реализаций, что делает программное обеспечение более гибким. Однако этот раздел посвящен множественному наследованию, поэтому давайте посмотрим, как оно работает.

Оказывается, иногда нанимают временных секретарей, когда нужно делать слишком много документов. Класс TemporarySecretary выполняет роль секретаря в контексте ProductivitySystem , но для целей расчета заработной платы это HourlyEmployee .

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

1. Унаследовать от Секретарь : Вы можете унаследовать от Секретарь , чтобы унаследовать .work () для роли, а затем переопределите метод .calculate_payroll () , чтобы реализовать его как HourlyEmployee .

2. Производный от HourlyEmployee : Вы можете наследовать от HourlyEmployee , чтобы унаследовать метод .calculate_payroll () , а затем переопределить метод .work () , чтобы реализовать его как Секретарь .

Затем вы помните, что Python поддерживает множественное наследование, поэтому вы решаете унаследовать от секретарь и HourlyEmployee :

  # У сотрудников.ру

class TemporarySecretary (Секретарь, Почасовой сотрудник):
    проходить
  

Python позволяет наследовать два разных класса, указав их в скобках в объявлении класса.

Теперь вы измените свою программу, добавив нового временного секретаря:

  импорт часов
импортные сотрудники
производительность импорта

manager = employee.Manager (1, 'Мэри Поппинс', 3000)
secretary = сотрудники.Secretary (2, 'Джон Смит', 1500)
sales_guy = сотрудники.SalesPerson (3, 'Кевин Бэкон', 1000, 250)
factory_worker = сотрудники.FactoryWorker (4, 'Джейн Доу', 40, 15)
временный_секретари = сотрудники.Темверинсекретарий (5, 'Робин Уильямс', 40, 9)
company_employees = [
    менеджер,
    секретарь,
    sales_guy,
    рабочий,
    временный_секретарь,
]
performance_system = продуктивность.ProductivitySystem ()
performance_system.track (company_employees, 40)
payroll_system = hr.PayrollSystem ()
payroll_system.calculate_payroll (company_employees)
  

Вы запускаете программу для проверки:

  $ программа на Python.ру

Отслеживание (последний вызов последний):
 Файл ". \ Program.py", строка 9, в 
  временный_секретарий = сотрудник.Темверинсекретарий (5, 'Робин Уильямс', 40, 9)
TypeError: __init __ () принимает 4 позиционных аргумента, но было дано 5
  

Вы получаете исключение TypeError , в котором говорится, что позиционные аргументы 4 там, где ожидалось, но были даны 5 .

Это связано с тем, что вы получили TemporarySecretary сначала из Секретарь , а затем из HourlyEmployee , поэтому переводчик пытается использовать Секретарь.__init __ () для инициализации объекта.

Ладно, перевернем:

  класс Временный секретарь (почасовый сотрудник, секретарь):
    проходить
  

Теперь запустите программу еще раз и посмотрите, что произойдет:

  $ python program.py

Отслеживание (последний вызов последний):
 Файл ". \ Program.py", строка 9, в 
  временный_секретарий = сотрудник.Темверинсекретарий (5, 'Робин Уильямс', 40, 9)
 Файл "employee.py", строка 16, в __init__
  super () .__ init __ (идентификатор, имя)
TypeError: __init __ () отсутствует 1 обязательный позиционный аргумент: 'weekly_salary'
  

Теперь кажется, что вам не хватает параметра weekly_salary , который необходим для инициализации Секретарь , но этот параметр не имеет смысла в контексте TemporarySecretary , потому что это HourlyEmployee .

Может быть, реализация TemporarySecretary .__ init __ () поможет:

  # В employee.py

class TemporarySecretary (Почасовой сотрудник, секретарь):
    def __init __ (self, id, name, hours_worked, hour_rate):
        super () .__ init __ (идентификатор, имя, часы работы, скорость_часа)
  

Попробуйте:

  $ python program.py

Отслеживание (последний вызов последний):
 Файл ". \ Program.py", строка 9, в 
  временный_секретарий = сотрудник.Темверинсекретарий (5, 'Робин Уильямс', 40, 9)
 Файл "Сотрудник".py ", строка 54, в __init__
  super () .__ init __ (идентификатор, имя, часы работы, скорость_часа)
 Файл "employee.py", строка 16, в __init__
  super () .__ init __ (идентификатор, имя)
TypeError: __init __ () отсутствует 1 обязательный позиционный аргумент: 'weekly_salary'
  

Это тоже не сработало. Хорошо, пора вам погрузиться в порядок разрешения метода (MRO) Python, чтобы увидеть, что происходит.

Когда осуществляется доступ к методу или атрибуту класса, Python использует класс MRO, чтобы найти его. MRO также используется super () , чтобы определить, какой метод или атрибут вызывать.Вы можете узнать больше о super () в Supercharge Your Classes With Python super ().

Вы можете оценить MRO класса TemporarySecretary с помощью интерактивного интерпретатора:

  >>> из сотрудников ввозят временного секретаря
>>> Временный секретарь .__ mro__

(<класс 'employee.TemporarySecretary'>,
 <класс 'employee.HourlyEmployee'>,
 <класс 'сотрудники. Секретарь'>,
 <класс 'employee.SalaryEmployee'>,
 <класс сотрудников.Сотрудник '>,
 <класс 'объект'>
)
  

  класс Временный секретарь (секретарь, почасовый сотрудник):
    def __init __ (self, id, name, hours_worked, hour_rate):
        HourlyEmployee .__ init __ (self, id, name, hours_worked, hour_rate)
  

  $ python program.py

Отслеживание производительности сотрудников
==============================
Мэри Поппинс кричит и кричит 40 часов.Джон Смит тратит 40 часов на оформление офисных документов.
Кевин Бэкон проводит по телефону 40 часов.
Джейн Доу производит гаджеты 40 часов.
Робин Уильямс тратит 40 часов на оформление офисных документов.

Расчет заработной платы
===================
Заработная плата для: 1 - Мэри Поппинс
- Сумма чека: 3000

Зарплата для: 2 - Джон Смит
- Сумма чека: 1500

Зарплата для: 3 - Кевин Бэкон
- Сумма чека: 1250

Зарплата для: 4 - Джейн Доу
- Сумма чека: 600

Зарплата для: 5 - Робин Уильямс
Отслеживание (последний вызов последний):
  Файл ".\ program.py ", строка 20, в 
    payroll_system.calculate_payroll (сотрудники)
  Файл "hr.py", строка 7, в файле calculate_payroll
    print (f'- Проверить сумму: {employee.calculate_payroll ()} ')
  Файл employee.py, строка 12, в файле calculate_payroll
    return self.weekly_salary
AttributeError: объект TemporarySecretary не имеет атрибута weekly_salary
  

  класс Временный секретарь (секретарь, почасовый сотрудник):
    def __init __ (self, id, name, hours_worked, hour_rate):
        HourlyEmployee .__ init __ (self, id, name, hours_worked, hour_rate)

    def calculate_payroll (самостоятельно):
        return HourlyEmployee.calculate_payroll (self)
  

  $ python program.py

Отслеживание производительности сотрудников
==============================
Мэри Поппинс кричит и кричит 40 часов.
Джон Смит тратит 40 часов на оформление офисных документов.
Кевин Бэкон проводит по телефону 40 часов.
Джейн Доу производит гаджеты 40 часов.
Робин Уильямс тратит 40 часов на оформление офисных документов.

Расчет заработной платы
===================
Заработная плата для: 1 - Мэри Поппинс
- Сумма чека: 3000

Зарплата для: 2 - Джон Смит
- Сумма чека: 1500

Зарплата для: 3 - Кевин Бэкон
- Сумма чека: 1250

Зарплата для: 4 - Джейн Доу
- Сумма чека: 600

Зарплата для: 5 - Робин Уильямс
- Сумма чека: 360
  

  # По производительности.ру

class ProductivitySystem:
    def track (я, сотрудники, часы):
        print ('Отслеживание производительности сотрудников')
        print ('==============================')
        для сотрудника в составе сотрудников:
            result = employee.work (часы)
            print (f '{имя сотрудника}: {результат}')
        Распечатать('')

класс ManagerRole:
    def работа (самостоятельно, часы):
        ответь f'scream и кричит в течение {hours} часов ».

класс Секретарь
    def работа (самостоятельно, часы):
        return f'expends {hours} часов на оформление офисных документов.'

class SalesRole:
    def работа (самостоятельно, часы):
        return f 'тратит {hours} часов на телефон.'

класс FactoryRole:
    def работа (самостоятельно, часы):
        вернуть гаджеты на {hours} часов ».
  

  # В час.ру

класс PayrollSystem:
    def calculate_payroll (самостоятельно, сотрудники):
        print ('Расчет заработной платы')
        print ('===================')
        для сотрудника в составе сотрудников:
            print (f'Payroll for: {employee.id} - {employee.name} ')
            print (f'- Проверить сумму: {employee.calculate_payroll ()} ')
            Распечатать('')

класс SalaryPolicy:
    def __init __ (self, weekly_salary):
        self.weekly_salary = weekly_salary

    def calculate_payroll (самостоятельно):
        return self.weekly_salary

класс HourlyPolicy:
    def __init __ (self, hours_worked, hour_rate):
        себя.hours_worked = hours_worked
        self.hour_rate = часовой_рейт

    def calculate_payroll (самостоятельно):
        вернуть self.hours_worked * self.hour_rate

класс CommissionPolicy (SalaryPolicy):
    def __init __ (self, weekly_salary, Commission):
        super () .__ init __ (недельная_ зарплата)
        self.commission = комиссия

    def calculate_payroll (самостоятельно):
        fixed = super (). calculate_payroll ()
        возврат фиксированный + self.commission
  

  # В employee.py

из часов импорта (
    SalaryPolicy,
    CommissionPolicy,
    Почасовая политика
)
из импорта производительности (
    ManagerRole,
    Секретарь роль,
    SalesRole,
    FactoryRole
)

класс Сотрудник:
    def __init __ (я, идентификатор, имя):
        себя.id = id
        self.name = имя

Менеджер класса (Сотрудник, ManagerRole, SalaryPolicy):
    def __init __ (self, id, name, weekly_salary):
        SalaryPolicy .__ init __ (self, weekly_salary)
        super () .__ init __ (идентификатор, имя)

класс Секретарь (Employee, SecretRole, SalaryPolicy):
    def __init __ (self, id, name, weekly_salary):
        SalaryPolicy .__ init __ (self, weekly_salary)
        super () .__ init __ (идентификатор, имя)

class SalesPerson (Сотрудник, SalesRole, CommissionPolicy):
    def __init __ (self, id, name, weekly_salary, Commission):
        CommissionPolicy.__init __ (самостоятельно, недельная_ зарплата, комиссия)
        super () .__ init __ (идентификатор, имя)

класс FactoryWorker (Сотрудник, FactoryRole, HourlyPolicy):
    def __init __ (self, id, name, hours_worked, hour_rate):
        HourlyPolicy .__ init __ (self, hours_worked, hour_rate)
        super () .__ init __ (идентификатор, имя)

класс TemporarySecretary (Сотрудник, SecretRole, HourlyPolicy):
    def __init __ (self, id, name, hours_worked, hour_rate):
        HourlyPolicy .__ init __ (self, hours_worked, hour_rate)
        super () .__ init __ (идентификатор, имя)
  

  $ python program.py

Отслеживание производительности сотрудников
==============================
Мэри Поппинс: кричит и кричит 40 часов.Джон Смит: тратит 40 часов на оформление офисных документов.
Кевин Бэкон: 40 часов разговаривает по телефону.
Джейн Доу: производит гаджеты 40 часов.
Робин Уильямс: тратит 40 часов на оформление офисных документов.

Расчет заработной платы
===================
Заработная плата для: 1 - Мэри Поппинс
- Сумма чека: 3000

Зарплата для: 2 - Джон Смит
- Сумма чека: 1500

Зарплата для: 3 - Кевин Бэкон
- Сумма чека: 1250

Зарплата для: 4 - Джейн Доу
- Сумма чека: 600

Зарплата для: 5 - Робин Уильямс
- Сумма чека: 360
  

  function FancyBorder (props) {
  возвращаться (
    

      {реквизит.children} 
  );
}  

  function WelcomeDialog () {
  возвращаться (
    
      
 Добро пожаловать 
 
 Спасибо, что посетили наш космический корабль! 
 
  );
}  

  функция SplitPane (реквизиты) {
  возвращаться (
    

      

        {реквизит.left} 
      

        {props.right} 
    
  );
}

function App () {
  возвращаться (
    }
      right = {
        <Чат />} />
  );
}  

  Диалог функции (реквизиты) {
  возвращаться (
    
      

        {реквизит.title} 
      

        {props.message} 
    
  );
}

function WelcomeDialog () {
  возвращаться (
    
);
}  

  Диалог функции (реквизиты) {
  возвращаться (
    
      

        {реквизит.заглавие}
      
      

        {props.message}
      
      {props.children} 
  );
}

class SignUpDialog расширяет React.Component {
  конструктор (реквизит) {
    супер (реквизит);
    this.handleChange = this.handleChange.bind (это);
    this.handleSignUp = this.handleSignUp.bind (это);
    this.state = {логин: ''};
  }

  оказывать() {
    возвращаться (
      

          Зарегистрируйтесь!  
    );
  }

  handleChange (e) {
    this.setState ({логин: e.target.value});
  }

  handleSignUp () {
    alert (`Добро пожаловать на борт, $ {this.state.login}!`);
  }
}  

  класс UnsupportedAction (LookupError):
    проходить

класс Animal (объект):
    _attributes = ()

    def __init __ (я, имя):
        себя.name = имя

    def make_sound (сам):
        print ("тишина ...")

    def __getattr __ (я, имя):
        для att в self._attributes:
            если hasattr (att, name):
                вернуть getattr (att, имя)
        еще:
            поднять UnsupportedAction ("{} не знает, как {}". формат (тип (сам), имя))



класс Dog (Животное):
    _attributes = (Ноги (),)


класс Птица (Животное):
    _attributes = (Ноги (), Крылья ())
  

  класс UnsupportedAction (LookupError):
    проходить

класс Animal (объект):
    _attributes = ()

    def __init __ (я, имя):
        self.name = имя

    def make_sound (сам):
        print ("тишина ...")


    def walk (self):
        return self._resolve_action ("прогулка")

    def fly (self):
        return self._resolve_action ("прогулка")

    # так далее

    def _resolve_action (я, имя):
        для att в себе._attributes:
            если hasattr (att, name):
                вернуть getattr (att, имя)
        еще:
            поднять UnsupportedAction ("{} не знает, как {}". формат (тип (сам), имя))
  

  Класс Действие (объект):
    def __init __ (я, имя):
        себя.name = имя

    def __get __ (self, obj, cls):
        если obj равно None:
            вернуть себя
        вернуть obj._resolve_action (self.name)

    def __set __ (self, obj, value):
        поднять AttributeError ("Атрибут доступен только для чтения")


класс Animal (объект):
    _attributes = ()

    def __init __ (я, имя):
        self.name = имя

    def make_sound (сам):
        print ("тишина ...")

    walk = Действие ("прогулка")
    fly = Действие ("летать")

    # так далее