I've noticed that all of the examples in Optaplanner use the line
import org.optaplanner.examples.common.domain.AbstractPersistable;
to import an abstract class that most of the domain classes implement. To persist my solution to an xml file, should I also utilize this class? My maven project would need to have org.optaplanner.examples as a dependency, which I am hesitant to do.
I've read the source for AbstractPersistable, and I can't tell what benefits it provides to the example projects.
Don't depend on optaplanner-examples.
You probably don't need that class, just leave it out.
If you want to have that superclass that provides a database id, for every domain class, simply copy paste that class into your sources.
Related
This issue is a pure design modeling
I have two packages and there are different classes with same name should embedded to these packages
what's the good design solution if I have same classes in different packages
I have read different solutions based on coding such as:
1-use "import"dependency between packages to avoid redundancy classes
2-create instance of classes in other package, and thus allow to have same name classes in different packages
3-fully qualify one of the class name
Would you suggest which is best solution or tell me other good solutions please?
You are allowed to use the same name for classes when they are I different packages. A package is a namespace so the fully qualified names of such classes will be different. Now how you access the class depends on in which package are you at the moment. Whenever you're outside the package containing the class (either directly out through import/access), you have to use fully qualified names to avoid ambiguity.
If the classes are actually the same, you may:
- put it the one package where it suits more and simply access it from the other package (standard approach, possible for all public classes)
- put it in one of the packages (if it suits there better for some reason) and import it to the other package (through element or package import)
- put it in additional package (e.g. Utils) and import it to both packages.
The choice will depend on specific situation.
If it is the same class you should define it in one package and "reuse" it in the other.
A complete UML modeling tool should be able to Drag-n-Drop an existing class in another package.
The tool should be able to indicate you are using a class from another package.
I have several internal logic dependencies in my source code. For example
Class A accepts an object and that object to be valid in Class A needs to have particular interfaces such as InterfaceOne, InterfaceTwo
I would like a way to represent the Interface dependencies for Class A visually in enterprise architect. Right now i'm generating the base class by importing the source code then I'm manually creating the dependencies between the Classes and Interfaces.
In my source code these dependencies are all within a variable of the class
$requiredDependencies = array('InterfaceOne', 'InterfaceTwo')...
Is there a way to programatically either parse this code or maybe enterprise architect has a way to read comments (like doxygen) and I could specify such relation in comments?
The Grammar Framework lets you generate in-EA parsers for custom languages, allowing you to reverse-engineer code in whatever language you choose. This is a pretty complex beast, but have a look in the help file under Extending UML Models -- MDG Technology SDK -- Grammar Framework.
If the language is already supported by EA, then that reverse-engineering process cannot be modified (other than what's available in the options), although you can of course write your own parser from scratch using the grammar framework.
If you want to do additional processing for a reverse-engineered class based on what's in its source file, then you can find the source file in Element.GenFile. You would then have to parse it yourself, of course.
I was thinking to create a generic base class and have each of the module base class inherit from it... but is there a better way to do this?
I'd say if you need a base class, you're not having real modules. I think modules should be "totally" independent sub-applications.
If you really want to write such a base class, use dependency injection, not inheritance so you can inject the needed common behaviour in all modules without creating such a tight coupling of all your modules. Just create a subfolder under 'application' and call it 'Base' or something. But again, I think it might not be such a good idea resp. if you need it, we're not talking about modules. Then again, each case is different.
Lets say I have a class...
com.mycom.app.AbstractMessage
There is another class in
com.mycom.model.QueryResponse
QueryResponse extends AbstractMessage and notice they are in different pacakges
com.mycom.model is a GWT Module and in the module XML
When I compile model there are errors. However when I try to use QueryReponse in another GWT module, I get runtime errors
"No source code is available for type com.mycom.app.AbstractMessage; did you forget to inherit a required module"
This lends me to believe that AbstractMessage was not compiled/compiled right to begin understandably because I DO NOT WANT to have "app" package be a GWT module
In other words, I only want to compile all classes in "model" and not any super classes. How can I tell the GWT compiler/rpc/linker/serializer etc not to do so?
i.e Is there a way to tell GWT not to walk beyond certain classes when it serializing/compiling it
I am doing this a source environment where we have a lot of packages, most of them depend on MODEL only and I DO NOT want to make a GWT module out of every package, just so it compiles.
Thoughts anyone?
I did a little bit of research on this one, you are right GWT will look for all implementations of an Abstract class, if and only if, the AbstractClass is referenced in an RPC GWTAsync interface, even though some are in non-GWT packages.
Let's say an object of type AbstractClass comes in over the network, and the GWT deserializer is now tasked with coverting the network data into a specific instance. It needs to know about all implementations of AbstractClass, to find which is coming over the network right now! -- So to accomplish this it, at compiletime, generates a .rpc file for each GWT service interface, listing all possible concrete types that the service methods can return.
Ray Ryan (Google employee) once mentioned that it is a bad idea to use interfaces arguments or return types in any RPC interface. - because it makes it difficult for the deserializer to know the exact type.
You can hand edit the generated RPC file and remove the offending types, or mark the other implementations as Non Serializable by not implementing Serializable in those implementations in other packages.
A Better way could be - I suspect you wrote code : "implements java.io.Serializable" at the top level (for the AbstractClass itself), maybe it's now time to move it to each implementation.
Now the GWT RPC deserializer's task is clear and straightforward - it knows that only certain implementations (that are serializable) of the AbstractClass will come over the network, and reach and compile them only. So it will not compile the other non serializable subclassess of your AbstractClass - as it knows they arent serializable.
There is one more option : If as I suspect you are using the command pattern - I have seen all the abstract interfaces, super classes for Command and Response etc always go in the client side packages - i.e., those that are GWT compiled. They are referrable and usable and instantiable for the server end of the application - so these source files are compiled twice, once by GWT into javascript for browser usage, and once by javac into bytecode for allowing reference from serverside. Thus in all GWT modules, including gwt-user.jar if you open them with 7Zip or WinZip you will see source and class files JARed together.
I recommend Moving AbstractMessage into the models package - as it is the model QueryResponse's super class.
And also inhertance in models is only a good idea, if you have 0 fields and only methods(behaviour) in the super class.
Lastly, if GWT is to make your QueryResponse into javascript - it needs ALL Types mentioned in the source file, to compile properly. So do not mention any server-only-classes in a source file meant to become javascript.
Have a region that has all the server-side java classes that will be run in a JVM on the server, and another region full of source files that will be compiled into javascript by the GWT compiler. The server-side region code/classes CAN refer to client region code/classes but defenitely NOT the vice versa. Make sure that no code thats gonna become javascript is referring (even an unused import statement) to a server side class.
GWT compiler works with source files only, however you need to compile client code into .class files so your serverside classes can refer to them.
NEW EDIT :
I did a little bit of research on this one, you are right GWT will look for all implementations of an Abstract class, if and only if, the AbstractClass is referenced in an RPC GWTAsync interface, even though some are in non-GWT packages.
Let's say an object of type AbstractClass comes in over the network, and the GWT deserializer is now tasked with coverting the network data into a specific instance. It needs to know about all implementations of AbstractClass, to find which is coming over the network right now! -- So to accomplish this it, at compiletime, generates a .rpc file for each GWT service interface, listing all possible concrete types that the service methods can return.
Ray Ryan (Google employee) once mentioned that it is a bad idea to use interfaces arguments or return types in any RPC interface. - because it makes it difficult for the deserializer to know the exact type.
You can hand edit the generated RPC file and remove the offending types, or mark the other implementations as Non Serializable by not implementing Serializable in those implementations in other packages.
A Better way could be -
I suspect you wrote code : "implements java.io.Serializable" at the top level (for the AbstractClass itself), maybe it's now time to move it to each implementation.
Now the GWT RPC deserializer's task is clear and straightforward - it knows that only certain implementations (that are serializable) of the AbstractClass will come over the network, and reach and compile them only. So it will not compile the other non serializable subclassess of your AbstractClass - as it knows they arent serializable.
I've recently started to try to use Dist::Zilla for maintaining Path::Class. I added the [PodCoverageTests] plugin, and it's reporting some failures in the Path::Class::Entity class, which is the abstract base class for Path::Class::File and Path::Class::Dir.
What I'd like is some way to tell the testing code that Entity doesn't need docs, but its two derived classes do - even though the methods are only defined in the parent class. Anyone know some way to do that?
Dist::Zilla's standard POD coverage test uses Pod::Coverage::TrustPod.
You should be able to say
=for Pod::Coverage
.
to tell it to assume that everything is documented.