Case StudyII: Software Engineering with Abstract Classes and Abstract MethodsConcrete Classes

IfCircle, Square and Triangle objects all have drawnmethods, itsreasonable to expect that calling draw on a Circle will display aCircle, calling draw on a Square will display a Square and callingdraw on a Triangle will display a Triangle. Objects of each classknow all the details of the specific shapes to draw. Classes that provide (orinherit) implementations of every method they define and that can be usedto create objects are called concreteclasses

.Abstract ClassesNow, lets consider class TwoDimensionalShapein the Shape hierarchys second level. If we were to create aTwoDimensionalShape object and call its draw method, classTwoDimensionalShape knows that all two-dimensional shapes aredrawable, but it does not know what specific two-dimensional shape todrawthere are many! So,it does not make sense forTwoDimensionalShape to fully implement a draw method. Amethod that is defined in a given class, but for which you cannot providean implementation is called an abstract method. Any class with an abstractmethod has a holethe incomplete method implementationand iscalled an abstract class.

TypeErrors occur when you try to createobjects of abstract classes. In the Shape hierarchy, classes Shape,TwoDimensionalShape and ThreeDimensionalShape all areabstract classes. They all know that shapes should be drawable, but do notknow what specific shape to draw. Abstract base classes are too general tocreate real objects.Inheriting a Common DesignAn abstract classs purpose is to providea base class from which subclasses can inherit a common design, such as aspecific set of attributes and methods. So, such classes often are calledabstract base classes. In the Shape hierarchy, subclasses inherit from theabstract base class Shape the notion of what it means to be a Shapethat is, common properties, such as location and color, and commonbehaviors, such as draw, move and resize.Polymorphic Cost of a PatientSystemNow, lets develop anPatientclass hierarchy that begins with an abstract class, then usepolymorphism to perform costcalculations for objects of two concretesubclasses. Consider the following problem statement:1.A patientpays tothehealthcare institutionweekly. The patientsare of twotypes: i) Regular patientspaya fixed weekly paymentregardless of the number of hours passedin the healthcare institution. Instantpatientspayby the hour and in addition to anovertime pay (1.5 times their hourlypaymentrate) for all hours passedin excess of 40 hoursin a week. Thehealthcare institutionwants to implement an app that performs its incomecalculations polymorphically.

PatientHierarchy Class DiagramThe following diagram showsthe Patienthierarchy. Abstract class Patientrepresents thegeneral concept of apatient. Subclasses RegularPatientandInstantPatientinherit from Patient. PatientRegular PatientInstant Patient

Abstract Base Class PatientThe Python Standard Librarys abc(abstract base class) module helps you define abstract classes by inheritingfrom the modules ABC class. Your abstract base class Patientclassshould declare the methods and properties that all patients should have.Each patient, regardless of the way his or her paymentsare calculated,has a first name, a last name and a Social Security number. Also, everypatientshould have paymentmethod, but the specific calculationdepends on the patients type, so youllmake paymentsan abstractmethod that the subclasses must override. Your Patientclass shouldcontain:i.An __init__ method that initializes the first name, last nameand Social Security number data attributes.ii.Read-only properties for the first name, last name and SocialSecurity number data attributes.iii.An abstract method paymentpreceded by the abc modules@abstractmethod decorator. Concrete subclasses mustimplement this method.

The Python documentation says youshould raise a NotImplementedError in abstract methods.iv.A __repr__ method that returns a string containing the firstname, last name and Social Security number of the patient.Concrete Subclass RegularPatientThis Patientsubclassshould override paymentsto return a RegularPatients weeklypayment. The class also should include:i.An __init__ method that initializes the first name, last name,Social Security number and weekly salary data attributes. Thefirst three of these should be initialized by calling base classPatients __init__ method.ii.A read-write weekly_paymentpropertyin which the setterensures that the property is always non-negative.iii.A __repr__ method that returns a string starting with'RegularPatient:' and followed by all the informationabout a RegularPatient. This overridden method shouldcall Patients version.Concrete Subclass InstantPatientThis Patientsubclassshould override paymentsto return an InstantPatients payments,based on the hours passedand paymentper hour. The class also shouldinclude:i.An __init__ method to initialize the first name, last name,Social Security number, hours and paymentdata attributes. The firstname, last name and Social Security number should be initializedby calling base class Patients __init__ method.ii.Read-write hours and paymentproperties in which the settersensure that the hours are in range (0168) and paymentper hour isalways non-negative.iii.A __repr__ method that returns a string starting withInstantPatient:' and followed by all the informationabout a InstantPatient. This overridden method should callPatients version.Testing Your ClassesIn an IPython session, test your hierarchy:1.Import the classes Patient, RegularPatientandInstantPatient.2.Attempt to create aPatientobject to see the TypeErrorthat occurs and prove that you cannot create an object of anabstract class.3.Assign objects of the concrete classes RegularPatientand InstantPatientto variables, then display eachpatients string representation and payments.4.Place the objects into a list, then iterate through the list andpolymorphically process each object, displaying its stringrepresentation and payments.