OOP Best Practices

My first two programming jobs have been working on products that were largely designed and written by procedural programmers. Despite all the schooling on OOP, I am still a little shaky on some of the 'correct' ways of doing things. Here is my question of the day:

My project has a database backend and is set up with several objects, most of which contain 20 or more properties. If I am working on a particular screen (web page in this case), and I need one or maybe two fields from a particular object, is it worth the extra overhead to instantiate the entire object, filling all 20 or so fields, just to grab that one that I need? Or is it better to just write a simple SQL statement and grab the data directly?

Thanks for your input!

The answer is that it depends. OOP isn't necessarily the "correct" way to program, it's a programming model that allows for more extensibility and easier reuse of components.

If you just need to create a page that displays a couple of fields from a database table, it's generally easier to just pull out those two fields and display them. If you're going to work with the data and do a lot of stuff with it, then it would probably save you a bunch of trouble to create some objects and then add methods to them, but if you're just pulling data to show on a screen, it's not necessary.

Another consideration is whether the initial design separated database from UI. If there were classes for dealing with the database, and those classes served up the data, then there would be a long-term cost in maintainability if you simply bypassed the structure to fill a special need. At that point the structure becomes "These classes interact with the database....along with the occasional other item whenever somebody felt it was convenient."

Is this not what partial classes are all about, basicly you make loads of little partial classes into one big database class, that way you only have to use the parts of the class you need when creating the object.

You can call a method which returns that object with just those few required fields populated.

Partial classes are all part of the same class, so in the end they compile as the same object. The advantage of partial classes is that you can separate out bits that you may not touch (like designer code) or it allows different developers to work on the same class in a solution.

Can you not instantiate a partial part of a partial class as its own object?

You can have a file1.vb

vb Code:

Public Class CodedFire
 
Public Function GetJoinDate() As String
Return "Aug 07"
End Function
 
End Class

And in file2.vb,

vb Code:

Partial Class CodedFire
 
Public Function GetLocation As String
Return "In Cog Neato"
End Function
 
End Class

Now when you instantiate CodedFire, all of the methods and properties from all of the partial classes for CodedFire from all over the place are given to you in a single object.

Wow thats not how i understood them at all, well it is but i also thought you could use the partial part as a seperate class.

Thanks mendhak

No prob, and now you see how the new 'designer.vb' concept works. Visual Studio places the declaration of the objects on your form/web form in the designer class so that you don't have to deal with it.