OO and U

[kermitology]

Originally Posted by ZedMan

Jeebus, assembly. I will never forget that feeling of looking at code I had written only the day before and having NO IDEA what it did anymore

That said, higher level languages like C# and Java can be much more self documenting through the use of well chosen variable, function and parameter names.

Transitioning between Java and C# is pretty painless. With the exception of library class names, simpler programs will look pretty similar between the two.

As nice as self documenting code is, it still lacks the complete clarity of inline comments. You don't have to document every single line, but if there is any decision being made, something that might be in any way unclear, tell someone about it.

I once read a quote that said something along the lines of: "Document your code as if the next guy who has to support what you've written is a homicidal maniac, and he knows where you live"

[Phaneuf3]

Originally Posted by kermitology

As nice as self documenting code is, it still lacks the complete clarity of inline comments. You don't have to document every single line, but if there is any decision being made, something that might be in any way unclear, tell someone about it.

I once read a quote that said something along the lines of: "Document your code as if the next guy who has to support what you've written is a homicidal maniac, and he knows where you live"

+1 for documenting your code.

That homicidal maniac may just in fact be you 6 months from now. I hate going back to something I've written in a rush and didn't document properly and trying to figure out exactly how it worked while thinking "there's no way I could have written something this sloppy".

[BlackEleven]

Originally Posted by FanIn80

This is all good stuff man, thanks. I've only finished the first week of this class, so I still have a lot to cover before it's done... and then there's an advanced class after this one is done. Lots of room for covering lots of concepts.

Edit: Yeah, I've heard from quite a few people that C# is similar to Java. Also, this class is using C#, but the advanced OO class after uses Java.

It's a shame you don't get to use C++ at all, imo. Even though you may not use it in the real world, I think understanding the fundamentals of how memory works is an important concept. And there's no better way to learn that than managing it yourself.

[Bill Bumface]

Originally Posted by BlackEleven

It's a shame you don't get to use C++ at all, imo. Even though you may not use it in the real world, I think understanding the fundamentals of how memory works is an important concept. And there's no better way to learn that than managing it yourself.

I disagree with your logic when it went one level up from that and we had to write assembly to appreciate how C worked.

I know it was a good exercise and all that, but I sure hated it.

Edit: Oh, and writing javascript without a debugging environment besides the little yellow sign with exclamation in the status bar of IE.

[photon]

C# has some things I like over Java too.. properties for one, the whole idea of do nothing getters and setters in Java is dumb. Primitives in Java seems very counter OO, while C# primitives aren't actually primitives, they're just aliases for actual types. Anyone who's written boxing and unboxing code for Java primitives can appreciate that.

I still like Java more but that's probably more because of the entire Java environment (tools, available enterprise level open source projects, etc) than just the language itself.

[photon]

Oh and operator overloading too, though I can appreciate the arguments for not doing it.

[BlackEleven]

Originally Posted by hulkrogan

I disagree with your logic when it went one level up from that and we had to write assembly to appreciate how C worked.

I know it was a good exercise and all that, but I sure hated it.

Edit: Oh, and writing javascript without a debugging environment besides the little yellow sign with exclamation in the status bar of IE.

Well, there's only so many level you need to drill down too as well....

If I went to a professional driving school, I'd want drive a manual to learn how it worked, but I wouldn't necessarily want to learn how to build my own transmission.

[kermitology]

Originally Posted by Phaneuf3

+1 for documenting your code.

That homicidal maniac may just in fact be you 6 months from now. I hate going back to something I've written in a rush and didn't document properly and trying to figure out exactly how it worked while thinking "there's no way I could have written something this sloppy".

Yup. Of course every once in a while the scope of your code changes so much that you just scrap the whole damn thing and start over.

I did that rather recently. It turned out really nice, but man did it suck to accept the fact that I'd done it wrong in the first place.

[ZedMan]

Originally Posted by hulkrogan

I disagree with your logic when it went one level up from that and we had to write assembly to appreciate how C worked.

I know it was a good exercise and all that, but I sure hated it.

Put me as a +1 for learning the whole deal. Yeah it was hard but I found it really interesting. I think it's good to know how the stack, stack frames, etc. work.

Edit: Oh, and writing javascript without a debugging environment besides the little yellow sign with exclamation in the status bar of IE.

OMG yes. I spent a good half hour yesterday debugging some js. The problem? Misplaced comma .

[photon]

The fact that I hate interpreted languages like perl and javascript and such probably makes me an old time kermudgen programmer now doesn't it, who needs the security of a compiler.

*hugs his compiler*

[ZedMan]

Oh, I like interpreted, untyped languages as much as the next guy but I still think type checking is underrated. Ever used Haskell? Really really strict type checking (even though it is interpreted). If there were no type errors, chances were really good that your program would do exactly what you expected.

[photon]

Never used Haskell, looks interesting!

Yeah I remember when they introduced strongly typed collections in Java so instead of it just storing generic objects with keys that you had to cast to a type when taking them out you could enforce the type of the object in the map (or vector or whatever). On one hand I loved it since it saved quite a bit of code, on the other hand the "true" OO people were up in arms about it... lol. Go back to Smalltalk I told them.

[BlackEleven]

Originally Posted by photon

The fact that I hate interpreted languages like perl and javascript and such probably makes me an old time kermudgen programmer now doesn't it, who needs the security of a compiler.

*hugs his compiler*

I hate Perl and javascript as well, but I love Python. Tonnes of great built-in modules if you just need to crank out a fast, powerful, light-weight app. It's a pure object oriented language as well.

Right tool for the right job is my mantra when it comes to programming languages.

[kermitology]

Originally Posted by hulkrogan

I disagree with your logic when it went one level up from that and we had to write assembly to appreciate how C worked.

I know it was a good exercise and all that, but I sure hated it.

Dr. Smith's Motorola 68k class.. Ugh. However, that taught me so much in the end.

I still love that I got your labs, but since you didn't comment them, I had no idea what they did, so they were useless you me! :P

[FanIn80]

/bump

So this week, we're talking about class interfaces... but I'm having a hard time understanding when someone would want to use this. I just don't get the correlation. Why put a method in an interface, when you have to define it in the class anyway? It just seems redundant to me.

Can someone give me a real-world example of a class interface being used properly?

[FanIn80]

To further explain my confusion... here's the way it was explained to me in class today:

We created a class called "Head" and another called "Dog."
We created a class interface called "IBody."

In the IBody interface, we added a string method named Eat: string Eat();
In the Dog class, we added some attributes, constructors, properties and a behavior called Eat: public string Eat() { return "Yum!"; }

He then went on to say that now I can just keep creating different animal classes (Cat, Bird, Monkey, etc) and, since they all "Eat," I can use the class interface I created to save time.

The thing I can't get my head around, though, is how does it save me any time? I still have to write the Eat method in each class I make... Maybe if I wrote the Eat method in the interface, and then just called it in the individual classes, that I can see saving me time... but... there's something I'm sure I'm missing here.

[photon]

Interfaces aren't so much about saving time as they are about having a consistent interface for some group of classes. It's like a contract, everything that implements IBody must implement the Eat method, no matter what's actually underneath it.

So without an interface, you wouldn't know if Cat, Bird, Monkey implemented eat or if it did if it did it properly.

But with an interface, you could have a big collection of objects that you want to call the Eat method on.

Remember you can create an IBody reference to these objects:

IBody animal1 = new Cat();
IBody animal2 = new Dog();
animal1.Eat();
animal2.Eat();

The power in this isn't always readily apparent, but take a look at all the collections classes and how they are set up with interfaces to get an idea. Likely there'll be a Collection interface which has methods like get, put, sort, etc.. so in my program I can just use a Collection interface to do what I'm doing.. then say 6 months down the road I need to use a different kind of collection because of memory concerns or thread safety or whatever, I can change which implementation I use without having to recode and test a ton of code. I just say Collection stuff = new HashMap() instead of Collection stuff = new Vector() and the stuff underneath is changed.

So yeah, think about it as a contract, anything that implements an interface is guaranteed to have specific methods.

[FanIn80]

Ohhh... so that's why he kept telling me, "You're dog has to eat!" I thought he just meant that all animals eat, so my dog must also eat... I didn't know he meant that I have to use Eat in the Dog class because the interface is like a contract.

I thought an interface was just a way for multiple objects instantiated from different classes to share the same methods...

[photon]

Well if you write a Dog class and have it implement IBody, you have no choice but to implement the Eat method otherwise it won't compile.

So yes you are right, an interface is a way for multiple objects instantiated from different classes to share the same methods. You could do this without interfaces, just making sure that each class has the same Eat() method, but the interface gives you a few more things.. first it gives you the contract so your code won't even compile if it doesn't have it. And second it gives you the ability to have a reference to to an object where the type is the interface rather than the actual object type, so you can refer to your objects as IBody objects rather than Dogs and Cats, which gives you that flexibility I mentioned with respect to collections.

ETA: And third it gives you the ability to make your code modular or facilitate reuse and changing of code. If you are working on one area of a big system, and someone else is working on another area, you might have an interface to dictate how one is going to talk to the other. Then you can change the implementation underneath the interface as much as you want and the other guy doesn't care because the interface doesn't change.

This gets more into OOD.

[gottabekd]

Interfaces can be both great, and terrible things.

First, the terrible:

A lot of frameworks define everything in terms of Interfaces, then go ahead and implement the Interface creating a concrete class that implements the Interface. You end up with MyCoolInterface, and MyCoolInterfaceImpl (for Implementation). Yes, extremely redundant, and really makes the code ugly.

But on the nice side of things...

Well, photon already described the idea. But as you do more and more OO, you'll realize that the Interfaces are the key to beautiful code. You worry less about what type the object is, but what can this object DO. They help you see objects are more than a place to store data and methods that act on the data, but that they are building blocks of the entire system.