I have a class called PriceStep. I keep a list of PriceStep objects in a class called PriceStepSearchSpace. Now I am required to have different PriceStepSearchSpace objects for different products and I need to keep them in some sort of a dictionary. I called this new class PriceStepSearchSpaceRepository.
Can you think of a simpler/shorter name?
You could call it Repository and put it in a namespace called PriceSteps.Searchspaces.
I might call it PriceStepSearchSpaces if it was unlikely that I would have any other type of collection of those objects. Otherwise, I like Timwi's idea of putting related classes into a namespace to prevent duplication of prefixes.
I would go with SearchSpace for your first and SearchSpaceDictionary for the second.
There's no need to preface a parent class with it's child class name!
However, you may want to re-think your object model, it's hard to give advice about that based on the info you provided.
PriceStep. PriceSteps. PriceStepsByProduct.
Related
If I have:
<!--/*#thymesVar id="someCollection" type="java.util.List"*/-->
How would I specify the type of objects in the collection?
I don't see anything on SO or the Idea docs about it.
Oh, it's as simple as specifying the class in the declaration:
<!--/*#thymesVar id="someCollection" type="java.util.List<com.domain.my.Bean>"*/-->
I want to execute the method remove_column on an instance of cl_salv_column_table but because of its visibility level, I am not able to do so.
Plan:
I already tried inheriting from cl_salv_columns_list and then perform the call inside the remove-method:
CLASS lcl_columns_list DEFINITION INHERITING FROM CL_SALV_COLUMNS_LIST.
PUBLIC SECTION.
METHODS:
remove IMPORTING iw_colname TYPE string.
ENDCLASS.
But apparently my casting knowledge got rusty as I'm not able to figure out an appropriate solution.
This is my current hierarchy - the red arrows show the way I would have to take:
My approach looks like this:
DATA lo_column_list TYPE REF TO lcl_columns_list.
lo_column_list ?= CAST cl_salv_columns_list( lo_columns ).
But it fails with:
CX_SY_MOVE_CAST_ERROR
Source type: \CLASS=CL_SALV_COLUMNS_TABLE
Target type: "\PROGRAM=XXX\CLASS=LCL_COLUMNS_LIST"
Background:
My task is to select all columns of 3 tables (which would be done like SELECT t1~*, t2~*, t3~* ...) as long as their names don't conflict (e.g. field MANDT should only be displayed once). This would require defining a very big structure and kick the size of the selection list to a maximum.
To avoid this, I wanted to make use of the type generated by my inline-declaration. Hiding the individual columns via set_visible( abap_false ) would still display them in the layout manager - which looks really ugly.
Is there any other way to accomplish my target?
Use set_technical( abap_true ) to hide the columns entirely. As for your approach - sorry, inheritance does not work that way - in no statically typed object oriented language that I know. You can't 'recast' an instantiated object to a different class. You would need to modify the framework extensively to support that.
I have a program ZPROG1_TEST where I define a local class LCL_PROG1_HELPER.
I have a second program ZPROG2_TEST where I'd like to define a variable reference to this class.
Isn't there a syntactic possibility for me to do this?
Or could this be in theory doable with the RTTI classes like CL_ABAP_CLASSDESCR ?
EXTRA
Why I'd like to do this is because I have a custom form ZMM_MEDRUCK that needs to know if the ME32N Document it's printing has been changed but not saved.
I've figures out the exact objects whose properties I need to interogate, but some of them are defined at design time as common interfaces, like IF_SERIALIZABLE_MM, and I need to cast them to the local classes whose instances I know these objects are going to be, like \FUNCTION-POOL=MEGUI\CLASS=LCL_APPLICATION.
I could of course try a dynamic method call and not care about anything, but since i'm here i thought i'd ask this thing first.
You could do it like that.
REPORT ZPROG1_TEST.
INTERFACE lif_prog1_helper.
METHODS:
test.
ENDINTERFACE.
CLASS LCL_PROG1_HELPER DEFINITION.
PUBLIC SECTION.
INTERFACES:
lif_prog1_helper.
ALIASES:
test FOR lif_prog1_helper~test.
ENDCLASS.
CLASS LCL_PROG1_HELPER IMPLEMENTATION.
METHOD test.
WRITE / sy-repid.
ENDMETHOD.
ENDCLASS.
REPORT ZPROG2_TEST.
DATA: g_test TYPE REF TO object.
START-OF-SELECTION.
CREATE OBJECT g_test TYPE ('\PROGRAM=ZPROG1_TEST\CLASS=LCL_PROG1_HELPER').
CALL METHOD g_test->('TEST').
CALL METHOD g_test->('LIF_PROG1_HELPER~TEST').
As far as I know, this is not possible. Accessing the local class dynamically is easy (well, relatively easy), but referring to it statically - not as far as I know. You'll probably have to call the methods dynamically.
Looking inside the runtime.h, I found the definition of the structure objc_class.
Among various members, We have this :-
struct objc_method_list **methodLists
We definitely need to know what all methods a class has,
But a list of methods should be fine, but why do we have "lists" ?
Why not just one list ?
Also, can anyone specify that, Are methods inherited from superclass part of that list or we get to them via superclass pointer that points to parent class's structure.
Here is my detail investigation into struct objc_method_list **methodLists : http://blog.csdn.net/jasonblog/article/details/7303618
And in short, methodLists stores SEL-IMP mapping of the instance methods by default. In this situation, it has only one list.
As the name 'methodLists' suggests, it can contain more than one list. If you add a category to a class, the runtime system will insert one more list into methodLists, which points to the method-list of the category.
I tried to answer this question several months ago, but at that time SO discard my answer due to network problem. Now I meet it again :)
The purpose is explained in objc-class.m, as linked by Georg:
cls->methodLists may be in one of three forms:
NULL: The class has no methods.
non-NULL, with CLS_NO_METHOD_ARRAY set: cls->methodLists points
to a single method list, which is the class's only method list.
non-NULL, with CLS_NO_METHOD_ARRAY clear: cls->methodLists points to
an array of method list pointers. The end of the array's block
is set to -1. If the actual number of method lists is smaller
than that, the rest of the array is NULL.
Attaching categories and adding and removing classes may change
the form of the class list. In addition, individual method lists
may be reallocated when fixed up.
Classes are initially read as #1 or #2. If a category is attached
or other methods added, the class is changed to #3. Once in form #3,
the class is never downgraded to #1 or #2, even if methods are removed.
Classes added with objc_addClass are initially either #1 or #3.
The short answer is therefore "because of categories." When a category is injected, rather than try to combine its method list with the one existing list, a new entry is simply added to methodLists, and set to the list coming from the category. This probably makes category injection faster, since it avoids (potential) large reallocations and copying.
Is setX() method name appropriate for only for setting class property X?
For instance, I have a class where the output is a string of an html table. Before you can you can call getTable, you have to call setTable(), which just looks at a other properties and decides how to construct the table. It doesn't actually directly set any class property -- only causes the property to be set. When it's called, the class will construct strHtmlTable, but you can't specify it.
So, calling it setTable breaks the convention of get and set being interfaces for class properties.
Is there another naming convention for this kind of method?
Edit: in this particular class, there are at least two ( and in total 8 optional ) other methods that must be called before the class knows everything it needs to to construct the table. I chose to have the data set as separate methods rather than clutter up the __construct() with 8 optional parameters which I'll never remember the order of.
I would recommend something like generateTable() instead of setTable(). This provides a situation where the name of the method clearly denotes what it does.
I would probably still use a setTable() method to actually set the property, though. Ideally, you could open the possibility of setting a previously defined table for further flexibility.
Yes, setX() is primarily used for setting a field X, though setX() may have some additional code that needs to run in addition to a direct assignment to a field. Using it for something else may be misleading to other developers.
I would definitely recommend against having a public setTable() and would say that setTable() could be omitted or just an unused private method depending upon your requirements.
It sounds like the activity to generate the table is more of a view of other properties on the object, so you might consider moving that to a private method on the object like generateHtmlTable(). This could be done during construction (and upon updates to the object) so that any subsequent calls to getTable() will return the the appropriate HTML.