about:navigating_principle_languages
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
about:navigating_principle_languages [2013-09-14 15:47] – judgment christian | about:navigating_principle_languages [2013-09-14 18:05] – christian | ||
---|---|---|---|
Line 43: | Line 43: | ||
* For the data layer there is a data component, a class '' | * For the data layer there is a data component, a class '' | ||
- | FIXME code for Data class | + | <code java> |
+ | public | ||
+ | { | ||
+ | public EnterpriseQueryIf getEnterpriseQueryIf() | ||
+ | { | ||
+ | return new EnterpriseQueryImpl(); | ||
+ | } | ||
+ | |||
+ | public PersistenceIf getPersistenceManager() | ||
+ | { | ||
+ | return new PersistenceImpl(); | ||
+ | } | ||
+ | |||
+ | public StoreQueryIf getStoreQueryIf() | ||
+ | { | ||
+ | return new StoreQueryImpl(); | ||
+ | } | ||
+ | } | ||
+ | </ | ||
* There are " | * There are " | ||
Line 53: | Line 71: | ||
private static DataIf dataaccess = null; | private static DataIf dataaccess = null; | ||
- | private DataIfFactory () {} | + | private DataIfFactory() {} |
- | public static DataIf getInstance () | + | public static DataIf getInstance() |
{ | { | ||
if (dataaccess == null) | if (dataaccess == null) | ||
{ | { | ||
- | dataaccess = new DataImpl (); | + | dataaccess = new DataImpl(); |
} | } | ||
return dataaccess; | return dataaccess; | ||
Line 146: | Line 164: | ||
So LC, RoE and TdA/IE are against the solution, KISS thinks it's good and ML has nothing against it. As it is not the number of principles which is important, the designer still has to make a sound judgment based on these results. What is more important: Coupling, testability, | So LC, RoE and TdA/IE are against the solution, KISS thinks it's good and ML has nothing against it. As it is not the number of principles which is important, the designer still has to make a sound judgment based on these results. What is more important: Coupling, testability, | ||
+ | |||
+ | ==== Deciding between Alternatives ==== | ||
+ | |||
+ | In the next step we would think about better alternatives and might come up with [[patterns: | ||
+ | |||
+ | We already constructed a characterizing set. So the only thing to do is to rate the ideas according to the principles: | ||
+ | |||
+ | The current " | ||
+ | |||
+ | * LC | ||
+ | * DI > SL > F | ||
+ | * Note that in the SL approach there is an additional coupling to the service locator | ||
+ | * KISS | ||
+ | * F > DI = SL | ||
+ | * All three solutions are rather simple but in DI there is complexity for passing around the references and in the SL approach there is complexity in maintaining the registry | ||
+ | * RoE | ||
+ | * The rating of RoE depends on the concrete variant of the pattern. In the DI approach the dependencies are explicitly visible on the interface, which is not the case in the two other approaches. In solution F the dependency is not visible from the interface at all. Same with SL if the service locator is globally accessible. Even if a reference to the service locator is explicitly passed around, it is still not visible which services provided by the locator are used. On the other hand getting a reference is explicit with F and SL. In the DI approach it is only explicit when it is done manually. Typical DI frameworks wire the instances implicitly. | ||
+ | * TdA/IE | ||
+ | * FIXME | ||
+ | * ML |
about/navigating_principle_languages.txt · Last modified: 2013-09-16 17:27 by christian