In ABAP class builder, it is possible to sort the lists of attributes and methods. Since I often work with big local classes, I wonder how I could sort my method and attribute declaration in there? I'm quite sure that there is no standard tool for this, but maybe somebody has written a utility or invented some other hack to achieve this?
I already tried this and could not find it how to sort.
You can use menu in SE24: GOTO->PUBLIC/PROTECTED/PRIVATE SECTION to see all methods/attributes (like a local class).
This way is faster to find a methods or attributes in big classes.
I think it is by design and I actually prefer to structure/sort methods and attributes, putting them in a logical context to each other and being able to add enhanced or simplified methods right to the other one, instead of them being overlooked by others. Methods are stored like in this order in the system/source.
There might be something that helps you: The object list applies a sorting to methods and attributes. You can open it with the menu path Utilities > Display Object List or the corresponding button.
You may also consider playing with the Class Builder settings (Menu Utilites > Settings > Class Builder) and the filter options to make it look better for you.
Related
What are the PROS and CONS on using onePageObject class for storing my all xpath/css selectors and etc., and then use them in other page object methods.
I'm thinking how lower the needless xpath's that are constantly is repeating in different pageObjects class.
Any suggestions?
Somebody already doing this? If yes, is it easyer or harder to find what you need?
I'm thinking to use the code something like this:
ObjectClass.java
Public class ObjectClass myXpaths {
#FindBy(xPath);
private button xPathButtonAdd;
#FindBy(xPath);
private button xPathButtonDelete;
#FindBy(xPath);
private button xPathButtonCancel;
}
ObjectClass2.java
import ObjectClass;
Public class void ObjectClass2 myPageObject {
ObjectClass smth = new ObjectClass();
smth.xPathButtonAdd.click();
smth.xPathButtonDelete.click();
smth.xPathButtonCancel.click();
}
CONS as I see it:
One huge class of selectors - huge classes are typical code smell.
Other page object class would inherit from or initialize an object
with a lot of selectors it doesn't need.
Violation of Single Responsibility Principle (SRP).
PROS:
Avoiding some repetitive code - you could avoid it by other means
(see example bellow)
....
If the reason why you think of doing this is minimizing repetitive code, you should rather think of how to extract that repetitive code to separate classes. For instance, given a application with multiple pages where every page has standart search section, you can extract it to separate class SearchSection or SearchBox and use it in pages where you need it.
If you gave an example of repetitive code or what do you want to do, it would be easier to suggest something.
Ok, I think I get now where you want to go. I would definitely recommend separating the selectors from the actual code. We organize our page objects in classes that more or less represent one screen of the application under test. Those classes are then again in a structure of packages representing the business process that is tested. That way we can easily reuse page elements and if something in the application under test changes we only have to touch this "repository" of page elements but not the script that does the action. We also use prefixes like "link", "button", "input" and so on that indicate the type of page element so that the action code is easier to understand and read.
But I would really advise against throwing all in one huge class, because you might have trouble finding things later on. :-)
I have used pragmas in Pharo Smalltalk and have an idea about how they work and have seen examples for what they are used in Pharo.
My questions are:
what are pragmas conceptually,
to what construct do they compare in other languages,
when should i introduce a pragma?
I already found an interesting article about their history: The history of VW Pragmas.
You must think of it as Annotations attached to a CompiledMethod, or if you want as additionnal properties.
Then, thanks to reflection, some tools can walk other compiled methods, collect those with certain annotations (properties) and apply some special handling, like constructing a menu, a list of preferences, or other UI, invoking every class methods marked as #initializer, or some mechanism could be walking the stack back until a method is marked as an #exceptionHandler ...
There are many possibilities, up to you to invent your own meta-property...
EDIT
For the second point, I don't know, it must be a language that can enumerate the methods, and can attach properties to them.
The third point is also hard to answer. In practice, I would say you would use some already existing annotations, but very rarely create a new one, unless you're trying to create a new framework for exception handling, or a new framework for GUI (you want to register some known events or some handlers...). The main usage I would see is for extending, composing an application with unrelated parts, like a main menu. It seems like a relatively un-intrusive way to introduce DECLARATIVE hooks - compared to the very intrusive way to override a well known method TheWorld>>mainMenu. It's also a bit lighter than registering/un-registering IMPERATIVELY via traditional message send at class initialization/unoading. On the other hand, the magic is a bit more hidden.
I have a problem where I have a main class which solves a numerical problem. For simplicity, assume that it solves Ax=b. Now, I want the user the ability to choose the method to solve it. There are thousands of options and each option has thousands of options within it.
My idea was to design it as follows: create a main class and then create subclasses for each method and subsubclasses for the details of each methods (which might interact via inheritance).
For instance, I envisage the user to do something like-
Model.method='CG' Model.preconditioning=off and then Model.Solve and in the Model class, there is a CG subclass which runs. Within CG there are methods CG_Precond and CG_NoPrecond which run depending on the preconditioning being on or off. (Assume that the methods are wildly different). So, in essence, the user is running Model.CG.CG_NoPrecond.
Is this good design? Should nested classes be avoided?
One important note is that other than the Model class, all of the subclasses contain only methods and no data of their own (other than what is returned).
I spent some time reading some really beautiful answers on SO and my problem ( I believe) aligns with the requirements of the accepted answer of Why/when should you use nested classes in .net? Or shouldn't you?.
First, you should create a class Solver and use the Strategy Pattern to create subclasses which represent the different methods to solve the problem.
The options and suboptions are a harder thing to do right. If i got you right, then CG_Precond and CG_NoPrecond should be subclasses of a CG (which is also a subclass of Solver) as they seem to share some inner logic.
If the options are like predefined values for the different methods where each method requires other values and type of values, then becomes more difficult. There i would like you to present some more examples of options, suboptions and so on.
I had a bunch of objects which were responsible for their own construction (get properties from network message, then build). By construction I mean setting frame sizes, colours, that sort of thing, not literal object construction.
The code got really bloated and messy when I started adding conditions to control the building algorithm, so I decided to separate the algorithm to into a "Builder" class, which essentially gets the properties of the object, works out what needs to be done and then applies the changes to the object.
The advantage to having the builder algorithm separate is that I can wrap/decorate it, or override it completely. The object itself doesn't need to worry about how it is built, it just creates a builder and 'decorates' the builder with extra the functionality that it needs to get the job done.
I am quite happy with this approach except for one thing... Because my Builder does not inherit from the object itself (object is large and I want run-time customisation), I have to expose a lot of internal properties of the object.
It's like employing a builder to rebuild your house. He isn't a house himself but he needs access to the internal details, he can't do anything by looking through the windows. I don't want to open my house up to everyone, just the builder.
I know objects are supposed to look after themselves, and in an ideal world my object (house) would build itself, but I am refactoring the build portion of this object only, and I need a way to apply building algorithms dynamically, and I hate opening up my objects with getters and setters just for the sake of the Builder.
I should mention I'm working in Obj-C++ so lack friend classes or internal classes. If the explanation was too abstract I'd be happy to clarify with something a little more concrete. Mostly just looking for ideas or advice about what to do in this kind of situation.
Cheers folks,
Sam
EDIT: is it a good approach to declare a
interface House(StuffTheBuilderNeedsAccessTo)
category inside Builder.h ? That way I suppose I could declare the properties the builder needs and put synthesizers inside House.mm. Nobody would have access to the properties unless they included the Builder header....
That's all I can think of!
I would suggest using Factory pattern to build the object.
You can search for "Factory" on SO and you'll a get a no. of questions related to it.
Also see the Builder pattern.
You might want to consider using a delegate. Add a delegate method (and a protocol for the supported methods) to your class. The objects of the Builder class can be used as delegates.
The delegate can implement methods like calculateFrameSize (which returns a frame size) etc. The returned value of the delegate can be stored as an ivar. This way the implementation details of your class remain hidden. You are just outsourcing part the logic.
There is in fact a design pattern called, suitable enough, Builder which does tries to solve the problem with creating different configurations for a certain class. Check that out. Maybe it can give you some ideas?
But the underlying problem is still there; the builder needs to have access to the properties of the object it is building.
I don't know Obj-C++, so I don't know if this is possible, but this sounds like a problem for Categories. Expose only the necessary methods to your house in the declaration of the house itself, create a category that contains all the private methods you want to keep hidden.
What about the other way around, using multiple inheritance, so your class is also a Builder? That would mean that the bulk of the algorithms could be in the base class, and be extended to fit the neads of you specific House. It is not very beautiful, but it should let you abstract most of the functionality.
I've had this problem many times before, and I've never had a solution I felt good about.
Let's say I have a Transaction base class and two derived classes AdjustmentTransaction and IssueTransaction.
I have a list of transactions in the UI, and each transaction is of the concrete type AdjustmentTransaction or IssueTransaction.
When I select a transaction, and click an "Edit" button, I need to decide whether to show an AdjustmentTransactionEditorForm or an IssueTransactionEditorForm.
The question is how do I go about doing this in an OO fashion without having to use a switch statement on the type of the selected transaction? The switch statement works but feels kludgy. I feel like I should be able to somehow exploit the parallel inheritance hierarchy between Transactions and TransactionEditors.
I could have an EditorForm property on my Transaction, but that is a horrible mixing of my UI peanut butter with my Model chocolate.
Thanks in advance.
You need to map your "EditorForm" to a transaction at some point. You have a couple options:
A switch statement...like you, I think this stinks, and scales poorly.
An abstract "EditorForm" property in base Transaction class, this scales better, but has poor seperation of concerns.
A Type -> Form mapper in your frontend. This scales fairly well, and keeps good seperation.
In C#, I'd implement a Type -> Form mapper like this:
Dictionary <Type,Type> typeMapper = new Dictionary<Type,Type>();
typeMapper.Add(typeof(AdjustTransaction), typeof(AdjustTransactionForm));
// etc, in this example, I'm populating it by hand,
// in real life, I'd use a key/value pair mapping config file,
// and populate it at runtime.
then, when edit is clicked:
Type formToGet;
if (typeMapper.TryGetValue(CurrentTransaction.GetType(), out formToGet))
{
Form newForm = (Form)Activator.CreateInstance(formToGet);
}
You probably don't want to tie it to the inheritance tree--that will bind you up pretty good later when you get a slight requirements change.
The relationship should be specified somewhere in an external file. Something that describes the relationship:
Editing AdujustmentTransaction = AdjustmentTransactionEditorForm
Editing IssueTransaction = IssueTransactionEditorForm
With a little bit of parsing and some better language than I've used here, this file could become very generalized and reusable--you could reuse forms for different objects if required, or change which form is used to edit an object without too much effort.
(You might want users named "Joe" to use "JoeIssueTransactionEditorForm" instead, this could pretty easily be worked into your "language")
This is essentially Dependency Injection--You can probably use Spring to solve the problem in more general terms.
Do I miss something in the question? I just ask because the obvious OO answer would be: Polymorph
Just execute Transaction.editWindow() (or however you want to call it), and
overwrite the method in AdjustmentTransaction and IssueTrasaction with the required functionality. The call to element.editWindow() then opens the right dialog for you.
An alternative to the Dictionary/Config File approach would be
1) to define a interface for each of the transaction editors.
2) In your EXE or UI assembly have each of the forms register itself with the assembly that creates the individual transaction.
3) The class controlling the registration should be a singleton so you don't have multiple form instances floating around.
3) When a individual transaction is created it pulls out the correct form variable from the registration object and assigns it do an internal variable.
4) When the Edit method is called it just uses the Show method of the internal method to start the chain of calls that will result in the display of that transacton editor.
This eliminates the need for config files and dictionaries. It continues to separate the UI from the object. Plus you don't need any switch statement
The downside is having to write the interface for each every form in addition to the form itself.
If you have a great deal of different types of editors (dozens) then in that case I recommend that you use the Command Pattern
You have a master command that contains the dictonary recommend by Jonathan. That commands in turns will use that dictornary to execute one of a number of other command that calls the correct form with the correct object. The forms continue to be separate from the object themselves. The forms reside in the Command assembly. In addition you don't have to update the EXE to add another editor only the Command assembly. Finally by putting things inside of Command you can implement Undo/Redo a lot easier. (Implement a Unexecute as well as a Execute)