I bet this is the dumbest question anyone could ever ask but I can't seem to wrap my head around this topic. I understand a Class is used to create an object (when you instantiate it) but what is confusing me is, "When do you know if it is viable to create a Class in a program?".
Say hypothetically your creating a program that gathers an input from the user (be it a name, a number or any other details), use those details to do some calculations and then storing all of it locally. Its basic but would you need to use a class to make the program smoother/faster or more maintainable?
Am I confusing myself?
EDIT: I am mostly using programs like Visual Studio and NetBeans IDE.
As you say a class is a construct that allows you to describe a type, which has properties methods and events on it.
In simple situations you can easily get away with not using classes, but in larger, more complex projects having a properly thought out object model makes things so much easier. Easier to maintain, extend, reuse, read.
It may feel like more work at the time (and in most cases it probably is), but it is definitely not wasted effort if you're creating something that will need to be supported.
In Java you don't have a choice: you can't write code that's outside of a class.
A class is a template for instances. It encapsulates state and behavior together into a single software component. You write programs by creating instances of classes that interact together to accomplish your goals.
would you need to use a class to make the program smoother/faster or
more maintainable?
I can't speak for C#, but in Java you don't have a choice. You either create a single class that does all that in a main class or you break it up into several classes that handle different parts of the problem (e.g. I/O, calculations, persistence, etc.) You have to have one or more classes.
You write classes and create objects from them because they map well to the kind of problems that you want to solve. They're either real objects that model physical things in the world (e.g. Person, Car, Bank, etc.) or reifications of ideas (e.g. PersonFactory, Account, etc.) You choose to write object-oriented code because objects model the problem you'd like to solve well.
Some problems lend themselves to functional programming. There are more than one way to write programs to solve problems.
here is a very simple / easy to understand Tutorial that will help you in learning / understanding C# especially Classes also look at Structs as well
C# Class Tutorial
Classes are primarily for us humans to help us organize code. They don't necessarily make software run faster on a computer. When I first learned about classes, I found it helpful to model "real-world" objects. For example, if I wanted to write a program that calculates the area and perimeter of geometrical shapes, I would create a simple Shape class which defines the abstract methods which do the calculations. Then I extend this class to create different kinds of shapes, say Circle, Square, and Triangle. By starting with simple applications of classes and through more programming experience, I have been able to gradually see other places to use classes.
For a simple program, like your example, to gather input from the user (name, number, comment), you can easily do this without creating a new class, excluding the fact that languages like C# and Java require a static class to put your main function inside. If you used a non-object oriented language like C, you could easily do it without a class.
For a simple class like you describe, in fact, it might seem like a little extra work to have to create the class (although it is probably negligible). However, that is only because you are referring to a small set of data.
The point where it gets useful to create classes is when you have many pieces of data. The class acts as a way to group that data together, and possibly store it locally as one. You can also add other related methods onto each class that are directly related to the class members.
When you app becomes more complex, say you need to keep track of customers, products, billing information (Credit Card, PayPal, ...), addresses (ship to, and billing), is when classes become extremely valuable in keeping each bit of information together as well as relating each of those larger "bundles" (classes) of information to each other.
You could have a customer who has an order who has a bill to and a shipping address. Each of these classes, itself has many fields inside of it. But you can relate the larger concept of customer to a target shipping address a lot easier with classes.
As far as "When do you know if it is viable to create a Class in a program?", the answer is not always easy, but any time you see data fields which naturally fit together (well, like an address, or a product description or billing information). I wish I had a more concrete answer, but it really depends on what you are building, and what type of data you are working with.
And no, it's not the dumbest question anyone could ever ask! I hope this helps your understanding.
1. When do you know if it is viable to create a Class in a program?
I think just about everyone who answers this question will have a slightly different response, but typically, you should use Classes to modularize your program's functionality. In your example, you said that your program might take input from the user, use input to perform some calculations, and persist the user data and calculation results somewhere. You could have the following three classes:
UserInput - handles keyboard input and converting it into some easier-to-process format
Calculator - processes all input after it has been converted
DataPersistence - handles reading/writing from/to disk, or database, or whatever you need.
This way, all of your code isn't just piled up inside a massive Java/C# main() call, you can focus on the smaller parts independently of each other. The interaction between these components is what determines your program's behavior.
2. Its basic but would you need to use a class to make the program smoother/faster or more maintainable?
Classes may actually end up adding overhead to your program because of how objects are referenced in languages like Java or C#, but they make your code much easier to read and modify than if your program was written inside one gigantic function. This is sort of analogous to dividing up math textbooks into chapters. If Algebra, Calculus, and Differential Equations were all condensed into a single chapter of the text book, then the text book wouldn't be very useful to those who want to skip ahead to the Calculus part. The overhead of adding chapter headings is negligible because it allows the author/reader to focus on certain portions of the book.
Likewise, Classes help you divide up your work so it's easier to maintain later. Speed/Performance are generally not affected by how you divide your program into classes, provided you do it intelligently - this is where the real artistry of Object Oriented Design manifests itself :)
Related
I wrote programs in procedural language (mostly VB6) since many years. Now I am learning C#. I read a couple of books and get things done but sometimes I ask myself: Should a method be in this class or in that class or somewhere else.
Here is an example: I write a console program which scans all files in a directory tree and will set NTFS security for all files according to some rules. For each “file type” (i.e. invoices, emails, Excel files) I have template files with the correct security settings.
My program does the following:
Read in the MyApp.exe.config where a log file should be written
Start the log file
Fill a list with details about the “file types” (currently hard coded)
Read in the MyApp.exe.config the locations and filenames of the template files from the above list
More steps
I have the classes Program with the Main method, FileWork which scans through the files, SecurityWork which sets NTFS security rights, and ApplConfig which reads and writes configuration information.
Now my question: Where should I put the method for my step 4 in above list? This concerns settings for the SecurityWork class which are read via the ApplConfig class. Should the method be in the SecurityWork class because it concerns the security settings, or should it be in the ApplConfig class because it reads information from the configuration file or should it be in the Program class? Technically all versions would work and I know how to write them.
I know there are OOP principles like Encapsulation and others involved. What I am looking for is not so much an answer to the above incomplete example but something like a set of questions I should ask myself to decide where methods which concern multiple classes should be.
Similar question were asked and answered before but most of the time I read answers like: you could do it like this or like that, it’s more or less up to you.
What do you suggest? Maybe a list with some questions, an article or a book?
To keep this question within the rules of Stackoverflow I am also happy to read an answer to the above example with an explanation of why it should be like this and not like that.
A short addition to this question: I think in many cases it is obvious in which class a method belongs. That is what I learned from books because they use often examples which are straight forward.
The “how do I do this?” happens only in some cases in which two or more classes are involved and the method could be in any of these classes and the program would work. The question is then: How would it work best? What is the best way to do this keeping future amendments in mind.
I appreciate already all the comments and answers up to now. Thanks.
Well, it's not really a question for stackoverflow, but I don't know where it would be better to ask it.
to your example the answer is to put the method for step 4 in the ApplConfig class, and have it send the values it's reading to the SecurityWork class.
Besides Encapsulation, there's this thing that's called the Single responsibility principle, that basically states that classes (and methods) should be responsible for one thing only.
Imagine a scenario where you want the location and file names to be stored in a database rather then in the app.config. By keeping the single responsibility principle all you have to change is one class and everything should work as it did before.
There are a lot of things to be said about the proper way to decide in which class a method belongs, but I think that this is probably one of the easiest to explain as well as understand, and it will give you the answer at least 80% of the time.
I would ask
Where will this have the lowest coupling to other objects?
Where can this go where it will have the fewest side effects (preferably no side effects)
Are there any useful patterns (see http://en.wikipedia.org/wiki/Software_design_pattern#Classification_and_list)
I work in development team of about 12 and we build a reasonable set of API's that we use on a strictly in-house only basis. Typically all classes and interfaces are public because that is just how they get done. I have often considered the value of making some of the constructors internal so that the consumers of the API (albeit internal) have to use the factory or some other reason that I can't think of now.
Is this something that you and your team practice?
How does this effect your unit tests? Do you find that it is okay to unit test a class through it's factory or do you access the constructor through something like PrivateObject?
The answer is yes; my current project has exactly one developer working on it - me - and yet I still use visibility and other access modifiers, along with more complex design patterns, as necessary. Here's why:
The compiler, if you let it, can be one of your greatest tools to enforce good design patterns. Making everything public can cause a lot of headaches down the road, when you have to maintain an object whose normal state during program execution is the object-oriented equivalent of a human living his life on an operating table with his chest cracked open and everyone who knows him from his children to his electric company poking around in his vital organs to get him to do what they want. Adding another hand, or removing one, can cause the patient to go into cardiac arrest.
Code should be self-documenting. A class or class member that is marked as internal means it probably should be; if everything's public, you don't know if there's anything you shouldn't touch when interfacing with the object. Again, you've got your patient sitting on the operating table, and all of a sudden a new guy comes in, grabs the liver and goes "hey, what does this do?". Objects should have their hands shaken, be told to do something and let go to do it, and the function of their liver is of no concern to anyone but them.
Code should be maintainable by your posterity. This ties back to the first two rules, but basically, someone should be able to open up your codebase, find the entrance point and trace through basic execution flow, all the while looking at objects utilized along the way and determining their general form and function. Back to our patient on the operating table, let's say five years from now someone walks in on this scene; a guy split open on a table with 50 guys in his guts. It's not going to look like any polite social custom he's ever seen; it'll probably look most like a ritual human sacrifice, and most people's first instinct when encountering such a situation is to run.
However, the flip side of the coin is that a design pattern implemented for its own sake is generally a Very Bad Thing. Once you graduate college and get your first job, nobody really cares that you know how to implement a Strategy pattern, and you shouldn't do so at the first opportunity just to say you did. Every pattern has a set of circumstances in which it applies. If you were a doctor, would you perform an angioplasty on the next patient who walked in just to say you were able to do it?
There is this famous quote that says
Procedural code gets information then
makes decisions. Object-oriented code
tells objects to do things. — Alec
Sharp
The subject of the post is precisely about that.
Let's assume we are developing a game in which we have a Game where there is a Board.
When facing the problem of deciding which methods are we going to implement on the Board class, I always think of two different ways:
The first approach is to
populate the Board class with getSize(), getPieceAt(x, y), setPieceAt(x, y, piece). This will seem reasonable and is what is generally found in libraries/frameworks. The Board class has a set of internal features that wants to share and has a set of methods that will allow the client of the class to control the class as he wishes. The client is supposed to ask for the things he needs and to decide what to do. If he wants to set all board pieces to black, he will "manually" iterate over them to accomplish that goal.
The second approach is about
looking for Board's dependent classes, and see what they are "telling" it to do. ClassA wants to count how many pieces are red, so I'd implement a calculateNumberOfRedPieces(). ClassB intends to clear all the pieces on the Board(set all of them to NullPiece, for example), so I'd add a clearBoard() method to the Board class. This approach is less general, but allows for a lot more flexibility on other aspects. If I "hide" Board behind an IBoard interface, and decide that I'd want to have a board with infinite size, doing in the first way, I'd be stuck, as I'd have to iterate over an infinite number of items! On the other hand, in this way, I could do fine (I could, for instance, assume all pieces are null other than the ones contained in a hashtable!).
So...
I am aware that if I intend to make a library, I am probably stuck with the first approach, as it is way more general. On the other hand, I'd like to know which approach to follow when I am in total control of the system that'll make use of the Board class -- when I am the one who is going to also design all the classes that'll make use of the Board. Currently, and in the future (won't the second approach raise problems if later I decide to add new classes that are dependent on the Board with different "desires"?).
The quote is really warning you away from data structures that don't do anything with the data they hold. So your Board class in the first approach might be able to be done away with and replaced by a generic collection.
Regardless, the Single Responsibility Principle still applies, so you need to treat the second approach with caution.
What I would do is invoke YAGNI (you aren't gonna need it) and try to see how far I could go using a generic collection rather than a Board class. If you find that later you do need the Board class its responsibility will likely be much more clear by then.
Let me offer the contrarian point of view. I think the second approach has legs. I agree with the single responsibility principle, but it seems to me that there's a defensible single mission/concern for a Board class: Maintaining the playing field.
I can imagine a very reasonable set of methods such as getSize(), getPiece(x,y), setPiece(x, y, color), removePiece(x, y), movePiece(x1,y1,x2,y2), clear(), countPieces(color), listPiecePositions(color), read(filename), write(filename), etc. that have a congent and clear shared mission. The handling of those board-management concerns in an abstracted way would allow other classes to implement game logic more cleanly, and for either Board or Game to be more readily extended in the future.
YAGNI is all well and good, but my understanding is that it urges you to not start building beautiful edifices with the hope that one day they'll be usefully occupied. For example, I wouldn't spend any time working toward the future possibility of an infinite playing surface, a 3D playing surface, or a playing surface that can be embedded onto a sphere. If I wanted to take YAGNI very seriously, I wouldn't write even straightforward Board methods until they were needed.
But that doesn't mean I would discard Board as a conceptual organization or possible class. And it certainly doesn't mean that I wouldn't put any thought at all into how to separate concerns in my program. At least YAGNI in my world doesn't require you start with the lowest-level data structures, little or nothing by way of encapsulation, and a completely procedural approach.
I disagree with the notion that the first approach is more general (in any useful way), or what appears to the the consensus that one should "just see how far you can get without abstracting anything." Honestly, that sounds like how we solved eight queens. In 1983. In Pascal.
YAGNI is a great guiding principle that helps avoid a lot of second system effect and similar bottoms-up, we-can-do-it-so-we-should mistakes. But YAGNI that's crossed the Agile Practice Stupidity Threshold is not a virtue.
CurtainDog is right, invoke Yagni and figure out what you actually need right now, implement that, then make sure it's not going to prevent any features that may be desirable in the future.
The second approach violates the principle that superclasses should not know about each of its subclasses. I think the element you're missing is that the base class can define template methods, like getBoardSize, countRedPieces, countBlackPieces, that can be overridden by subclasses and your superclass has code that uses those template methods, therefore telling its subclasses what to do, but not how to do it.
This may be a silly question (with MSDN and all), but maybe some of you will be able to help me sift through amazing amounts of information.
I need to know the specifics of the implementations of common data structures and algorithms in C#. That is, for example, I need to know, say, how Linked Lists are handled and represented, how they and their methods are defined.
Is there a good centralized source of documentation for this (with code), or should I just reconstruct it? Have you ever had to know the specifics of these things to decide what to use?
Regards, and thanks.
Scott Mitchell has a great 6-part article that covers many .NET data structures:
An Extensive Examination of Data Structures
For an algorithmic overview of data structures, I suggest reading the algorithm textbook: "Introduction to Algorithms" by Cormen, et al..
For details on each .NET data structure the MSDN page on that specific class is good.
When all of them fail to address issues, Reflector is always there. You can use it to dig through the actual source and see things for yourself.
If you really want to learn it, try making your own.
Googling for linked lists will give you a lot of hits and sample code to go off of. Wikipedia will also be a good resource.
Depends on the language. Most languages have the very basics now pre-built with them, but that doesn't mean their implementations are the same. The same named object--LinkedList in C# is completely different than the LinkedList in Java or C++. Even the String library is different. C# for instance is known to create a new String object every time you assign a string a new value...this becomes something you learn quickly when it brings your program to a crashing halt when you're working with substrings in C# for the first time.
So the answer to your question is massively complicated because I don't know quite what you're after. If you're just going to be teaching a class what a generic version of these algorithms and data structures are, you can present them without getting into the problems I mentioned above. You'll just need to select, lookup, read about a particular type of implementation of them. Like for LinkedList you need to be able to instantiate the list, destroy the list, copy the list, add to the list somewhere (usually front/back), remove from the list, etc. You could get fancy and add as many methods as you want.
The project I'm working on has just hit 4200 lines in the main C# file, which is causing IntelliSense to take a few seconds (sometimes up to 6 or so) to respond, during which Visual Studio locks up. I'm wondering how everyone else splits their files and whether there's a consensus.
I tried to look for some guides and found Google's C++ guide, but I couldn't see anything about semantics such as function sizes and file sizes; maybe it's there - I haven't looked at it for a while.
So how do you split your files? Do you group your methods by the functions they serve? By types (event handlers, private/public)? And at what size limit do you split functions?
To clarify, the application in question handles data - so its interface is a big-ass grid, and everything revolves around the grid. It has a few dialogs forms for management, but it's all about the data. The reason why it's so big is that there is a lot of error checking, event handling, and also the grid set up as master-detail with three more grids for each row (but these load on master row expanded). I hope this helps to clarify what I'm on about.
I think your problem is summed up with the term you use: "Main C# file".
Unless you mean main (as in the method main()) there is no place for that concept.
If you have a catch-all utility class or other common methods you should break them into similar functional parts.
Typically my files are just one-to-one mappings of classes.
Sometimes classes that are very related are in the same file.
If your file is too large it is an indication your class is too big and too general.
I try to keep my methods to half a screen or less. (When it is code I write from scratch it is usually 12 lines or fewer, but lately I have been working in existing code from other developers and having to refactor 100 line functions...)
Sometimes it is a screen, but that is getting very large.
EDIT:
To address your size limit question about functions - for me it is less about size (though that is a good indicator of a problem) and more about doing only one thing and keeping each one SIMPLE.
In the classic book "Structured Programming" Dijkstra once wrote a section entitled: "On our inability to do much." His point was simple. Humans aren't very smart. We can't juggle more than a few concepts in our minds at one time.
It is very important to keep your classes and methods small. When a method gets above a dozen lines or so, it should be broken apart. When a class gets above a couple of hundred lines, it should be broken apart. This is the only way to keep code well organized and manageable. I've been programming for nearly 40 years, and with every year that has gone by, I realize just how important the word "small" is when writing software.
As to how you do this, this is a very large topic that has been written about many different times. It's all about dependency management, information hiding, and object-oriented design in general. Here is a reading list.
Clean Code
SOLID
Agile Principles, Patterns, and Pratices in C#
Split your types where it's natural to split them - but watch out for types that are doing too much. At about 500 lines (of Java or C#) I get concerned. At about 1000 lines I start looking hard at whether the type should be split up... but sometimes it just can't/shouldn't be.
As for methods: I don't like it when I can't see the whole method on the screen at a time. Obviously that depends on size of monitor etc, but it's a reasonable rule of thumb. I prefer them to be shorter though. Again, there are exceptions - some logic is really hard to disentangle, particularly if there are lots of local variables which don't naturally want to be encapsulated together.
Sometimes it makes sense for a single type to have a lot of methods - such as System.Linq.Enumerable but partial classes can help in such cases, if you can break the type up into logical groups (in the case of Enumerable, grouping by aggregation / set operations / filtering etc would seem natural). Such cases are rare in my experience though.
Martin Fowler's book Refactoring I think gives you a good starting point for this. It instructs on how to identify "code smells" and how to refactor your code to fix these "smells." The natural result (although it's not the primary goal) is that you end up with smaller more maintainable classes.
EDIT
In light of your edit, I have always insisted that good coding practice for back-end code is the same in the presentation tier. Some very useful patterns to consider for UI refactorings are Command, Strategy, Specification, and State.
In brief, your view should only have code in it to handle events and assign values. All logic should be separated into another class. Once you do this, you'll find that it becomes more obvious where you can refactor. Grids make this a little more difficult because they make it too easy to split your presentation state between the presentation logic and the view, but with some work, you can put in indirection to minimize the pain caused by this.
Don't code procedurally, and you won't end up with 4,200 lines in one file.
In C# it's a good idea to adhere to some SOLID object-oriented design principles. Every class should have one and only one reason to change. The main method should simply launch the starting point for the application (and configure your dependency injection container, if you're using something like StructureMap).
I generally don't have files with more than 200 lines of code, and I prefer them if they're under 100.
There are no hard and fast rules, but there's a general agreement that more, shorter functions are better than a single big function, and more smaller classes are better than 1 big class.
Functions bigger than 40 lines or so should make you consider how you can break it up. Especially look at nested loops, which are confusing and often easy to translate to function calls with nice descriptive names.
I break up classes when I feel like they do more than 1 thing, like mix presentation and logic. A big class is less of a problem than a big method, as long as the class does 1 thing.
The consensus in style guides I've seen is to group methods by access, with constructors and public methods on the top. Anything consistent is great.
You should read up on C# style and refactoring to really understand the issues you're addressing.
Refactoring is an excellent book that has tips for rewriting code so that behavior is preserved but the code is more clear and easier to work with.
Elements of C# Style is a good dead tree C# style guide, and this blog post has a number of links to good online style guides.
Finally, consider using FxCop and StyleCop. These won't help with the questions you asked, but can detect other stylistic issues with your code. Since you've dipped your toe in the water you might as well jump in.
That's a lot, but developing taste, style and clarity is a major difference between good developers and bad ones.
Each class should do one small thing and do it well. Is your class a Form? Then it should not have ANY business logic in it.
Does it represent a single concept, like a user or a state? Then it shouldn't have any drawing, load/save, etc...
Every programmer goes through stages and levels. You're recognizing a problem with your current level and you are ready to approach the next.
From what you said, it sounds like your current level is "Solving a problem", most likely using procedural code, and you need to start to look more at new ways to approach it.
I recommend looking into how to really do OO design. There are many theories that you've probably heard that don't make sense. The reason they don't is that they don't apply to the way you are currently programming.
Lemme find a good post... Look through these to start:
how-do-i-break-my-procedural-coding-habits
are-there-any-rules-for-oop
object-oriented-best-practices-inheritance-v-composition-v-interfaces
There are also posts that will refer you to good OO design books. A "Refactoring" book is probably one of the very best places you could start.
You're at a good point right now, but you wouldn't believe how far you have to go. I hope you're excited about it because some of this stuff in your near future is some of the best programming "Learning Experiences" you'll ever have.
Good luck.
You can look for small things to change and change each slowly over time.
Are all the methods used in that class only? Look for support methods, such as validation, string manipulation, that can be moved out into helper/util classes.
Are you using any #region sections? Logical groupings of related methods in a #region often lend themselves to being split into separate classes.
Is the class a form? Consider using User Controls for form controls or groups of form controls.
Sometimes large classes evolve over time due to lots of developers doing quick fixes / new features without considering the overall design. Revisit some of the design theory links others have provided here and consider on-going support to enforce these such as code reviews and team workshops to review design.
Well, I'm afraid to say that you may have a bigger issue at hand than a slow load time. You're going to hit issues of tightly coupled code and maintainability/readability problems.
There are very good reasons to split class files into smaller files (and equally good reasons to move files to different projects/assemblies).
Think about what the purpose that your class is supposed to achieve. Each file should really only have a single purpose. If it's too generalized in its goal, for example, "Contain Shopping Basket Logic", then you're headed down the wrong path.
Also, as mentioned, the term you use: "Main C# file" just reeks that you have a very procedural mindset. My advise would be to stop, step back, and have a quick read up on some of the following topics:
General OOP principles
Domain-driven design
Unit testing
IoC Containers
Good luck with your searches.
Use Partial classes. You can basically break a single class into multiple files.
Perhaps the OP can respond: is your project using Object-Oriented Programming? The fact that you use the word "file" suggests that it is not.
Until you understand object orientation, there is no hope for improving your code in any important way. You'd do better to not split up the file at all, wait until it grows to be unbearably slow and buggy, then instead of bearing it any more, go learn OO.
The Intellisense parser in Visual Studio 2008 seems to be considerably faster than the one 2005 (I know they specifically did a lot of work in this area), so although you should definitely look into splitting the file up at some point as others have mentioned, Visual Studio 2008 may resolve your immediate performance problem. I've used it to open a 100K+ line Linq to SQL file without much issue.
Split the code so that each class/file/function/etc. does only One Thing™. The Single Responsibility Principle is a good guideline for splitting functionality into classes.
Nowadays, the largest classes that I write are about 200 lines long, and the methods are mostly 1-10 lines long.
If you have regions of code within a class, a simple method is to use the partial keyword and breakout that definition of the class into that file. I typically do this for large classes.
The convention I use is to have the ClassName_RegionName.cs. For example, if I want to break out a class that manages the schema for a database connection, and I called the class DatabaseConnection I would create a file called DatabaseConnection.cs for the main class and then DatabaseConnection_Schema.cs for the schema functionality.
Some classes just have to be large. That's not bad design; they are just implementation-heavy.