First, I did take some time off of EVERYTHING (except being a dad and husband and all the stuff I normally do at home). Okay, let me rephrase that, I took some time off work and coding. I should have spent at least some of my time of during December to learning me some code but, alas, I did not. No going back now, so now I have two weeks of family time only, which is good! Next, I just started reading the next chapter on inheritance yesterday and am not finished, but I feel I need to provide an update.
Ah, inheritance. Sometimes you inherit really great things, like the genius gene or money, and sometimes not so great things, some sort of really bad gene. Coding, you can luckily change what gets inherited, kind of. More on this later.
Coding, a subclass inherits everything from the base class (return type, fields, parameters, everything). Do something like:
Class A {
public int field1;
}
Class B ; A {
public int field2;
}
That allows the coder to do a lot less code duplication. The code above, class A has one field called field1 and class B has two fields, one called field2 and one it inherited from class A called field1. One less line of code to write, yeah!
I started out with an exercise from the book, I took the Party Planner tool from the last chapter and added the ability to cost out birthday parties.
The two cost structures were almost identical with a few minor differences. At work I had seen, and actually used, inheritance before. I knew that it was possible, although when I used it I was more copying what I learned from Google and didn't understand what I was doing. So, when the book had me typing everything out for my new class that was pretty much the same code as another class that already existed I thought, "Man, this seems like a lot." And it was. Too much.
The book must have the readers go through that to see if we will stop and think that there has to be a more simple way (the reader should know that there is because it alludes to this fact at the beginning of the chapter). I am just past this point in the book and I think in the next few pages it will have me create another project, probably just like the party planner before, but this time use a base class for my overall Party and have sub-classes: one for dinner parties and one for birthday parties (just my guess but knowing the structure of the book, it is probably a pretty good guess, we will see on the next post...ooh, I cliff hanger).
WAIT! What about my kind of statement above? I did get a little further after re-writing all my party code. I read that you can change something that gets inherited from the base class. You just need to make sure your method is marked with "virtual" like below:
In Class A:
public virtual void CoolMethod () {
//do some CoolMethod here
}
This needs to be followed by an override in the subclass like, say class B that inherited from A:
public override void CoolMethod() {
//do an even more CoolMethod here
}
No you inherited everything else that is in class A, such as field1, but the CoolMethod does some other awesome stuff that A doesn't do, and also has field2 (see above).
More to come on inheritance.
A few definitions:
Subclass: A class that inherits fields and methods from a base class
Override the method: A subclass changes the behavior of an inherited class
Class Hierarchy: Classes at the top are base classes with subclasses below it. Those subclasses can have their own subclasses that inherit from them
P.S. Maybe I should spend more time this week learning GitHub...I deleted the Chapter 6 code...again! Anyway, I took a shortcut on recreating the code..You can get the program here.
https://github.com/robertjorg/Ch6
Ah, inheritance. Sometimes you inherit really great things, like the genius gene or money, and sometimes not so great things, some sort of really bad gene. Coding, you can luckily change what gets inherited, kind of. More on this later.
Coding, a subclass inherits everything from the base class (return type, fields, parameters, everything). Do something like:
Class A {
public int field1;
}
Class B ; A {
public int field2;
}
That allows the coder to do a lot less code duplication. The code above, class A has one field called field1 and class B has two fields, one called field2 and one it inherited from class A called field1. One less line of code to write, yeah!
I started out with an exercise from the book, I took the Party Planner tool from the last chapter and added the ability to cost out birthday parties.
The two cost structures were almost identical with a few minor differences. At work I had seen, and actually used, inheritance before. I knew that it was possible, although when I used it I was more copying what I learned from Google and didn't understand what I was doing. So, when the book had me typing everything out for my new class that was pretty much the same code as another class that already existed I thought, "Man, this seems like a lot." And it was. Too much.
The book must have the readers go through that to see if we will stop and think that there has to be a more simple way (the reader should know that there is because it alludes to this fact at the beginning of the chapter). I am just past this point in the book and I think in the next few pages it will have me create another project, probably just like the party planner before, but this time use a base class for my overall Party and have sub-classes: one for dinner parties and one for birthday parties (just my guess but knowing the structure of the book, it is probably a pretty good guess, we will see on the next post...ooh, I cliff hanger).
WAIT! What about my kind of statement above? I did get a little further after re-writing all my party code. I read that you can change something that gets inherited from the base class. You just need to make sure your method is marked with "virtual" like below:
In Class A:
public virtual void CoolMethod () {
//do some CoolMethod here
}
This needs to be followed by an override in the subclass like, say class B that inherited from A:
public override void CoolMethod() {
//do an even more CoolMethod here
}
No you inherited everything else that is in class A, such as field1, but the CoolMethod does some other awesome stuff that A doesn't do, and also has field2 (see above).
More to come on inheritance.
A few definitions:
Subclass: A class that inherits fields and methods from a base class
Override the method: A subclass changes the behavior of an inherited class
Class Hierarchy: Classes at the top are base classes with subclasses below it. Those subclasses can have their own subclasses that inherit from them
P.S. Maybe I should spend more time this week learning GitHub...I deleted the Chapter 6 code...again! Anyway, I took a shortcut on recreating the code..You can get the program here.
https://github.com/robertjorg/Ch6
No comments:
Post a Comment