If you want to have an object with a FirstName and LastName attribute, create and object like that, with two private string members and two public properties. If you then need a FullName property, create a new readonly property and return the concatenation of the two former; do *not* use any padding in your object.
I can agree that an object in the business realm is the correct way to go. But what's to say the converter you mention in the next paragraph can't be an object with property accessors to a character buffer?
\> When you're ready to persist your object to a legacy system, *only then* use padding, but not in your object; implement a converter object for this purpose that is capable of taking an instance of your object and spit out a stream or a big string that contains padded data. Pass this to another object or function to actually persist it to a file.
I can hardly imagine a single valid reason (except hardware handlers) where you'd need to have a padded in-memory representation of *any* read/write property value. What happens to the data when your client wants to change the max length of FirstName? Do you update all your code? What happens if you forget to update just a single place and it makes into production? Do you go back to your storage and update all the data to match the new length? What kind of client is that where you can do that to production data just like that?
I don't think issues like the valid length of the string are hardly issues at all, that can be moved out to a configuration file of sorts. Besides, if it's a legacy system with existing applications, how a change in the length affects this application is the least concern.
If you're reworking an old system you might as well do it right. Trying to imitate COBOL behavior is certainly wrong in any object-oriented language, Java and C++ included.
Isn't it more that C# enables object oriented practices? Sure the .NET Framework is object oriented, and we design objects by default, but why does that bind us into striving to being the best of object oriented programmers, and if the solution proposed is not OOP in concept and design then it's deemed wrong? These are more of comments than questions, because I can't agree with those conclusions. Nonetheless, I am understanding the main principle here of why this solution is needed in the first place, and that the OOP concepts mentioned so far is the way to go, and if a need to persist in a fixed length format is needed, then that's achievable through a utility class to write in that format. Ron =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
