Case Study II: Software Engineering with Abstract Classes and Abstract Methods 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 classes. 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 many! So, 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 attributes 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 weekly 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 Diagram-The following diagram shows the Patient hierarchy. Abstract class Patient represents the general concept of a patient. Subclasses RegularPatient and InstantPatient Abstract Base Class Patient -The Python Standard Library'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 override. Your Patient class should contain: i. 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 abc module's @abstractmethod 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: i. An _init_ method that initializes the first name, last name, Social Security 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: i. 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. iii. 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 payments. 4. Place the objects into a list, then iterate through the list and polymorphically process each object, displaying its string representation and payments