How to decide on creating classes in an application..?

I am having some serious problem here. When do we need a class exactly?

Specifically, I thought of designing an desktop application that will be able to generate a profiling test or a unit test for any number of methods i specify. I was having a simple list for storing the methods. I did not think of having a class. But now, I thought of creating a class to store all the classes and gets the set of methods in the class. If this idea is correct, my last 4 days of eff开发者_如何学Cort is nullified. So putting up a new question if i can get some information.

Also I could not find the head or tail in my approach. So wanted to discuss with anyone who are interested in helping me with the design.

In general the rule to define the boundaries of a set of data and functionality to be moved into a class of their own is the single responsibility principle.

In Martin Fowler's excellent refactoring bliki you will find lots of patterns to move responsibilities, data and functionalities between classes (the obvious Extract Class, of course, but with the powerful aid of Extract Method and, in your case, Encapsulate Collection, maybe).

TDD is a good way to outline the design very early. Usually "easy to test" leads to "decoupled" and thus to separation of concerns.

Using both these approches together (TDD+Refactoring) may help you with the transition from a design to another: things should go a tad more smoothly.

And another excellent guideline is DIYDI (do it yourself dependency injection).

Also: are you going for code generation or runtime analysis here?

In the first case you might be interested in template engines which might save you a lot of work in the post-processing phase.

In the second case you might use Aspect Oriented Programming and/or Reflection to inspect the classes and find out what methods they have.

Please read this text by Grady Booch et al to get started into Objected Oriented Design.

Design can be quite difficult, and until you get some experience you are going to make bad choices, so write tests to make it easier to refactor your code. I would recommend reading, Code Complete. However since you probably want to get started right away and you question is directly asking about OO and classes I also recommend reading Uncle Bob's Blog post

http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod

Hope this helps

In a simple statement - If you have any data on which operations has to be performed, then you need a class. Good example for these are data containers like linklist, vector, .... This is known as Object Based programming and is the first step of class designs.

The next step is Object Oriented (Inheritance, Polymorphism), the Proficiency for this comes with experience and looking at well designed codes.

If your application is not reusable (which is implied by the "desktop application") it is pretty much up to you to decide the granularity of your objects.

As long as you are fine with having (or not having) an additional classes there is no reason to change that.

If you are looking for principles for OO (object oriented design) there is plenty of literature and weblinks available.