Learning C# in 21 Days - Progress and Questions thread.

sniffy · 11 Sep 2009 at 13:02

I'm a CS undergrad so my answers aren't exactly correct, just my understanding

Morthoseth said:
Encapsulation refers to Objects effectively, an object that defines a circle outputs a circle, though the way the circle is worked out is 'encapsulated' in such a way that it keeps the user oblivious. If the object outputs a circle, all the inner workings out are irrelevant

That's pretty much it. To me the important thing to keep in mind is that an encapsulated class only shows what it does, not how it does it.

Polymorphism covers quite a few things, if you were to feed an object certain arguments and depending on what arguments are fed into the object, different outputs are created - based on the information fed in, the output could be a square, circle, triangle.

My understanding of this is admittedly vague. My Java lecturer would talk about it early on but I didn't really appreciate the concepts when I was so new to it all. Polymorphism basically means the ability to appear in many forms/shapes. It's closely linked to inheritance. For example say you have a superclass called MediaItem. Two subclasses called DVD and CD extend this superclass. Now say you have a collection (say an ArrayList) of MediaItem objects. Within this collection you can store DVD and CD objects. Now say you want the title of all objects within this collection (through a simple get method that's in MediaItem). If you hadn't taken advantage of inheritance and polymorphism concepts, you'd need separate collections for DVD and CD items along with other sloppy code issues. Imagine you had 20+ subclasses of MediaItem; things get messy awfully quick.

If I'm wrong please correct me

Haircut · 11 Sep 2009 at 13:29

sniffy said:
My understanding of this is admittedly vague. My Java lecturer would talk about it early on but I didn't really appreciate the concepts when I was so new to it all. Polymorphism basically means the ability to appear in many forms/shapes. It's closely linked to inheritance. For example say you have a superclass called MediaItem. Two subclasses called DVD and CD extend this superclass. Now say you have a collection (say an ArrayList) of MediaItem objects. Within this collection you can store DVD and CD objects. Now say you want the title of all objects within this collection (through a simple get method that's in MediaItem). If you hadn't taken advantage of inheritance and polymorphism concepts, you'd need separate collections for DVD and CD items along with other sloppy code issues. Imagine you had 20+ subclasses of MediaItem; things get messy awfully quick.

If I'm wrong please correct me

That's sort of it, but not quite - it could be me not understanding your example properly though.

Imagine your MediaItem class again, assuming it's an abstract clas you could have an abstract method called Play()

In your DVD and CD classes you could then override this method to do various things.
In the DVD class the Play method could start up your video player application.
In the CD class the Play method could start up the music player application.

When you create your application all you need to worry about is the MediaItem class.
You can get a particular MediaItem, call the Play method on it and it will fire up the video player or music player depending on the concrete type of the object, but the calling code doesn't need to know whether it's a DVD, CD or whatever.
It only has to depend on the MediaItem class, so later down the line you could create a Blu-Ray class that again inherits from MediaItem and have that fire up a blu-ray player application in the Play method without having to change the calling code at all.

That's polymorphism.

sniffy · 11 Sep 2009 at 16:15

Thank you for clearing that up. That's how I naturally code now; I just wasn't aware it came under polymorphism.

Morthoseth · 11 Sep 2009 at 16:43

Thanks for the overwhelming response, after reading some of the feedback i actually looked in the sticky at the top of the Programming board and took a look at the first thing under c#.

Lesson one on there, when combined with the book is quite helpful - and the actual layout in terms of chapters is pretty much the same, the book may go deeper into the theory, but the website goes deeper into the code. With a decent mix of both, i reckon i'll do alright as far as learning goes.

As for an initial goal, i'm not sure what could really be realisitc - in my computing class ~5 years ago i made an appointment booking system with added features in VB, so making something similar wouldnt be too bad, though i feel once i get to the database stages it will be slightly trivial.

Any suggestions as for first projects? As previously mentioned an e-mail client sounds good, though also very hard i'd imagine!

A way to catalogue and rate my DVD collection could be quite good, but i'll see what you guys think.

I'll post a Day two update later on :-)

Mr^B · 11 Sep 2009 at 16:53

There's extremely important concepts that you really should understand before coding anything at all - things like:

Source Control and Versioning
Unit Testing
SOLID principles
n-tier architecture
data storage
XML

And for OO programming specifically:

UML
Design Patterns

A book is good for learning the syntax of a language, but actually using it - and writing "good" code - is something else entirely.

Haircut · 11 Sep 2009 at 17:11

Mr^B said:
There's extremely important concepts that you really should understand before coding anything at all - things like:

Source Control and Versioning
Unit Testing
SOLID principles
n-tier architecture
data storage
XML

And for OO programming specifically:

UML
Design Patterns

A book is good for learning the syntax of a language, but actually using it - and writing "good" code - is something else entirely.

I've got to say I disagree with this, for most beginners there's no way they're going to get a grasp of all that stuff before they start coding.
I would get stuck into some simple projects and learn about the various other bits and pieces along the way.

You don't need to know about n-tier architectures to create a small project yourself.

Mr^B · 11 Sep 2009 at 20:03

Haircut said:
I've got to say I disagree with this, for most beginners there's no way they're going to get a grasp of all that stuff before they start coding.
I would get stuck into some simple projects and learn about the various other bits and pieces along the way.

You don't need to know about n-tier architectures to create a small project yourself.

It's easier to do it that way round - otherwise you end up having to "undo" all the bad habits that people learn whilst learning to code.

No "learn to code in 24hrs" book ever talks about source control - are you saying that source control is a difficult concept to grasp?

Programming is 10% writing code and 90% organising code. And as organising code is largely language agnostic, it makes sense to learn it that way round, surely?

Haircut · 12 Sep 2009 at 08:16

Mr^B said:
It's easier to do it that way round - otherwise you end up having to "undo" all the bad habits that people learn whilst learning to code.

No "learn to code in 24hrs" book ever talks about source control - are you saying that source control is a difficult concept to grasp?

Programming is 10% writing code and 90% organising code. And as organising code is largely language agnostic, it makes sense to learn it that way round, surely?

I never said source control was a difficult concept to grasp, but I certainly think things like design patterns and SOLID principles are if you've never done any coding before.
To be honest I can't see any aspect of OO really making much sense unless you've had some prior development experience.
That's definitely one of the things I would learn while doing.

I don't agree with the bad habits comment either, as long as you're using good coding style (which can be done with the help of some reference books) then I see nothing wrong with learning how to write procedural code before OO.
As developers you're always learning of better ways to do things anyway and I often find the best way to learn things is to get them wrong in the first place.

Obviously I'm not saying that you shouldn't learn the things on your list as soon as possible, just that it makes sense to incorporate them into your work while you're coding rather than doing all of that before properly getting going with the code.

Mr^B · 12 Sep 2009 at 15:31

We'll have to agree to disagree then.

There's a few things like SOLID and design patterns where I'll shift some ground. But I'm not shifting on items like unit testing and source control. There are "professional" developers out there who still don't use either. Crazy huh?

Mr^B · 12 Sep 2009 at 20:40

Maybe swap out UML and replace it with CRC cards.

lokkers · 13 Sep 2009 at 10:03

I've got to agree with Haircut. You don't need to learn about unit testing and source control when you are first learning a language. Yes, for professional developers they are a must, but not when you have first set out to learn some code.

Once the OP has some skills and decides to use them for a personal project (which I would highly recommend doing), he can investigate source control and the like.

Mr^B · 13 Sep 2009 at 10:52

You see, that's the problem - that's what everyone does.

"Oh, i'll add it to source control later"
"I'll add some unit tests, when I've got time, after I've actually done the work"

And it might start as a private project (just to learn the language) but it all too often spill over into professional development. And it's VITAL to get these things nailed down as quickly as you can.

There are still professional devs out there who don't use source control and think that unit testing is a waste of time and it's a result of bad habits which are extremely difficult to shift.

Unit testing and source control should NEVER be an afterthought.

lokkers · 13 Sep 2009 at 13:33

Jesus - the guy doesn't even know the BASICS of C# and you're saying that he needs to learn source control and unit testing, as well as n-tier development now?!

You're right - these things should never be an afterthought in a professional environment, but as the OP is learning C# in 21 days, I'd think the basics of the language are more important now. More complex (and important things) can come later. Just because initially he doesn't know these things doesn't mean he will be an awful developer in the future.

What you're basically saying is that his HelloWorld application(s) should be in SC, using unit test and implement n-tier architecture. I think following KISS is more applicable in these circumstances.

Mr^B · 13 Sep 2009 at 15:26

should be in SC, using unit test and implement n-tier architecture

If he's done programming before (which he says he has), then the answer is most definitely, "yes".

It's not hard to set up source control, nor is it hard to do a "hello world" application using TDD and by extension a "proper" MVC architecture (which if you are doing a web-page ASP.Net kindly augments for you by at least separating the V from the M&C aspects already).

This isn't meant to put the OP off from learning, on the contrary, it will make learning the language easier (esp. an OO language).

Or are you saying that his questions relating to OO principles should be completely ignored too? After all, you can just use C# as a procedural language if you like, 100s of static methods all over the place...still, he can always learn about OO programming later - right?

lokkers · 13 Sep 2009 at 17:42

Mr^B said:
If he's done programming before (which he says he has), then the answer is most definitely, "yes".

It's not hard to set up source control, nor is it hard to do a "hello world" application using TDD and by extension a "proper" MVC architecture (which if you are doing a web-page ASP.Net kindly augments for you by at least separating the V from the M&C aspects already).

No of course it isn't, but when you are learning someone new you shouldn't spend time overcomplicating things. If I knock up a quick app to implement something I've just learnt (say a bit of WCF), I don't go to the trouble of putting it in SC, implementing unit tests and making sure its to the same high quality as any of my "proper" code. Why? Because it detracts from the simple reason for the code in the first place - a quick demonstration of key concepts that I want to cement into my mind.

Mr^B said:
This isn't meant to put the OP off from learning, on the contrary, it will make learning the language easier (esp. an OO language).

I can't see how, simply because it isn't teaching him anything about the code nor the .NET framework.

Mr^B said:
Or are you saying that his questions relating to OO principles should be completely ignored too? After all, you can just use C# as a procedural language if you like, 100s of static methods all over the place...still, he can always learn about OO programming later - right?

No because that's a fundamental part of the language. TDD and SC aren't.

I think we're going to go around in circles here, and we're at risk of completely derailing this thread (which I'm sure the OP doesn't want). I think the best thing to do will be to agree to differ, and to let to OP decide if he wants to learn about these other aspects. Perhaps you'd be so kind as to provide him with some good tutorials? ASP.NET MVC is certainly one I would recommend (as you say, it implements a lot of the best practice features by default), although it's a bit of a jump from winforms or console apps.

Mr^B · 13 Sep 2009 at 19:40

OK, agree to disagree, with this final word.

Any idiot can write code, it's just grammar and syntax after all.

It takes time and patience and effort and all the other things I mentioned to write good code.

It takes none of the above to write awful code.

The code that I see, on a day-to-day basis is written as if it were the workings of someone who had just read a "learn to code in 24 hours" book. Probably because that's exactly what happened.

We have a large "code debt" team which aims to eliminate all this "just add water" code - and it's not a pleasant job. So anything I can do to lay reasonable foundations (rather than no foundations at all) is, for me, a good thing.

I understand the objections, simply because it's not the way that most people have learned to code, it certainly isn't the way that I learned to code - and, I agree that technically you need none of the above to "just get started". I was introduced to version control in my first job and it came as quite a surprise! It doesn't mean that I'm wrong though - and if the OP does just some basic reading around the subjects it'll make him a far better coder.

Izi · 14 Sep 2009 at 00:28

Mr B, what do you use for unit testing and versioning in your development?

Mr^B · 14 Sep 2009 at 08:59

Izi said:
Mr B, what do you use for unit testing and versioning in your development?

For Unit testing, I use nUnit (integrated into visual studio via Resharper) - together with Spring.Net as an IoC container and Rhino-mocks for mocking.

nUnit - http://www.nunit.org/index.php
ReSharper - http://www.jetbrains.com/resharper/
Sprint.Net - http://www.springframework.net/
Rhino Mocks - http://ayende.com/projects/rhino-mocks.aspx

Versioning is via subversion/visualSVN

http://subversion.tigris.org/
http://www.visualsvn.com/

Other tools

Nant (build automation scripting "language") - http://nant.sourceforge.net/
Cruise Control (continuous integration/daily builder service) - http://cruisecontrol.sourceforge.net/

Out of all of those, it's only ReSharper that I can't really live without - I have literally no idea how I managed without it. It's awesome.

Izi · 14 Sep 2009 at 09:58

ReSharper looks great!

Haircut · 14 Sep 2009 at 12:13

Izi said:
ReSharper looks great!

It is, I wouldn't ever be without it again.
As already said it integrates very nicely with nUnit as well.

We have a solution with getting on for 10,000 classes at work and on things of this size ReSharper just makes life so much more bearable.

The downside is that Visual Studio usually takes up around 1.4GB of RAM with ReSharper running!