a question about this book

[John Salerno]

I'm thinking about reading Beginning C# Objects: From Concepts to Code
because I still don't have a great grasp of objects, but I wonder if C#
2.0 will change things enough that a lot of what's in the book will no
longer be relevant or applicable? I know generics are the big change,
but since I don't have much of a concept of what they are yet, I don't
know how much they (and other changes) will effect any of the content of
books released before 2005.

Thanks.

 

[Josh]

What dont you understand about objects?

 

[John Salerno]

What dont you understand about objects?

Hard to say. I understand what they are basically, but I can't help but
try to read programs from top to bottom (procedurally, I guess), and I
know that objects don't quite work that way. It seems like in order to
understand an OO program, you have to jump around in the code to see
everything. That can be a little confusing, and also I guess I just
wanted a better explanation of how they work. Maybe there's a website I
can read that explains it well?

 

[Steve Walker]

Hard to say. I understand what they are basically, but I can't help but
try to read programs from top to bottom (procedurally, I guess), and I
know that objects don't quite work that way. It seems like in order to
understand an OO program, you have to jump around in the code to see
everything.

Ah, now, that's just the point. If your classes are well designed, in
the context of inspecting code that uses them, you shouldn't need to
look at their source to see how they work.

 

[Josh]

It seems like in order to understand an OO program, you have to jump

around in the code to see everything.

If the code is written OO you dont have to step into all of that code. For
instance, heres some code.

String a = "some text"'
DataTable myTable = UserBusinessObject.GetBlankTable();
int b = 23;


Now when reading through this code you wouldn't have to follow the flow into
"UserBusinessObject.GetBlankTable()" because it's self explanatory, and
provided there is no error when you make the call you dont have to go look
in there.

OO code should be broken down into compact self contained units so that
reading the code is simpler than reading procedureal code. Effectively OO
can simply be considered an enhanced GOSUB technology.

 

[Sam sgentile]

Hello Josh,

No, you don't need to step into that code. That is the whole idea behind
Encapsulation which basically abstrats some chunk of functionality into a
box with well defined inputs/outputs (an interface contract). That beiong
said, it's going to be really hard without some basic understanding of OO
concepts since the .NET Framework is completly OO oriented. So, I have already
suggested Petzold's Programmin In The Key of C# in another thread that teaches
programming from the ground up and Part IV teaches OO from the ground up.

This intro is in C++ but some of intro may help http://www.zib.de/Visual/people/mueller/Course/Tutorial/tutorial.html

Also:
http://www.softwaredesign.com/objects.html
http://www.firststep.com.au/education/solid_ground/oo.html

Sam Gentile
Chief .NET Architect
Adesso Systems, Inc
INETA Speaker, Microsoft MVP - .NET/C#
Blog: http://samgentile.com/blog/

J> If the code is written OO you dont have to step into all of that
J> code. For instance, heres some code.
J>
J> String a = "some text"'
J> DataTable myTable = UserBusinessObject.GetBlankTable();
J> int b = 23;
J> Now when reading through this code you wouldn't have to follow the
J> flow into "UserBusinessObject.GetBlankTable()" because it's self
J> explanatory, and provided there is no error when you make the call
J> you dont have to go look in there.
J>
J> OO code should be broken down into compact self contained units so
J> that reading the code is simpler than reading procedureal code.
J> Effectively OO can simply be considered an enhanced GOSUB
J> technology.
J>

 

[John Salerno]

Hello Josh,

No, you don't need to step into that code. That is the whole idea behind
Encapsulation which basically abstrats some chunk of functionality into a
box with well defined inputs/outputs (an interface contract). That beiong
said, it's going to be really hard without some basic understanding of OO
concepts since the .NET Framework is completly OO oriented. So, I have already
suggested Petzold's Programmin In The Key of C# in another thread that teaches
programming from the ground up and Part IV teaches OO from the ground up.

This intro is in C++ but some of intro may help http://www.zib.de/Visual/people/mueller/Course/Tutorial/tutorial.html

I just finished reading that book, but I think I could understand it better.

 

[John Salerno]

Ah, now, that's just the point. If your classes are well designed, in
the context of inspecting code that uses them, you shouldn't need to
look at their source to see how they work.

Well see, the fact that I'm seeing a problem where there shouldn't be
shows that I don't fully understand it.

 

[Sean Hederman]

I'm thinking about reading Beginning C# Objects: From Concepts to Code
because I still don't have a great grasp of objects, but I wonder if C#
2.0 will change things enough that a lot of what's in the book will no
longer be relevant or applicable? I know generics are the big change, but
since I don't have much of a concept of what they are yet, I don't know
how much they (and other changes) will effect any of the content of books
released before 2005.

The OO concepts that I assume that book contains will be fundamental for a
long time to come. The .NET framework is entirely objects, and the new
features of 2.0 do not change that at all. Generics allows you to created
slightly different types of classes, iterators construct enumerator classes
for you, and anonymous methods create delegates for you. In all these areas
a strong understanding of OO is still required. My suggestion would be to
read what you can on OO and make sure you understand it before worrying too
much about the 2.0 features.

Also, play around with samples from the books. I'm sure they've got examples
and stuff, so develop them. Also, try writing them procedurally and then
make a major design change to both the procedural and the OO code. You
should quickly see the advantages of OO in such a case. My conversion to the
"OO Way" was not a sudden epiphany but a gradual accretion of understanding.

 

[Rick Elbers]

The OO concepts that I assume that book contains will be fundamental for a
long time to come. The .NET framework is entirely objects, and the new
features of 2.0 do not change that at all. Generics allows you to created
slightly different types of classes, iterators construct enumerator classes
for you, and anonymous methods create delegates for you. In all these areas
a strong understanding of OO is still required. My suggestion would be to
read what you can on OO and make sure you understand it before worrying too
much about the 2.0 features.

Also, play around with samples from the books. I'm sure they've got examples
and stuff, so develop them. Also, try writing them procedurally and then
make a major design change to both the procedural and the OO code. You
should quickly see the advantages of OO in such a case. My conversion to the
"OO Way" was not a sudden epiphany but a gradual accretion of understanding.

Sean,

It might be worse as we will discover if c#2.0 goes live. Templates or
generics as c# wants to call them are notorious for abuse and defeat
of good OO design. The parameters break the encapsulation.

Rick

 

[Jon Skeet [C# MVP]]

It might be worse as we will discover if c#2.0 goes live. Templates or
generics as c# wants to call them are notorious for abuse and defeat
of good OO design. The parameters break the encapsulation.

Fortunately generics are a bit more restricted than C++ templates, in
an attempt to reduce the abuse. I'm not hugely familiar with all the
ins and outs of C++ templates so don't know all of the kinds of abuse,
but hopefully it'll be a bit better with C#. (Sound familiar from the
operator overloading discussion?

 

[Rick Elbers]

Jon,

Fortunately generics are a bit more restricted than C++ templates, in
an attempt to reduce the abuse. I'm not hugely familiar with all the
ins and outs of C++ templates so don't know all of the kinds of abuse,
but hopefully it'll be a bit better with C#. (Sound familiar from the
operator overloading discussion?

Sure. I see a pattern too. One other problem not solved in c++
templates was polymorphism inside stl containers. Therefore a lot of
people implemented polymorphy with pointer containers in which case
you can create polymorphic containers. Then the ownership problem
emerged, which was not present in the original beautiful stl design,
cause stl container is not going to delete your pointers. Both
problems are probably not generic for c# lol.

Regards,
Rick