I have a class with nothing but a whole lot of Shared (Static) methods that do exactly that. These methods can be called from anywhere in your program, including Property.Get.
Class Person
Public ReadOnly Property FullName as String
Get
Return MyClassFullOfStaticMethodsOfAllKinds.FullName(mLast, mFirst, mWhatEver)
End Get
End Property
End Class
Jav
Jav:
I have a class with nothing but a whole lot of Shared (Static) methods that do exactly that. These methods can be called from anywhere in your program, including Property.Get.
Class Person
Public ReadOnly Property FullName as String
Get
Return MyClassFullOfStaticMethodsOfAllKinds.FullName(mLast, mFirst, mWhatEver)
End Get
End PropertyEnd Class
FWIW, this is NOT the object oriented way of handling things. A 'utilities' class which is just a dumping ground for miscellaneous functions is a throwback to procedural programming.
In my opinion, don't worry about creating a full name function at all. Thats just a display issue, nothing more. If you go down this route, what happens when later there is a need to display LastName, Firstname? You have to create another function. More testing, more maintence later.Andy,
I have to disagree with your statement that a 'utilities' class is a throwback to procedural programming. IMHO, the whole idea behind object oriented programming and other best practices is to avoid code duplication and hence avoid maintenance problems. If having a 'utility' class helps you avoid code duplication and hence lets you maintain code easily, then that is the route you should take.
The 'utility' class can have one function for each of the ways you want to show the name and it can be called by any class. Is there any better way to avoid code duplication than having a 'utility' class like this? This 'utility' class is a perfect example of avoiding code duplication and creating code that can be easily managed.
Cosmic Ovungal
Again, thats incorrect. One of the goals of OOP is NOT to reduce duplicate code. In fact, one of the critisms of OOP is that it can be HARDER to reduce duplicate code. The idea behind OOP is that you are modeling behavior. Sometimes that means you duplicate code. However, there are OO ways to reduce duplicate code.I have to disagree with your statement that a 'utilities' class is a throwback to procedural programming. IMHO, the whole idea behind object oriented programming and other best practices is to avoid code duplication and hence avoid maintenance problems.
If having a 'utility' class helps you avoid code duplication and hence lets you maintain code easily, then that is the route you should take.
You may need to factor common functionality into a 'helper' class, but even that class should have a clear purpose. Throwing random, unreleated, functions together into a single static class is never a good idea. Even in procedural C, you would at least group related functions within a similar file, you wouldn't just make something called 'utilities.c' and dump miscellaneous functions into it.
This route I'm a bit more comfortable with. You could have a PersonNameFormatter class, or something similar. Its only purpose though is to format names. Ideally, it would operate on objects which implement an interface which spells out the FirstName, LastName, etc. fields. But the class shouldn't worry about formatting anything else. I wasn't sure though which method you were talking about; a generic utilties that miscellanous unrelated functions get thrown into (which is almost always a bad idea) or a name formatter class. Its more the former that I have a problem with; the latter is more in the spirit of OOP.The 'utility' class can have one function for each of the ways you want to show the name and it can be called by any class. Is there any better way to avoid code duplication than having a 'utility' class like this? This 'utility' class is a perfect example of avoiding code duplication and creating code that can be easily managed.
Andy,
Thank you for your comments. I think you are right about code getting duplicated in OOP systems because we are modelling behaviour. And you are also right about having a definite purpose for the utility class instead of dumping miscellaneous functions into it. I stand corrected.
I had meant a general utilities class but I see what you mean. It is always better to have a group of related functions in a class which can be named in such a manner so as to reflect the commonality among the functions.
This is what makes this forum so useful. Healthy debates and discussions lead us to design better software.
Thanks once again,
Cosmic Ovungal
![Smile [:)]](/emoticons/emotion-1.gif)
),Copyright (c) Marimer LLC