I would have thought that the answer to this would be easy to find in S.O. or the internet, but I have not been successful. From what I have read so far, my current understanding is just 2 levels - the outer class and then any number of inner classes at level 2.
It appears you would like to continue to organize your code in a series of collapsible "regions", but you would like to prevent simple plain text from being used for naming.
Classes could be used for this but unless you convert all the functions and methods to Shared, they won't be accessible unless these classes are instantiated first. Plus, this isn't really what classes should be used for. I would suggest using Namespaces.
Namespaces are used to separate the naming of functions and methods so multiple with the same name can exist within the same project without issues. They must each have their own namespace which must be specified when referencing the function/method in code (e.g. NamespaceName.FunctionName).
Related
What is the difference between Type-pool and creating a class for constants?
What is better?
My question is for a large group of constants and to be accessible to other groups.
Thank you
EDIT - Thank you for the answers and I will improve my question. I need something to store constants and I will use them on programs or other classes. Basically, I wanted to know if it is better to use a type-pool or a class with constants (only). I can have more than one class or type-pool.
The documentation mentions this:
Since it is possible to also define data types and constants in the public visibility section of global classes, type groups are obsolete and should no longer be created. Existing type groups can still be used.
A sensibly named interface with the constants you desire is the way to go. An additional benefit is that ABAP OO enforces some more rules.
Agree with #petul's answer, except for one detail: I'd recommend creating one enumeration-like class per logical group of constants, instead of collecting constants in interfaces.
Consider using the new enum language feature for specifying the constant values.
Interfaces can be accidentally "implemented", which doesn't make sense here. Classes can prevent this with final.
Making one class per logical group simplifies finding the constants with IDE features such as Ctrl+Shift+A search in the ABAP Development Tools. Constants that are randomly thrown together into interfaces are hard to find later on.
Classes allow adding enumeration-like helper methods like converters, existence checks, numbering all values.
Classes also allow adding unit tests, such as ensuring that the constant collection is still in sync with the fixed values of an underlying domain.
I apologize in advance if this is a "downvotable" question but I really need help in understanding how to know what to make classes out of in a VBA project.
NOTE: I am not asking how to code a class. I am asking how to determine what to make a class for.
Example
I want to draw shapes on a PowerPoint slide. 2 of the 3 kinds of shapes I need to draw have the same properties and methods. Would I create one class called CShape or 3 classes: CCircle, CSquare, CRectangle? Furthermore, lines are considered shapes in PowerPoint. Should I add a CLine class or just lump everything together in CShape?
I have searched Google for Methodologies on determining classes in VBA and the like but can not find anything. Does anybody out there have a method or way they go about determining how to create classes for their projects (and the reasons behind it)?
Also, I am just getting into classes and interfaces and this is the first project I am using them in. Thanks!
UPDATE
I did find this: When to use a Class in VBA?
When you work with code that can be reusable, this is the perfect time to use classes.
You need to create classes that have procedure to handle errors and possible wrong entries. As much robust you can create your code, your class will work as you expect.
I worked with PowerPoint and build some classes to manipulate document properties, another to manipulate slides, another to resize shapes.
You can find several classes examples from Chip Pearson site and you can figure out how to make your own classes.
http://www.cpearson.com/Downloads/Downloads.aspx
Hope this helps.
VBA (which is almost the same as Visual Basic 6) doesn't support inheritance.
So you have some options, using Interfaces would the normal way to deal with this, so probably three classes each on which implements the IDrawable interface. You may want to have a base class that deals with these features and have the outer classes call down to the base.
IDrawable might have public members for drawing, position, color and penwidth with the other parameters being part of the individual classes.
In particular you should read up on the Liskov substitution principle. I've seen examples of it using rectangles and squares as examples of what not to do.
See this older question for example Is deriving square from rectangle a violation of Liskov's Substitution Principle?
I have been using VBA for over 20 years, and made very little use of class modules.
The most useful cases for me were to build classes representing some structured spreadsheets or complex text files (with logical rows spanning over several physical lines) you may have to query or browse.
You can then implement a .MoveNext method and some properties like .EoF, .Price, .Rate to read them sequentially, being able to reuse that class everywhere you use that specific input file 'layout', and having the complex logic encapsulated in the class.
There are some constants and enumerations in a project, and each one is used by some other classes.
As a design pattern, is it acceptable to create a class for constants and enumerations definition? Or is there a better way to define and use those constants?
It depends on the problem domain. Generally speaking it is rather standard practice to keep them in Java enumeration. The question is - how would you like to use those constants? I have such experience, that constants being hold in interfaces/enumerations are being duplicated and created over and over again due to lack of the knowledge of developers of past constants. In the result, there are many files as such Constants.java, BusinessLogic.java, AppConstants.java etc.. It causes big overwhelm over the purpose and then you don't know if the some constant, lets say APP_MODE should be used from Constants.java or AppConstants.java ?
One of the solutions is to keep those constants in one (or many?) properties files and inject thme using spring' #Value annotation.
You may group by using some prefixing, building groups separated by dot.
One of the advantages of the property files is that you keep one Java logic of using properties, but you still can provide property file (which may vary depending on application). A lot of flexibility, no redundancy.
Another solution is to create one Service to provide properties / constants from database. You can differentiate the values over diffrent environements, but that's another story.
If I were you I create a constant container class packege by package. Just span the logically coherent parts together. Otherwise you will increase the the coupling and dependency. And the most general constants (problem domain independent ones) take place in the utility package's constant container class.
Do you have any input on how to organize and name utility classes?
Whenever I run in to some code-duplication, could be just a couple of code lines, I move them to a utility class.
After a while, I tend to get a lot of small static classes, usually with only one method, which I usualy put in a utility namespace that gets bloated with classes.
Examples:
ParseCommaSeparatedIntegersFromString( string )
CreateCommaSeparatedStringFromIntegers( int[] )
CleanHtmlTags( string )
GetListOfIdsFromCollectionOfX( CollectionX )
CompressByteData( byte[] )
Usually, naming conventions tell you to name your class as a Noun. I often end up with a lot of classes like HtmlHelper, CompressHelper but they aren't very informative. I've also tried being really specific like HtmlTagCleaner, which usualy ends up with one class per utility method.
Have you any ideas on how to name and group these helper methods?
I believe there is a continuum of complexity, therefore corresponding organizations. Examples follow, choose depending of the complexity of your project and your utilities, and adapt to other constraints :
One class (called Helper), with a few methods
One package (called helper), with a few classes (called XXXHelper), each class with a few methods.
Alternatively, the classes may be split in several non-helper packages if they fit.
One project (called helper), with a few packages (called XXX), each package with ...
Alternatively, the packages can be split in several non-helper packages if they fit.
Several helper projects (split by tier, by library in use or otherwise)...
At each grouping level (package, class) :
the common part of the meaning is the name of the grouping name
inner codes don't need that meaning anymore (so their name is shorter, more focused, and doesn't need abbreviations, it uses full names).
For projects, I usually repeat the common meaning in a superpackage name. Although not my prefered choice in theory, I don't see in my IDE (Eclipse) from which project a class is imported, so I need the information repeated. The project is actually only used as :
a shipping unit : some deliverables or products will have the jar, those that don't need it won't),
to express dependencies : for example, a business project have no dependency on web tier helpers ; having expressed that in projects dependencies, we made an improvement in apparent complexity, good for us ; or finding such a dependency, we know something is wrong, and start to investigate... ; also, by reducing the dependencies, we may accelerate compilation and building ....
to categorize the code, to find it faster : only when it's huge, I'm talking about thousands of classes in the project
Please note that all the above applies to dynamic methods as well, not only static ones.
It's actually our good practices for all our code.
Now that I tried to answer your question (although in a broad way), let me add another thought
(I know you didn't ask for that).
Static methods (except those using static class members) work without context, all data have to be passed as parameters. We all know that, in OO code, this is not the preferred way. In theory, we should look for the object most relevant to the method, and move that method on that object. Remember that code sharing doesn't have to be static, it only has to be public (or otherwise visible).
Examples of where to move a static method :
If there is only one parameter, to that parameter.
If there are several parameters, choose between moving the method on :
the parameter that is used most : the one with several fields or methods used, or used by conditionals (ideally, some conditionnals would be removed by subclasses overriding) ...
one existing object that has already good access to several of the parameters.
build a new class for that need
Although this method moving may seem for OO-purist, we find this actually helps us in the long run (and it proves invaluable when we want to subclass it, to alter an algorithm). Eclipse moves a method in less than a minute (with all verifications), and we gain so much more than a minute when we look for some code, or when we don't code again a method that was coded already.
Limitations : some classes can't be extended, usually because they are out of control (JDK, libraries ...). I believe this is the real helper justification, when you need to put a method on a class that you can't change.
Our good practice then is to name the helper with the name of the class to extend, with Helper suffix. (StringHelper, DateHelper). This close matching between the class where we would like the code to be and the Helper helps us find those method in a few seconds, even without knowledge if someone else in our project wrote that method or not.
Helper suffix is a good convention, since it is used in other languages (at least in Java, IIRC rails use it).
The intent of your helper should be transported by the method name, and use the class only as placeholder. For example ParseCommaSeparatedIntegersFromString is a bad name for a couple of reasons:
too long, really
it is redundant, in a statically typed language you can remove FromString suffix since it is deduced from signature
What do you think about:
CSVHelper.parse(String)
CSVHelper.create(int[])
HTMLHelper.clean(String)
...
I recently had to write some code which parsed a file to set data in an object. As there were several objects and corresponding files involved here, I decided to separate the parsing code out.
So I then had one class for parsing the files, CommandFileParser, and two classes per file/object type: one for the actual object itself and one for the possible commands that may be used to set the data in the object. e.g. VectorDrawing and VectorDrawingCommands. The latter's methods would be called by CommandFileParser using reflection as it found them in the input file, and applied data to the former.
But to me this seems like a really messy way of doing it. I ended up repeating loads of boilerplate code doing stuff like dataobject.value = value in all the of -Commands classes. And I don't like having an auxillary class per main data class just to set the data.
Can anyone suggest any ideas for cleaner and more appropriately OO ways of doing this?
"I ended up repeating loads of boilerplate code doing stuff like dataobject.value = value."
The assignment statement isn't really "boilerplate". It's the most important statement you have; the fact that there are many means you're doing lots of important things.
However, other "boilerplate" could be anything. Could you provide examples of the specific boilerplate you object to?
If all of your commands just involve direct assignments, perhaps you don't need the command objects. Can you directly do reflection on the objects themselves and get rid of the command objects entirely?
Another possibility is that you have two classes of commands: One is directly implemented by the object, e.g., simple property setting, and the other that is implemented by external command objects, e.g., for commands that need to do calculations or set multiple properties. You do the same reflection as before, but just check two objects.
BTW, I like the idea of using reflection to look for commands. It makes it incredibly easy to add new commands.
I don't know about VB.Net, but in all OO language with which I'm familiar, the normal approach is for a mutable object to contain the methods that set its own attributes' values, rather than putting that work into a second class.
Is there some reason why you wouldn't put the methods in your current VectorDrawingCommands class directly in VectorDrawing instead, and eliminate VectorDrawingCommands completely?
Maybe you want each Class to inherit the CommandFileParser instead of separating it out.
Why couldn't you just use reflection to set the values of the fields or properties directly and remove the entire concept of the -Commands classes?