Newbie Question: When to use classes?
Hello, everyone.
I recently started studying c# and whole object oriented programming while creating an website for my employer. The website will be managing students(new students, collect documents, etc) and everything is going fine but I suddenly started asking myself if I needed to use classes.
for example, I got registering a new students to work without using classes.. but I guess if I really wanted to use OOP, I could have created a class called students with all those fields including name, address, ID, etc.
but if I did that, I would basically be doing 2 codings: 1 to add textbox values to the student classes, then other one to add student class fields to the database.
Is it always good idea to use classes? or can I just skip it if I am not going to re-use the object?
Please reply!!!
Thanks in advance and sorry for my sorry English skills :D
Re: Newbie Question: When to use classes?
You ask an interesting question; one which I'm certain will receive many replies before fading into obscurity. Indeed, this will probably be the most popular thread we've seen around here for quite some time.
In My Humble Opinion, classes are the very essence of Object-Oriented Programming ... that is, a class, instantiated, is an object, a fundamental element of OOP, and the distinguishing characteristic between an OOP flavor of C (think C++ or C#) and C itself.
I began with C in the late 70s and as a result of a number successful projects in C and/or assembler, I was reluctant to embrace OOP when first exposed to it many years later (Ada back in the early 90s) thinking that its passion for secrecy (referring to encapsulation, access levels, etc) was paranoiac at best, and sheer madness at worst.
And I think OOP or its implementation may even be a bit insulting to the programmer ... Ada for instance (or at least the version we used) refused to let programmers manipulate bits, thinking it was WAY too difficult for programmers to understand the concept of an 'AND' or 'exclusive OR'. And apparently the C# language designers still believe that pointers are far too difficult for mere programmers (Oh! the poor dears) with their severely limited mental capacity for understanding.
Another difficult thing for me was the strict type-discipline .... occasionally a little on the demeaning side if you ask me. God Bless FORTRAN's EQUIVALENCE statement !
But over the years, while still believing the OOP conceptualists must be a little twisted (and I would certainly hate to meet them in a dark alley), I have come to see the beauty in this new organization of data and functions (being a C purist, I refuse to call them 'methods'). I now embrace the richness of the OOP paradigm which is really saying something coming from an old troglodyte such as I. And I really do love Microsoft's C++ and c#. Now ... The first few years however, coming from a C/FORTRAN/Assembler background, were very painful.
So you ask if one should always use classes ... perhaps not when working with the most trivial applications. But from the pragmatic perspective, with VS 2010 (or 8 or whatever flavor of Visual Studio you have), one is working in an OOP milieu. That IDE is designed with OOP in mind and I can't help but think one's life would be much easier if one chose to "go with the flow" and employ OOP. When in Rome, do as the Romans do.
Sure, one could probably fight the compiler and win, but is that the most efficient way to spend one's time (is that how one's employer wants his or her time spent)? Fighting the compiler and entire IDE ? I would think it'd be easier to work in pure C if one wishes to avoid OOP and classes.
Re: Newbie Question: When to use classes?
If you want to market what you know, learn what's used most...
Re: Newbie Question: When to use classes?
Quote:
Originally Posted by
ThermoSight
So you ask if one should always use classes ... perhaps not when working with the most trivial applications.
I didn't want to be the first to say this, fearing what "C-purists" might respond - but since this came from one, I'll be happy to re-state it: you should always use classes.
What's the real question here is granularity - what should a class encompass/represent and how to properly design it. You can still write what's fundamentally not OO code even if you use classes; this is why it's important to understand the principles of OO programming first (at least the basic ones). This is not such an easy task though; a lot of abstract concepts there that may seem strange or unjustified at first - but don't let that discourage you. Iit's all to the goal of making your code easier to understand, debug, and reuse, and hopefully harder to mess-up. However, though classes are in the core of OO, by themselves they are really nothing but a neat way to organize code - the real power comes from their interactions. The real power of OO is revealed in systems of classes working together, in design patterns and higher level constructs.
Quote:
Originally Posted by
ThermoSight
[...] the distinguishing characteristic between an OOP flavor of C (think C++ or C#) and C itself.
I wouldn't call C# a flavor of C, since the languages are not related in the same way C and C++ are. But it does belong to the same family (C-family) of languages (to illustrate the scope of "C-family": so does Java). The syntax and the grammar are similar, but it pretty much ends there.
Re: Newbie Question: When to use classes?
Quote:
Originally Posted by
ThermoSight
And I think OOP or its implementation may even be a bit insulting to the programmer ... Ada for instance (or at least the version we used) refused to let programmers manipulate bits, thinking it was WAY too difficult for programmers to understand the concept of an 'AND' or 'exclusive OR'. And apparently the C# language designers still believe that pointers are far too difficult for mere programmers (Oh! the poor dears) with their severely limited mental capacity for understanding.
I think you're looking at it from the wrong angle. I don't think they decided to ban pointers from C# because they felt the programmers will not be able to understand them, but because they wanted to make an inherently safer system/language. When you design a class that is to be used by other devs, it's better to do your best to prevent (by design) any possibility of misuse (that could crash the app) than to have good faith all the people using your class will understand and follow all the relevant rules, and be consistently disciplined about it. Same goes when you design a language.
For example, I have no doubt that you understand pointers perfectly well, but even so, how often you simply forgot to delete something, or had some otherwise ephemeral bug in your C++ code? (At least before you've developed a set of personal coding practices. But even then?) I'm not saying C++ is bad - It's just that the two languages had different goals in terms of design.
P.S. BTW, there are pointers in C#, but are only allowed in what's called an "unsafe context" (a bit unfortunate name, I might add), and are somewhat less powerful than their C++ counterparts.
Re: Newbie Question: When to use classes?
Sure. The pyramid gets bigger as each address gets exposed. Doesn't matter if it's the latest game, a website, or the OS.
If you can point to it/bypass it with one statement, then that could be the END function, in some cases
Re: Newbie Question: When to use classes?
"BTW, there are pointers in C#, but are only allowed in what's called an "unsafe context" (a bit unfortunate name, I might add), "
Hello again, C ...
Yeah, I'm familiar with the unsafe context but I am, sadly, a product of my education however meagre and/or unsavory, and while that may have included mention of the "unsafe context", little practical use was made of it. Consequently, to this day I virtually never use it in my day to day activities. For me, it remains a dingy little sideshow in the vast panoply of structure and beauty that is OOP and Microsoft's C++/C#.
Still, it always seemed to me that the C# language designer could better have expressed his revulsion and abhorrence of pointers, and his conviction that decent, respectable programmers should have nothing to do with pointers (and indeed, are very likely intellectually incapable of using pointers) by giving the context a more dramatic name like, say, "Fraught with Peril context" or "Here be Dragons context" (grin).
Best wishes to you, Sir; hope all goes well for ya.
Old Fool
Re: Newbie Question: When to use classes?
Quote:
Originally Posted by
ThermoSight
Best wishes to you, Sir; hope all goes well for ya.
I'm honored to be referred-to as "Sir", but I feel that I have to wait a good amount of years before I can even begin to think I deserve such a title - furthermore, I should probably address you as Sir, and from what I've read in the post above, your experience certainly warrants it.
But, I like to keep a more friendly tone, I hope you don't mind; I feel that the discussion is more relaxed and fluent that way.
Quote:
Originally Posted by
ThermoSight
Still, it always seemed to me that the C# language designer could better have expressed his revulsion and abhorrence of pointers, and his conviction that decent, respectable programmers should have nothing to do with pointers (and indeed, are very likely intellectually incapable of using pointers) by giving the context a more dramatic name like, say, "Fraught with Peril context" or "Here be Dragons context" (grin).
LOL :)
But, again, I don't think the designers (I think it was a team) felt revulsion towards pointers - the main thing is that C++ and C# were designed with different goals in mind. C++ is more about power and speed, and pointers fit in that world perfectly. C# was designed with the "Age of the Internet" in mind, connectivity and XML being a big deal in that world, and features like reflection and garbage collection. Also, notice how compiler error messages are significantly less cryptic in C# - it's just beautiful.
Now, keeping all the design goals of C# in mind, you can see how "raw" pointers might become a problem - to quote Eric Lippert:
Quote:
Originally Posted by Eric Lippert in his blog
(link)
We also want to avoid some of the optimization nightmares that languages with pointers have. Languages with heavy use of pointers have a hard time doing garbage collection, optimizations, and so on, because it is infeasible to guarantee that no one has an interior pointer to an object, and therefore the object must remain alive and immobile.
(Note: Eric Lippert is a senior software design engineer at MS, where he assisted with the design and implementation of C#, among other things. BTW, that article might shed some more light on both references and pointers in C#, and the reasoning behind the design of the language.)
Quote:
Originally Posted by
ThermoSight
Consequently, to this day I virtually never use it in my day to day activities.
Actually, I think most C# developers rarely use them (if ever). What does that tell you? That you can manage without them just fine, using references instead. You must have seen C++ implementations of smart pointers or reference-counting pointers before - this directly resulted from the need to focus on the actual app, rather than being constantly concerned with the implementation details and language intricacies. As for C# pointers, I believe I've seen them used when performance is critical, maybe in some graphics-related applications and the like.
So, the way I see it, the design is guided by the end goals, and the nature and complexity of the tasks the language is supposed to be a tool for solving. There are low level languages, there are high level languages. Some are not OO, some provide support for OO, some are more OO, and some are "hardcore" OO... All of them have their advantages and drawbacks. I personally feel most comfortable somewhere between the two extremes.
Re: Newbie Question: When to use classes?
Quote:
Originally Posted by
ThermoSight
Still, it always seemed to me that the C# language designer could better have expressed his revulsion and abhorrence of pointers, and his conviction that decent, respectable programmers should have nothing to do with pointers
But C# does have pointers. They're a core part of the language that you use without even realising. Classes are pointers to memory locations on the heap. Consider this:
Code:
public class Foo
{
int a, b, c, d;
}
public struct Bar
{
int a, b, c, d;
}
public Foo SomeMethod (Foo f)
{
Foo x = SomeOperation (f);
return x;
}
public Bar SomeMethod (Bar b)
{
Bar x = SomeOperation (b);
return x;
}
Do you understand the difference between what happens when you pass the struct to the method and when you pass the class? In the former you end up copying 4 * sizeof (int) bytes, for the latter you copy 1x sizeof (void*). Obviously copying 16 bytes is a lot slower than copying 4 (or 8) bytes so by using pointers as a 1st class citizen of the language you can retain the performance of pointers with no penalty to type safety. The result of this is that it's now impossible for a developer to have a bug where they cast a pointer of type X to incompatible type Y. That's one entire class of bugs gone.
People like to harp on about "oh look, C# has no pointers, it must be crap" but when you think about it, they're not gone at all. They're just safer and less obvious. You can always do things using the unsafe keyword and take pointers to whatever you want. It's called unsafe not because the designer of C# hates pointers, it's that all guarantees about type safety and array bounds checking are gone. That's an entire class of bugs *reintroduced* when you take an unsafe pointer. These are bugs which are impossible to have in a normal application.
Then you have to take into account the 'ref' and 'out' keywords. They all you to, in a type safe way, pass a pointer to a struct. These C# and C functions are identical:
Code:
public void Foo ()
{
int value = 0;
FooImpl (ref value);
Console.WriteLine (value); // prints 1
}
public void FooImpl (ref int value)
{
value ++;
}
Code:
void Foo ()
{
int value = 0;
FooImpl (&value);
printf ("%d", value); // prints 1
}
void FooImpl (int *value)
{
*value ++;
}
The biggest difference is that in C# you *know* that a value passed by ref can never be null. In C your pointer can be null and in this case your entire app will crash.
So the point of this post was to say that pointers really do exist and you're using them all the time, they're just safer and better ;)
Re: Newbie Question: When to use classes?
Quote:
Originally Posted by
Mutant_Fruit
But C# does have pointers. They're a core part of the language that you use without even realising. Classes are pointers to memory locations on the heap.
Well, yeah - at least in the sense that the same reference/dereference capabilities are supported. But most people insist on the difference between the C# references and traditional pointers precisely for the reasons you stated. How exactly C# references are implemented under the hood is irrelevant, what matters is what they actually mean and how they differ from pointers sensu stricto.
To quote Eric Lippert again:
Quote:
Originally Posted by Eric Lippert on his blog:
Pointers are strictly "more powerful" than references; anything you can do with references you can do with pointers, but not vice versa. I imagine that's why there are no references in C -- it's a deliberately austere and powerful language.
[Emphasis in original]
Here's a link to that article, it discusses references and pointers, and the semantics of references, if you're interested.
Re: Newbie Question: When to use classes?
Quote:
Originally Posted by
ThermoSight
I began with C in the late 70s and as a result of a number successful projects in C and/or assembler, I was reluctant to embrace OOP when first exposed to it many years later (Ada back in the early 90s) thinking that its passion for secrecy (referring to encapsulation, access levels, etc) was paranoiac at best, and sheer madness at worst.
Seems like we came from approximately the same background. I, too, had difficulty embracing OOP for a long time.
Quote:
Another difficult thing for me was the strict type-discipline .... occasionally a little on the demeaning side if you ask me. God Bless FORTRAN's EQUIVALENCE statement !
Amen, brother! ;-)
Quote:
But over the years, while still believing the OOP conceptualists must be a little twisted (and I would certainly hate to meet them in a dark alley), I have come to see the beauty in this new organization of data and functions (being a C purist, I refuse to call them 'methods'). I now embrace the richness of the OOP paradigm which is really saying something coming from an old troglodyte such as I. And I really do love Microsoft's C++ and c#. Now ... The first few years however, coming from a C/FORTRAN/Assembler background, were very painful.
Again, I completely parallel your experience here. However now that I've "seen the light" of OOP I don't know if I could go back to doing it any other way, at least not when creating anything of significance. After learning proper OOP and C# (having written C for 20+ years, VB for 10 more) I'm finding myself pulling off things that would have taken, perhaps 10 times as much effort. The OOP paradigm has helped me stay extremely well organized in a product I'm presently developing. Could I have pulled all this off without it? Yeah, but I just don't think it would be quite as elegant.
Quote:
So you ask if one should always use classes ... perhaps not when working with the most trivial applications. But from the pragmatic perspective, with VS 2010 (or 8 or whatever flavor of Visual Studio you have), one is working in an OOP milieu. That IDE is designed with OOP in mind and I can't help but think one's life would be much easier if one chose to "go with the flow" and employ OOP. When in Rome, do as the Romans do.
Well said. Precisely.
-Max :D
