Joe,
Just one guy's opinion on these.
1) I find Get/Set methods to be excessive overhead. You are effectively doubling the size of the interface which I think is bad. I like the simplicity of being able to set properties by putting them on the left side of an = and getting them by using them on the right side. Most Java folks greatly disagree on direct access to properties (but then they are Java programmers so who cares? *LOL*)
2) I agree it's horrible to have tons of code executing inside an access/assign, that much code deserves real method. I use assign methods to do things like insure path properties have a trailing \ so the rest of my code in the class doesn't have to constantly keep checking for it. I have rarely used access methods.
3) Tons of parameters to Init() are bad because you can't work with the class in a design-time containership environment, ie you can't drop an instance of the class in another or on a form and use it because its Init() won't ever be called with parameters. If you use a property based interface you can use the class both ways. I also find it to be clearer code to read where several properties are set and a method is called, than sending a boatload of parameters to a method. I like putting a description on every property so that you can read the info while working with the class/object on the property sheet if the property name alone isn't quite enough to tell you how to use it. In the long run it takes a few more lines of code but maintaining the code is easier.
I'm sure others will chime in here with arguments countering mine. It all boils down to what way you and your team want to go. Choose one way or the other and just use it consistently. Also don't be afraid to go back and do a bit of reengineering if you find down the road that for your needs
>I had a few questions concerning how to manage OO methodology:
>
>PROPERTIES (with access/assign) vs. METHODS --
>
>The programmer I replaced was VERY fond of properties and of using access/assign methods to do a lot of heavy lifting behind the scenes. At first I thought, "Cool!", but I am now thinking, "Ugh!" every time I have to work on that code.
>
>Here is an example. We need to convert from file number fo file ID. Here would be the property-driven way of doing it:
>
>- Have an object with two properties, FileNum and FileID.
>- Set up assign methods on these two properties.
>- In FileNum's assign method, calculate the FileID and store it to FileID.
>- Get FileID by accessing the FileID property.
>
>Alternatively, with methods/parameters:
>
>- Have an object with two properties, FileNum and FileID (though you wouldn't really even need them), and method GetFileID(filenum AS parameter).
>- Call the GetFileID(filenum) method of the object and get back FileID. Optionally, you could even store the FileID in the FileID property, though that seems like going a bit too far.
>
>Over the years I have become a method man. I think they are more readable, more flexible, and more easy to change in complex systems. I guess I basically need to know where to draw the line when it comes to access/assign methods. Should they be used solely for data integrity and scrubbing purposes? How is everyone else using them? I fear I am missing something, as a lot of my objects just end up being glorified function libraries! On to the next question...
>
>INIT vs. ASSIGNING PROPERTIES --
>
>I am also a big fan of the Init method. I tend to pass a goodly amount of parameters to my object's Init and have the Init store the properites. Alternately, one could create the object, then assign properites, and then call subsequent methods.
>
>Some Init parameters are obvious. If your object needs info just to get itself created, you have to pass it in. Should the rule be to just stop there? Any extra parameters should be assigned as properties? This kind of goes with the method question above, as there are times when I don't know whether to make a property or just have a data element be a parameter of a method. Any good rules of thumb to use for decisions like this?
