C# App - Best practices question: OO design/code placement

[maxx233]

Hello all,
I'm new to OO design and have a question regarding where I should place some code. Here's a simplified situation:

I'm making an app to do create, submit, and track employee reviews within our organization. Should I have a class called Review, with properties for things like "review date", "employee being reviewed", etc?.. And methods for things like submit(), generateReport(), delete(), etc? I don't really think I *need* an object of this type, I don't need to pass it around within the program, I can't think of any reason I'd ever use this sort of thing later in a different program... it just needs to be submitted straight to a DB from a specific form within my app. And then specific information from that DB will later be used to fill in other parts of later forms.

Should I still make an object just for the sake of feeling more like an OO programmer, or should I be approaching it from an angle I'm not seeing that makes more OO sense? Or should i just do it the way that makes sense to me now by not creating an object, and just taking the info directly from the text fields in my form, straight to a DB, and later pulling the exact info I need from that DB to whichever form needs it at the time?

Also, whichever method I end up using to submit the review to a DB (either straight from text fields or into an object first that has a submit() function), should I hardcode all my DB code in every method in my app that ends up needing it? My last project I made a static DB(string query) method in app.Program.cs that had all my DB code and took a string as a parameter, which it then used as a query string with the DB code it had to make the connection and execute that query string. I don't know if that's what people normally do, if it's bad practice, etc. etc. ... I know that I don't like that way of doing things because if I were to create a Review class, it wouldn't be self contained - it would have to call to app1.program.DB(string) to function, so if I ever used that class in another app it wouldn't work unless I filled in the missing portion of that app's Program file. But I *do* like this way of doing things because if I need to change something in the way my program accesses the DB (or *which* DB it accesses), it's in a central location and takes 5 seconds to change the entire way the program handles DB work. Is there a better way? Im interested to hear people's thoughts who have more experience than I when it comes to oo design. Let me know what you think, or if I didn't explain things well enough. It's much appreciated, thanks!

Maxx

[RedSon]

Hello all,
I'm new to OO design and have a question regarding where I should place some code. Here's a simplified situation:

I'm making an app to do create, submit, and track employee reviews within our organization. Should I have a class called Review, with properties for things like "review date", "employee being reviewed", etc?.. And methods for things like submit(), generateReport(), delete(), etc? I don't really think I *need* an object of this type, I don't need to pass it around within the program, I can't think of any reason I'd ever use this sort of thing later in a different program... it just needs to be submitted straight to a DB from a specific form within my app. And then specific information from that DB will later be used to fill in other parts of later forms.

Should I still make an object just for the sake of feeling more like an OO programmer, or should I be approaching it from an angle I'm not seeing that makes more OO sense? Or should i just do it the way that makes sense to me now by not creating an object, and just taking the info directly from the text fields in my form, straight to a DB, and later pulling the exact info I need from that DB to whichever form needs it at the time?

Also, whichever method I end up using to submit the review to a DB (either straight from text fields or into an object first that has a submit() function), should I hardcode all my DB code in every method in my app that ends up needing it? My last project I made a static DB(string query) method in app.Program.cs that had all my DB code and took a string as a parameter, which it then used as a query string with the DB code it had to make the connection and execute that query string. I don't know if that's what people normally do, if it's bad practice, etc. etc. ... I know that I don't like that way of doing things because if I were to create a Review class, it wouldn't be self contained - it would have to call to app1.program.DB(string) to function, so if I ever used that class in another app it wouldn't work unless I filled in the missing portion of that app's Program file. But I *do* like this way of doing things because if I need to change something in the way my program accesses the DB (or *which* DB it accesses), it's in a central location and takes 5 seconds to change the entire way the program handles DB work. Is there a better way? Im interested to hear people's thoughts who have more experience than I when it comes to oo design. Let me know what you think, or if I didn't explain things well enough. It's much appreciated, thanks!

Maxx

Maxx,

I think you have the main idea behind OO programming. However it does not make sense to make an object just because you can. If there is a need for the object then you should make it.

[maxx233]

Thanks! I was kinda figuring, but I see so much about emulating real objects (a piece of paper report) with code objects that I just wasn't quite sure if good design dictated to do it anyway.

Any thoughts on the DB code placement? Inside each method that needs it or centrally? If centrally, then is Program.cs the best place to put it, or is there a better way? Thanks a bunch!

Maxx

Maxx,

I think you have the main idea behind OO programming. However it does not make sense to make an object just because you can. If there is a need for the object then you should make it.

[RedSon]

Thanks! I was kinda figuring, but I see so much about emulating real objects (a piece of paper report) with code objects that I just wasn't quite sure if good design dictated to do it anyway.

Any thoughts on the DB code placement? Inside each method that needs it or centrally? If centrally, then is Program.cs the best place to put it, or is there a better way? Thanks a bunch!

Maxx

You can put your DB code in each method but if you are putting several copies of the same code in each method then that would be a good candidate for making a new helper method.

Let your program dictate its form a structure. Don't make an object unless you see a need for it. Don't make a method unless you see a need for it. When you are working with small programs you can work from this sort of bottom up design. Small programs are great because you can try lots of different things and it won't take you weeks to refactor the code. For example you can build the entire program in one main method, then you can look at it again and think of ways to improve. So now you have a program with a few methods, then you look at it again and think, hey I could encapsulate this in a couple classes. So then you refactor yet again. Eventually you will get an eye for these kind of optimizations.

This type of iterative improvements will be a very big help to you when it comes time to design a complicated system months before any coding actually begins. This is why software people get paid so much; if you can become a good designer it's like becoming a good architect you will be able to create this complicated and gigantic thing that won't fall down and kill people.

[maxx233]

heh, good analogy :) Thanks a lot, I appreciate it!

Maxx