if (catchyTitle.Text == "Interface Inheritance" ) { MessageBox.Show("Chapter 7 is done!") }

This chapter took a little longer than prior chapters. Maybe it is because there is more material and the coding projects try to use the majority of code I have learned in the prior chapters. So, since a few blogs ago I decided that I wasn't going to use the "help" as much as I had been prior. I would say I succeeded pretty well in this chapter. Building a house with places to hide I did go to solution after I got stuck and was unable to make progress. I hope it helped me learn what I was actually using better. I think it also helped that I didn't have many days between actually looking at code I started and code I was finishing. Instead of having to remind myself of what I did before, I was able to remember it pretty well.

While my code doesn't look the same as the solution, and probably has more lines then what is needed, I ended up having an issue where my form wasn't updating correctly. The issue showed itself after I implemented the interface for a hiding place. I forgot to call a method when moving from one room to another called ReDreawForm(). Hence, the form was not redrawing and giving incorrect information about where the hiding place was in the different rooms.

Well, the hide and seek project (I called it long project because when I started it the book said it was going to be a long one) contains both outside rooms and inside rooms. Both inherit from the Room class. Then there are two interfaces for rooms that have exterior doors and rooms with hiding places. I had to do some searching on what to display depending on the room type (IHasExteriorDoor or IHidingPlace). In comes upcasting and downcasting (aka Polymorphism). Example of finding a class that inherits from an interface:

if (currentLocation is IHasExteriorDoor)
            {
                goThroughTheDoor.Visible = true;
            }

That brings me to another point, Object Oriented Programming has four principles (why the book waited to chapter 7 is a good question):

• Inheritance - one class or interface inherits from another

• Encapsulation - creating an object that keeps track of its state internally using private fields, and uses public properties and methods to let other classes work with only the part of the internal data that they need to see

• Abstraction - When you create a class model that starts with more general - or abstract - classes and then has more specific classes that inherit from it. Cannot instantiate these

• Polymorphism - "Many forms" Take an instance of one class and use it in a statement or method that expects a different type, like a parent class or an interface that the class implements. Upcasting or downcasting allows us to get polymorthism.

We have used all of the principles so far, it now is a matter of being able to remember each principle and how each is used (so much to remember, but I think coding more often will help that). 

This chapter also talked about access modifiers. You know, like public or private but with a few more. 

• Public - anything can access this (as long as access to the declaring class.) Least restrictive. Only use if you have a reason to make it public.
• Private - only other members in the class can access it (other instances of the class can use these as well). You can only mare a class private if it is encased in another class.
• Protected - public to subclasses, private to all else.
• Internal - public only to other classes in the assembly. Protected Internal can only be accessed from within the assembly OR from a subclass.
• Sealed - class which cannot be subclassed. Not an actual access modified, it only affects inheritance.

I think something to help remember the implementations, inheritance from a class allows you to modify the methods or use the methods how they are written in the base class. Interfaces have abstract methods and cannot be instantiated. The methods in the interface do not have any code in the contained methods, it only tells a class that inherited from the interface that all the methods MUST be used. The class can then implement any type of code needed for the given method, but it has a framework of what needs to be implemented from the interfaces.

I am only touching the surface I know. So much to learn!

GitHub Repository

Go play hide and seek!

Inheritance

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