It is fairly easy to create ABAP program objects using the built-in statements. But what about dictionary objects? There are a lot of function groups related to DDIC, but which ones to use? Or classes perhaps?
Check the function modules RPY_* - they are rather complete and reliable (and RFC-enabled :-)).
One class you can use is CL_REBF_DDIC_TABL. Use the static method PUT_COMPLETE. For a function module have a look at DD_CREATE_TABLE but I've never used this before.
You might want to check the specific DDIC elements you want to create and have a look at the Plugins of SAPlink http://code.google.com/p/saplink/ or ZAPlink http://code.google.com/p/zaplink/.
Both support a variety of elements and show the usage of functions to create them.
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.
This question already has an answer here:
Generic Structs with Go
(1 answer)
Closed 8 months ago.
I know that Go doesn't have classes in the traditional OOP sense, but Go does provide a notion of interfaces that allows you do most of the OOP things you'd want to do.
BUT, does Go allow for something like creating a templated class? For instance, I'm reading through the source code for the container/list package. It defines a list and the list's associated methods. But in all methods, the values contained in the list are of type interface{} -- so, of any type. Is there any way to create a list that is constrained to only hold values of a particular type? int, string, Fruit... whatever.
Newer than gotgo, there's a code-generation-based package called "gen".
http://clipperhouse.github.io/gen/
gen is an attempt to bring some generics-like functionality to Go, with inspiration from C#’s Linq, JavaScript’s Array methods and the underscore library. Operations include filtering, grouping, sorting and more.
The pattern is to pass func’s as you would pass lambdas in Linq or functions in JavaScript.
Basically what #FUZxxl said.
Generics? Not at this time.
Templates? Not quite. There are third-party projects like gotgo which aim to add template
support by pre-processing files. However, gotgo is quite dead as far as I know.
Your best option is to use interfaces or reflection for the time being.
If you really want to use reflection, note that the reflect package offers a way to fill a typed function variable with generic (reflected) content. You can use this to use types the compiler
can check with your reflection based solutions.
The jQuery framework has a lot of functions which will either retrieve or mutate values depending on the parameters passed:
$(this).html(); // get the html
$(this).html('blah'); // set the html
Is there a standard name for functions which behave like this?
AFAIK, there is no "standard" name for a single function that acts both as a getter and as a setter. It's an idiom not very commonly used, but it's possible in some languages, and as long as it's well documented, there's no harm in using it.
Some call it a property.
Is there a standard name for functions which behave like this?
Getters and Setters.
EDIT:
I just realized that you want a single function to do this. The technical term for this is a bad idea. Unless your language provides properties, trying to rig up a single function to do this is very unreadable.
I asked a fellow colleague yesterday if a function has too many parameters whether it would be better to create a class with properties instead. Are there any guidelines that I can follow?
I think that might depend on the language you are using, and the number of parameters in question, and are some of them allowed to be left out when calling the function.
VB has optional params, and C#3+ will allow for instantiation using params.
Will the new class have any other use except running that function, or will the state of that class be relevant later in the code?
When the number of parameters exceeds 5 I usually start thinking about refactoring the method. There's no absolute number, but this is my general rule. It may make sense to group the data in a data class, or sometimes it means that I should move the method to be closer to the data.
It all depends on the context.
Eg.
If it is not a database operations we can do as per the design of the system. Break the module and try to create sub modules.
If it is a database system I always prefer to write a separate bean class for the Fields and DAO class for operations.
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?