Давайте разберемся с наследованием в #TypeScript
В реальном мире очень часто говорят, что «Сотрудник — это человек», и это центр нашего урока по пониманию наследования в мире #TypeScript.
Я мог бы привести пример «Собака — это животное», но это не так сильно влияет на нас эмоционально и кажется чем-то роботизированным.
Контекст
В мире компьютерного программирования, особенно для объектно-ориентированного программирования, мы говорим о наследовании. Наследование делает наши программы эволюционными. Правильно спроектированное приложение должно иметь интерфейсы и классы, а из них должно развиваться большее количество классов. Давайте возьмем пример некоторого ERP-приложения, где мы уверены, что будет сущность Сотрудник, и они могут быть, скажем, Руководителем или Менеджером.
Продолжение
Я посоветовал вам прочитать несколько глав о TypeScript в моем предыдущем посте, и если вы следили за ним, вы могли заметить, что наше обсуждение продолжалось до Классов в TypeScript. В этом примере ниже я хотел бы продолжить наше обучение, понимая наследование.
Итак, как может выглядеть класс Employee
и вот как вы создадите объект для менеджера
Это выглядит хорошо, но ответьте на несколько вопросов
- Сможете ли вы идентифицировать себя с объектом, если он содержит менеджера или исполнителя, пока вы не просмотрите свойства объекта?
- Можете ли вы защитить этот объект от нежелательного изменения данных (кто-то меняет значение Назначения с Менеджера на Руководителя)?
Что, если я немного усовершенствую этот код.
Замечательно! Наша система содержит определение сотрудника, но всякий раз, когда создается экземпляр, мы вынуждены говорить, что этот сотрудник является менеджером. (мы можем создать отдельное определение для исполнителя аналогичным образом)
Подождите, может быть другой объект Подрядчик, у которого может быть не Назначение в нашей организационной модели, а Роль. Можете представить, как будет выглядеть наша модель сущности в этом сценарии? Посмотрим
На данный момент мы достигли наименьшей сущности, из которой все может развиваться, а другие классы могут наследоваться.
Сотрудник — это человек, даже подрядчик — это человек
Поскольку приведенное выше утверждение имеет смысл в программировании приложения, я предполагаю, что оно также может иметь социальное влияние. Но не будем терять фокус. Когда мы разрабатываем приложение (независимо от объектно-ориентированного языка), мы пытаемся оценить наименьшую сущность, которая может участвовать в определении других сущностей в системе.
Я очень кратко рассмотрел другие подобные концепции TypeScript, кроме наследования, в своей серии руководств, которые можно найти здесь. Оставляйте свои отзывы об этом или любом другом посте в моем блоге. Я буду очень рад общаться со всеми вами.
Приятного чтения… хорошего дня!
Ссылка на мою запись в блоге:
