OOP 101 - Inheritance confusion

  • Thread starter Thread starter TomB
  • Start date Start date
T

TomB

I'm sure this is OOP 101 but I'm confused.

I'm writing a simple accounting type application. I created an abstract
class called IAccount, which my other account types are derived from.

Most of the code on the derived classes is repeated. So it occurred to me
that instead of an abstract class I should create a base class with the
basic functionality in it. However; I "need" to prevent that base class
from being instantiated. How would I do that?

I remember reading the "typical" example of a Bank Account Class, where
you'd have a Chequing account and a Savings Account based on it. In that
example they said to change BankAccount to IBankAccount to keep it from
being instantiated, but then I think the deposit and withdrawal methods
would be repeated-even they are the same.

Am I rambling? Thanks for any help.

Tom
 
OK.
I should have tried this before posting. I changed my Properties, removing
the abstract statement...like this.
<CODE>
public abstract class IAccount
{
private double m_Balance;
public IAccount()
{}
public double Balance
{
get{return m_Balance;}
set{m_Balance=value;}
}
public abstract int Number
{
get;
set;
}
</CODE>
It appears to be working as expected. If I'm doing it wrong, please let me
know.
 
TomB said:
I'm sure this is OOP 101 but I'm confused.

I'm writing a simple accounting type application. I created an abstract
class called IAccount, which my other account types are derived from.
Click to expand...

IAccount would be an interface. You just want an abstract class. Abstract
simply means that it cannot be instantiated directly.

abstract class Account
{
protected Decimal balance;
public Decimal Debit(Decimal Amount)
{
balance -= Amount;
return balance;
}
}

class DDAAccount : Account
{
protected string accountNumber;
DDAAccount(string AccountNumber)
{
accountNumber = AccountNumber;
balance = 0;
}
}

David
 
TomB said:
It appears to be working as expected. If I'm doing it wrong, please let me
know.
Click to expand...

Nope, that's the way to do it. Abstract classes _can_ provide
implementations of methods and/or properties if desired.
 
OK.
An interface has NO implementation code and everything MUST be overriden.
Correct?
Whereas an abstract can have implementation code, can be overriden, and
can't be instantiated.

Jeez, I thought I head around all this stuff.

TomB
 
TomB said:
Oh god....I thought Abstract and Interface were the same?!?
Click to expand...

Tom,

They are close, but not the same. You _MAY_ provide an implementation
of some method/property in an abstract class. You _CAN'T_ provide an
implementation of some method/property in an interface.
 
Stop thinking about Abstract and Interface in the same context. They are
used for different things.

If you want to stop a class from being inherited use an abstract class.
Pretend you know nothing about interfaces and never
use that keyword again ;)

-ilPostino
 
let me take my foot out my mouth -

correction to below: if you want to stop a class from being instantiated use
abstract! not inherited
 
Well, there's no reason you should avoid interfaces completely. They are
useful.
You just need to understand the diff btwn Interfaces and Abstract classes.

heres some code:

interface IVechicle {
int GetMaxSpeed(); // since this is an interface, methods have no body.
}
class Airplane : IVehicle {
public GetMaxSpeed() {
return 1000;
}
}
abstract class Car : IVehicle {
// this class represents one "genre" of vehicles, "Cars" - but is still
not concrete.

public int GetMaxSpeed(){
// you know all cars max speed is based on the same things, but
those things depend on the car;
return Octane * Torque;
}

// the abstract keyword here says that classes that extend the Car class
must implement these functions:
public abstract int Octane { get; }
public abstract double Torque { get; }
}
class BMW : Car {
int gas = 87;
public override int Octane { get {return gas;} }
public override double Torque { get {return 1.4;} }
}
sealed class BMW_Z3 : BMW {
// sealed indicates that you can NOT inherit from this class anymore.
// you don't really get more specific then the model... maybe year but
you get the point : )

public override double Torque { get {return 2.2;} }
}

So, how is this all useful?
the major difference btwn interfaces and abstract classes is that
when abstract classes are dervived from, implementation and variables come
along with the derivation;
sometimes you want this, like when all the derived objects have some
*behavior* in common
and sometimes you don't, here's an example:

interface ICommand { // represents a task you want the computer to do.
bool Run(); // run some code, and return success code.
}
class FtpDownload {
FtpConnection ftp;
public bool Run() {
ftp.DownloadFile("file.txt");
if(File.exists("file.txt"))
return true;
}
}
class SqlUpload {
SqlConnection sql;
public bool Run() {
return sql.UploadFile("file.txt");
}
}
void Main() {
ArrayList commands = new ArrayList();
commands.Add(new FtpDownload());
commands.Add(new SqlUpload());

foreach(ICommand com in commands){
com.Run();
}
}


Now, vow to always program with interfaces !!!!!!
 
Thanks for the great mini-tutorial.
Shouldn't your example at the end have your classes declared as implementing
ICommand?

Somewhere I read an article (sorry I really don't remember where) in which
the author said you should write an interface first for EVERY class. I
think he/she may have been trying to be dramatic. But I think the point was
that an interface forced you to "sign a contract" on what the class was to
do.

Thanks to everyone for the help.

You think you've got it, then boom you forget it all again.

Tom
 
yes, the ftp & sql classes should have been declared as implementing
ICommand - good catch.

I don't think you need an interface for every class, just the ones you plan
to have multiple implementations of.


TomB said:
Thanks for the great mini-tutorial.
Shouldn't your example at the end have your classes declared as implementing
ICommand?

Somewhere I read an article (sorry I really don't remember where) in which
the author said you should write an interface first for EVERY class. I
think he/she may have been trying to be dramatic. But I think the point was
that an interface forced you to "sign a contract" on what the class was to
do.

Thanks to everyone for the help.

You think you've got it, then boom you forget it all again.

Tom


Eric Weinschenk said:
Well, there's no reason you should avoid interfaces completely. They are
useful.
You just need to understand the diff btwn Interfaces and Abstract classes.

heres some code:

interface IVechicle {
int GetMaxSpeed(); // since this is an interface, methods have no body.
}
class Airplane : IVehicle {
public GetMaxSpeed() {
return 1000;
}
}
abstract class Car : IVehicle {
// this class represents one "genre" of vehicles, "Cars" - but is still
not concrete.

public int GetMaxSpeed(){
// you know all cars max speed is based on the same things, but
those things depend on the car;
return Octane * Torque;
}

// the abstract keyword here says that classes that extend the Car class
must implement these functions:
public abstract int Octane { get; }
public abstract double Torque { get; }
}
class BMW : Car {
int gas = 87;
public override int Octane { get {return gas;} }
public override double Torque { get {return 1.4;} }
}
sealed class BMW_Z3 : BMW {
// sealed indicates that you can NOT inherit from this class anymore.
// you don't really get more specific then the model... maybe year but
you get the point : )

public override double Torque { get {return 2.2;} }
}

So, how is this all useful?
the major difference btwn interfaces and abstract classes is that
when abstract classes are dervived from, implementation and variables come
along with the derivation;
sometimes you want this, like when all the derived objects have some
*behavior* in common
and sometimes you don't, here's an example:

interface ICommand { // represents a task you want the computer to do.
bool Run(); // run some code, and return success code.
}
class FtpDownload {
FtpConnection ftp;
public bool Run() {
ftp.DownloadFile("file.txt");
if(File.exists("file.txt"))
return true;
}
}
class SqlUpload {
SqlConnection sql;
public bool Run() {
return sql.UploadFile("file.txt");
}
}
void Main() {
ArrayList commands = new ArrayList();
commands.Add(new FtpDownload());
commands.Add(new SqlUpload());

foreach(ICommand com in commands){
com.Run();
}
}


Now, vow to always program with interfaces !!!!!!


TomB said:
I vow never to use that keyword again.

Thanks

P.S. At least until I know what I'm doing.

Stop thinking about Abstract and Interface in the same context. They are
used for different things.

If you want to stop a class from being inherited use an abstract class.
Pretend you know nothing about interfaces and never
use that keyword again ;)

-ilPostino



OK.
An interface has NO implementation code and everything MUST be
overriden.
Correct?
Whereas an abstract can have implementation code, can be
Click to expand...
overriden,
and
Click to expand...
Click to expand...
 
Trevor said:
Tom,

They are close, but not the same. You _MAY_ provide an implementation
of some method/property in an abstract class. You _CAN'T_ provide an
implementation of some method/property in an interface.
Click to expand...

Note also that the relationship between a class and an interface on one
hand, and a class and an abstract class on the other, is actually quite
different. In the former case, the class presents an _implementation_ of the
interface, there is no inheritance involved. In the latter case, however,
the class does _inherit_ from the abstract class, optionally extending and
polymorphing parts of its behaviour. In C#, you may inherit from just one
class (abstract or not), whereas you may implement as many interfaces as you
want.
 
ilPostino said:
let me take my foot out my mouth -

correction to below: if you want to stop a class from being instantiated use
abstract! not inherited
Click to expand...

or make the ctor protected....

regards
roy fine
 
public class Account
{
private Account()
{

}
}

Having a private constructor forbids the users of your class from
instantiating it.
with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
Back
Top