Would you introduce additional abstraction layer just to make the code more understandable ?
I have a database that currently contains 20 tables.
In my application, there are 10 classes that I should refactor, to make them more readable, for my future self and others who will read my code, by refactoring, I mean changing the code it self - the logic- and also changing the methods and classes names.
Let's only consider one specific case; changing the name of one class.
When my friend so the following code that I wrote:
/// <summary>
/// Abstracts the destination to which data is written, regardless of whether the destination is a file, database, or any other kind of storage.
/// </summary>
public interface IWriter
{
//...
}
public class SqlServerWriter : IWriter {//code.....}
he thought that the responsibility of the above class is to write data to any number of tables in the the Sql Server database, i.e., that it can use it to write data to only one table, two or more tables, or all of the tables.
Unfortunately, that was not what the class is actually responsible for; it is meant to write a specific data across all the tables in the database, it does not give the caller an option to write a generic data to a specific tables in the database.
He was mad at me and said that I should introduce an additional layer of abstraction:
/// <summary>
/// Abstracts the destination tables in the Sql Server; may write to all tables in the database or some of them;
/// </summary>
public interface ISqlServerWriter:IWriter
{
}
/// <summary>
/// Intended to write some data to all the tables in the database.
/// </summary>
public class AllTablesWriter : ISqlServerWriter {//code.....}
Do you consider that an overkill/overengineering ?
EDIT:
If you wonder why the class write data to all the tables in the database, it because it has the job of synchronizing the content of the database with external data source, specifically, an Excel file.
