Thursday, January 28, 2016

Uh-oh 14 days, some of chapter 7

I broke my own deal. I was doing relatively well and was writing blogs on a close to weekly basis. Then I decided to go slower on each of the chapters. This means that if I am going to write every week I may or may not have a full chapter done. The past two weeks have been, interesting. I haven't been able to find much time while at home to go through the C# book (either that or after Nora goes to bed I haven't wanted to take the time to read. Bad I know. I need to spend more time on the book if I am really to become a full developer. I will be honest (don't worry my boss knows this), I do not want to be installing our product at client sites forever. In order to stop doing that I need to spend more time learning to code.

Anyway, I have said that before and I guess writing it down (again) reminds me (again) that I need to just do it more. That may mean late nights or staying late at work (staying late is hard because when I stay too late I don't get to see my daughter). I know I disappoint the 20 readers when I don't post something. I need to make a list of subjects that are separate from the book to have a continuous flow of subjects.

Onto the meat of the blog, I have started chapter 7 in the book. I have seen at work we will have a class that says ThisClass : IInterface. I had no idea what the ": IInterface" was doing and had heard some people talking about interfaces. Up until now I had no idea what they were talking about (shame on me for not asking more questions when I saw them in the code). An interface tells a class that it must implement certain methods and properties. The interface does not tell the class how to implement these methods and properties, just that it has contain these in some form. Okay, not in some form, the methods and properties in the interface must be implemented with the same names and return types.

I learned a little about downcasting and upcasting to make it so you can have an array of objects that aren't 100% the same, but implement the same interface. Seems like that can be really useful and I am sure the exercise for the chapter will let me get a try at this.

More on Chapter 7 on a later blog.

On a side note, we are starting to use Microsoft Azure at work. So far it seems like it will be a powerful tool. Our team has created templates and we are finding out how powerful Azure actually is. When I say our team, I mean a few of the guys are doing that and I am getting more an more behind. They have posted some articles on Azure on our internal site, I need to get reading those.

Chapter 7, here I come!


Thursday, January 14, 2016

Bee Management

Well, it is another week and I find myself saying, "I am not moving as fast as I would like." There is always more learning to be done. The amount of learning for me to feel comfortable telling people I am a developer is a large amount! Luckily, my job title is only doing part time coding, but that doesn't mean I should go slow on my learning.

This chapter took me longer than I had hoped. Not only did it take a long time, I also feel I did myself a small disservice in this chapter. The book provides the code that they want you to write. That is great when you are stuck, but I feel I was using the "help" too much. I created a Bee Management system in two parts. The first part used code that I should already know, I do. The problem, I should have taken the opportunity to learn it better. I felt I didn't have enough time to do this though and looked at the "help" more than I ought to have. I need to slow down and spend more time doing the code myself. That is a New Years resolution 14 days late.

Now, house cleaning out of the was and the confession of my sins is done. I already blogged about the inheritance in chapter 6 and, as I thought, I redid the party planner and used inheritance instead of writing extra code. Before doing that I learned a little about the hierarchy used in the code. If you don't override you can run into some issues with code not doing what you want when using inheritance.


The bee management program was done in two steps. First just writing the program that assigns the jobs to the bees, no inheritance used. The next piece was to use inheritance by adding a class that all bees used for honey consumption. Hey! I got to override the honey consumption for the queen, she apparently is real hungry when the bees work.

Not only did I override a method, I also added parameters to a subclass. This requires a little different syntax then the virtual/override. The bee class (base class) has a weight parameter and the worker bee (subclass) also tells you what jobs they can do. Do something like:

public Worker(string[] jobsICanDo, int weight) : base(weight)
(the string is an array and I hard coded the jobs a bee can do in the Form1.cs file.)

The Bee class has the weight parameter and the worker class added the jobs parameter.

So much you can do with code!

Here is the bee management program. Happy bee management!

Now that 15 days of the year have gone, I hope you are still doing your resolutions. If not, I hope you have a great new start with your old habits!

Wednesday, January 6, 2016

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