Please write in python

Concrete Classes-If Circle, Square and Triangle objects all have drawn methods, it's reasonable to expect that calling draw on a Circle will display a Circle, calling draw on a Square will display a Square and calling draw on a Triangle will display a Triangle. objects of each class know all the details of the specific shapes to draw. Classes that provide (or inherit) implementations of every method they define and that can be used to create objects are called concrete casses. Abstract Classes-Now, let's consider class TwoDimensionalshape in the Shape hierarchy's second level. If we were to create a. TwoDimensionalshape object and call its draw method, class TwoDimensionalshape knows that all two-dimensional shapes are drawable, but it does not know what specific two-dimensional shape to draw-there are manyl 5o, it does not make sense for TwoDimensionalshape to fully implement a draw method. A method that is defined in a given class, but for which you cannot provide an implementation is called an abstract method. Any class with an abstract method has a "hole" - the incomplete method implementation-and is called an abstract class. TypeErrors occur when you try to create objects of abstract classes. In the Shape hierarchy, classes Shape, TwoDimensionalshape and ThreeDimensionalshape all are abstract classes. They all know that shapes should be drawable, but do not know what specific shape to draw. Abstract base classes are too general to create real objects. Inheriting a Common Design-An abstract class's purpose is to provide a base class from which subclasses can inherit a common design, such as a specific set of attritutes and methods. So, such classes often are called abstract base classes. In the Shape hierarchy, subclasses inherit from the abstract base class shape the notion of what it means to be a Shape - that is, common properties, such as location and color, and common behaviors, such as draw, move and resize. Polymorphic Cost of a Patient System -Now, let's develop an Patient class hierarchy that begins with an abstract class, then use polymorphism to perform cost calculations for objects of two concrete subclasses. Consider the following problem statement: 1. A patient pays to the healthcare institution weekly. The patients are of two types: i) Regular patients pay a fixed weeky payment regardless of the number of hours passed in the healthcare institution. Instant patients pay by the hour and in addition to an overtime pay (1.5 times their hourly payment rate) for all hours passed in excess of 40 hours in a week. The healthcare institution wants to implement an app that performs its income calculations polymorphically. Patient Hierarchy Class Dagram-The following diagram shows the Patient hierarchy. Abstract ciass Fatient represents the general concept of a patient. Subclasses Regularpatient and instantPatient inherit from Patient. Abstract Base Class Patient-The Python Standard Lbrary/s abc (abstract base class) module helps you define abstract classes by inheriting from the module's ABC class. Your abstract base class Patient class should declare the methods and properties that all patients should have. Each patient, regardless of the way his or her payments are calculated, has a first name, a last name and a Social Security number. Also, every patientshould have payment method, but the specific calculation depends on the patient's type, so you'll make payments an abstract method that the subclasses must overnide. Your Patient class should contain: 1. An _init__method that initializes the first name, last name and Social Security number data attributes. ii. Read-only properties for the first name, last name and Social Security number data attributes. iii. An abstract method payment preceded by the abe module's gabstractmethod decorator. Concrete subclasses must implement this method. The Python documentation says you should raise a NotimplementedError in abstract methods. IV. A repr__ method that returns a string containing the first name, last name and Social Security number of the patient. Concrete Subclass RegularPatient-This Patient subclass should override payments to return a RegularPatient's weekly payment. The class also should include: 1. An _ init__ method that initializes the first name, last name, Social Securfy number and weekly salary data attributes. The first three of these should be initialized by calling base class Patient's _ init__method. ii. A read-write weekly payment property in which the setter ensures that the property is always non-negative. iii. A _repr_ method that returns a string starting with' Regularpatient:' and followed by all the information about a RegularPatient. This overridden method should call Patient's version. Concrete Subclass InstantPatient-This Patient subclass should override payments to return an InstantPatient's payments, based on the hours passed and payment per hour. The class also should include: 1. An _ init__method to initialize the first name, last name, Social Security number; hours and payment data attributes. The first name, last name and Social Security number should be initialized by calling base class Patient's _ init _ method. ii. Read-write hours and payment properties in which the setters ensure that the hours are in range (0168) and payment per hour is always non-negative. i. A repr__method that returns a string starting with instantPatient:' and followed by all the information about a InstantPatient. This overridden method should call Patient's version. Testing Your Classes - in an IPython session, test your hierarchy: 1. Import the classes Patient, Regularpatient and instantPatient. 2. Attempt to create a Patient object to see the TypeError that occurs and prove that you cannot create an object of an abstract class. 3. Assign objects of the concrete classes Regularpatient and instantPatient to variables, then display each patient's string representation and paryments. 4. Place the objects into a list, then iterate through the list and polymorphically process each object, displaying its string representation and payments