the charge was successful we examine that return value to decide whether to assess feeand in turn we return that value to the caller of methodso that the new version of charge has similar outward interface as the original the process month method is new behaviorso there is no inherited version upon which to rely in our modelthis method should be invoked by the bankonce each monthto add new interest charges to the customer' balance the most challenging aspect in implementing this method is making sure we have working knowledge of how an annual percentage rate translates to monthly rate we do not simply divide the annual rate by twelve to get monthly rate (that would be too predatoryas it would result in higher apr than advertisedthe correct computation is to take the twelfth-root of self aprand use that as multiplicative factor for exampleif the apr is (representing %)we compute and therefore charge interest per month in this wayeach $ of debt will amass $ of compounded interest in year protected members our predatorycreditcard subclass directly accesses the data member self balancewhich was established by the parent creditcard class the underscored nameby conventionsuggests that this is nonpublic memberso we might ask if it is okay that we access it in this fashion while general users of the class should not be doing soour subclass has somewhat privileged relationship with the superclass several object-oriented languages ( javac++draw distinction for nonpublic membersallowing declarations of protected or private access modes members that are declared as protected are accessible to subclassesbut not to the general publicwhile members that are declared as private are not accessible to either in this respectwe are using balance as if it were protected (but not privatepython does not support formal access controlbut names beginning with single underscore are conventionally akin to protectedwhile names beginning with double underscore (other than special methodsare akin to private in choosing to use protected datawe have created dependency in that our predatorycreditcard class might be compromised if the author of the creditcard class were to change the internal design note that we could have relied upon the public get balancemethod to retrieve the current balance within the process month method but the current design of the creditcard class does not afford an effective way for subclass to change the balanceother than by direct manipulation of the data member it may be tempting to use charge to add fees or interest to the balance howeverthat method does not allow the balance to go above the customer' credit limiteven though bank would presumably let interest compound beyond the credit limitif warranted if we were to redesign the original creditcard classwe might add nonpublic methodset balancethat could be used by subclasses to affect change without directly accessing the data member balance