Duplicate classes not sharing common interface

[matthias-ronge]

The classes ProcessObject, ProjectObject and StepObject in the package de.sub.goobi.persistence.apache duplicate the classes Projekt, Prozess and Schritt in the package de.sub.goobi.beans for use with different implementations (Hibernate vs. Apache Commons DBUtils).

The accessors have partly been translated into English (getTitle() vs. getTitel()), but this work has not been completed (getBearbeitungsende() ?).

Both implementations cannot be interchanged because of the different naming of the accessors and because the “twin pairs” lack to implement a shared interface.

Because of the missing interchangability classes making use of these classes in the packages de.sub.goobi.export.download and de.sub.goobi.metadaten have been duplicated as well (ExportMets vs. ExportMetsWithoutHibernate, …).

Required changes:

• [ ] Rename getters and setters in each both class twins to use the same (English) names
• [ ] Make each pair of class twins implement an interface delcaring its getters and setters
• [ ] Use the interface everywhere members of either class are used in the code
• [ ] Merge duplicated classes in de.sub.goobi.export.download and de.sub.goobi.metadaten

[Kathrin-Huber]

In the course of our refactoring, we will fix all of those issues in a bigger context. Duplicated code will be removed, everything will be translated into english (or renamed, if the name indicates wrong expectations). If necessary, we will design Interfaces. Our goal is also a much better structure of the packages (especialy, merging de/... and org/...) We are happy about every contribution to our process. We will develop all of our changes in "master", so you can follow our work.

[matthias-ronge]

Recent workflow was creating GitHub issues for each step of development. This is what I wanted to start with, naming one of the, to my eyes, most annoying things first. Of course, renaming and also repackaging are necessary steps too, but if we continue to follow the introduced workflow there should be one issue ticket for each of these tasks. Repackaging is targeted in https://github.com/kitodo/kitodo-production/issues/470#issuecomment-222507851 as well.

[henning-gerhardt]

@matthias-ronge : Is this issue only a general issue to do this in near future or do you want to work on this issue now or next few days? If you want to do this in next few days then you should co-ordinate this with @Kathrin-Huber as module structure and new package structure is a goal of current sprint (11/23/2016) on DFG project.

[matthias-ronge]

No. I actually only wanted to start documenting some code problems that I remember, but that are probably not that obvious. At the moment, I can rather only spend my knowledge. I’m sorry for that. I didn’t add tickets for code quality in the past as long as it was not clear if the legacy code would be subject to the new development. Now that there will be development, there should be tickets for code smell issues to document the hidden knowledge about them and let the project management decide how to deal with them. Some more obvious things have already been mentioned (such as packaging and code language).