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.
Related
In Java package protected access was very handy, because it allowed to write modular code. This is not possible with Kotlin unless you stick all those classes into one file and put Private on all of them or by implementing Internal in a separate Module. But I don't like this solutions. Putting lot of stuff in one file is not readable and another problem is that you cannot test any Method/Class that is not Public. Is there another solution?
No, package-protected access is not supported.
You should use internal in Kotlin. This restricts access to the same module, a logical unit of files compiled together to an artifact.
The motivation for not providing a package-protected visibility specifier is as follows, from a Kotlin developer:
The motivation for not having package protected access is very simple: it does not provide any real encapsulation. Any other module in the system can define classes in the same package as your complex independent component and get full access to its internals. On the other hand, classes with internal visibility cannot be accessed from any module other than the one where they are defined.
And you definitely can test methods/classes that have internal access: the tests of a module have full access to internal declarations of that module.
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.
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.
A long shot, but putting it out there -- looking for a way to provide privacy based on a common relative package scope.
So, for example, is there a way to use private[foo] for packages com.company1.foo and com.company2.foo where each package will have access to the other foo package based on their "foo-ness"
Unlikely, but would be nice, have a private[model] used in dependent sbt projects that could really benefit from such a relative privacy.
You cannot do this. From the language spec (2.9):
The modifier can be qualified with an identifier C (e.g. private[C]) that must
denote a class or package enclosing the definition
So the best you can hope for is a shared common package. For the two given examples, com.company1.foo, and com.company2.foo the most restrictive shared root is com; private[com] would be the best you could do.
I don't think this is possible, since foo is just an alias for one specific fully named package in any given scope.
So to packages with names ending in .foo don't have much more in common than two packages containing the letter e in their names.
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.