3 Answers
3

The main problem would seem to be that the legacy interfaces are not understood and not trusted. It's not possible to solve this problem by ignoring it - and adding more members ad-hoc is actively making it worse.

The bottom line is that interfaces to your classes should be clear, small, trusted, well-documented, and ideally only about a single responsibility (refer to the Single Responsibility Principle).

Techniques like refactoring can be used to move towards that ideal goal. Remember: it will take conscious effort to improve the situation.

Find the source code for the system you are changing. Unless the application is trivial, it is most probably going to be useful specially if it is still in production.

Study the schema and the source code well and plan to re-use. You may find information you don't know such as filed dependencies that are not obvious or special business rules.

Don't write new code that is like the old code unless there is a major issue with the old code. You need to have a clear policy as why there are 2 different classes for Customer for example, otherwise, maintenance and testing will be hell.

I don't understand your point (#3).

The only valid excuses to not re-use existing system's code, INMO, is if you are migrating the system to use a new framework or can't access the code for a technical or legal reason. A system must have internal order and proper structure, it can't be a quality system if it looks like a college student's room!

In a DAO you may return 3 columns from table A, joined with 2 columns from table B, etc. Maybe 4 tables are touched in a single transaction. It will be a necessity to create a new method for new functionality, even on existing tables. The possible permutations are endless. It is not possible to cover every database interaction with generic CRUD methods.

Actually it's possible to cover every interaction with generic CRUD, but it would be like forcing a circle through a square shaped hole.

Usually some sort of framework provides generic CRUD access to the tables. The methods are often designed for working on 1 record at a time. If you fall within this scope, then use the generic CRUD methods. But you wouldn't want to use these methods to update 5 million rows as they would literally perform 5 million separate updates. (they also tend to redundantly update all columns of the row, whether edited or not causing locking issues). You cannot use them for transactional functionality if they are non-transactional.