13: Poly-what-ism in C#

Printing Code-128 in C# 13: Poly-what-ism

Note, however, that no Unified Factoring Theory exists for any given set of classes The relationship in Figure 13-4 seems natural, but suppose that an application cared more about differentiating types of schools that are administered by local politicians from those that aren t This relationship, shown in Figure 13-5, is a more natural fit for that type of problem

Figure 13-5: There s no correct factoring The proper way to break down the classes is partially a function of the problem being solved

As intellectually satisfying as factoring is, it introduces a problem of its own Return one more time to BankAccount, which was introduced at the beginning of the chapter Think for a minute about how you may go about defining the different member functions defined in BankAccount Most BankAccount member functions are no problem because both account types implement them in the same way You should implement those common functions in BankAccount Withdraw() is different, however The rules for withdrawing from a savings account differ from those for withdrawing from a checking account You ll have to implement SavingsAccountWithdraw() differently from CheckingAccountWithdraw() But how are you supposed to implement BankAccountWithdraw() Ask the bank manager for help I imagine the conversation going something like the following: What are the rules for making a withdrawal from an account you ask, expectantly What type of account Savings or checking comes the reply From an account, you say Just an account

Blank look (One may say a blank bank look Then again, maybe not) The problem is that the question doesn t make sense There s no such thing as just an account All accounts (in this example) are either checking accounts or savings accounts The concept of an account is an abstract one that factors out properties that are common to the two concrete classes It is incomplete, because it lacks the critical property Withdraw() (After you get further into the details, you may find other properties that a simple account lacks) The concept of a BankAccount is abstract

Abstract classes are used to describe abstract concepts An abstract class is a class with one or more abstract methods Oh, great! That helps a lot Okay, an abstract method is a method marked abstract We re really moving now Let me try again: An abstract method has no implementation now you re really confused Consider the following stripped-down demonstration program:

// AbstractInheritance - the BankAccount class is actually abstract because // there is no single implementation for Withdraw namespace AbstractInheritance { using System; // AbstractBaseClass - create an abstract base class with nothing // but an Output() method abstract public class AbstractBaseClass { // Output - abstract method that outputs a string // but only in subclasses that override it abstract public void Output(string sOutputString); } // SubClass1 - one concrete implementation of AbstractBaseClass public class SubClass1 : AbstractBaseClass { override public void Output(string sSource) { string s = sSourceToUpper(); ConsoleWriteLine( Call to SubClass1Output() from within {0} , s); } } // SubClass2 - another concrete implementation of AbstractBaseClass public class SubClass2 : AbstractBaseClass

{ override public void Output(string sSource) { string s = sSourceToLower(); ConsoleWriteLine( Call to SubClass2Output() from within {0} , s); } } class Program { public static void Test(AbstractBaseClass ba) { baOutput( Test ); } public static void Main(string[] strings) { // you can t create an AbstractBaseClass object because it s // abstract - duh C# generates a compile time error if you // uncomment the following line // AbstractBaseClass ba = new AbstractBaseClass(); // now repeat the experiment with Subclass1 ConsoleWriteLine( Creating a SubClass1 object ); SubClass1 sc1 = new SubClass1(); Test(sc1); // and finally a Subclass2 object ConsoleWriteLine( \nCreating a SubClass2 object ); SubClass2 sc2 = new SubClass2(); Test(sc2); // wait for user to acknowledge ConsoleWriteLine( Press Enter to terminate ); ConsoleRead(); } } }

The program first defines the class AbstractBaseClass with a single abstract Output() method Because it is declared abstract, Output() has no implementation, that is, no method body Two classes inherit from AbstractBaseClass: SubClass1 and SubClass2 Both are concrete classes because they override the Output() method with real methods and themselves contain no abstract methods A class can be declared abstract whether it has abstract members or not; however, a class can be concrete only when all of the abstract methods in any base class above it have been hidden (overridden) with real methods The two subclass Output() methods differ in a trivial way Both accept an input string, which they regurgitate to the user However, one converts the string to all caps before output and the other to all lowercase characters