Page 1 of 1
single or separate classes.
Posted: Fri Apr 05, 2013 3:46 am
by social_experiment
I wrote a class that imports records into a database; now the requirements for the system has changed; i have to import a second, different set of data. The initial class has the following properties and methods:
Properties:
-------------
$fields
$table
$mimeTypes
Methods:
-----------
searchSimilarRecord()
processFile()
populateDatabase()
The second import would also use these methods but i'm wondering whether i should refactor the existing class to accommodate the new information (new table name, new fields, etc) or should i go with a separate class for each type of import?
Re: single or separate classes.
Posted: Fri Apr 05, 2013 12:28 pm
by requinix
Might you need to use the original import code at some time in the future? Is it a question of there being a new type of import or that the original import has changed format? How much code is involved?
Re: single or separate classes.
Posted: Fri Apr 05, 2013 4:02 pm
by social_experiment
requinix wrote:Might you need to use the original import code at some time in the future?
Yes, the first import will stay in place along with the second type of import
requinix wrote:Is it a question of there being a new type of import or that the original import has changed format? How much code is involved?
It's a new type of import; the original import is for race details while the new import is for rider information. Not much really; 280 lines
Re: single or separate classes.
Posted: Fri Apr 05, 2013 4:09 pm
by requinix
Then I say make a copy. It's a small amount of code so there's not much to worry about regarding code duplication. More importantly it's a new type of import with a new set of data.
Re: single or separate classes.
Posted: Tue Apr 16, 2013 7:17 pm
by jraede
Couldn't you just extend the main class for each import type you have? Doesn't look like you'd have much to change besides maybe the field names, DB columns, etc. The general logic would all be the same.
Re: single or separate classes.
Posted: Tue Apr 16, 2013 9:57 pm
by Christopher
Yes, I would create a base import class and then extend it for each import type. The child classes would assign the table name, field name array, etc. to base properties. The base class would handle the common functionality. And, you can always add extra methods specific to each import class.
Re: single or separate classes.
Posted: Wed Apr 17, 2013 1:25 am
by social_experiment
jraede wrote:Couldn't you just extend the main class for each import type you have?
i only had a single class to begin with but the idea might be worth looking into should there be any refactoring required at some stage

thanks for the idea
Christopher wrote:Yes, I would create a base import class and then extend it for each import type. The child classes would assign the table name, field name array, etc. to base properties. The base class would handle the common functionality. And, you can always add extra methods specific to each import class.
again thanks for the ideas

just a question regarding overhead: the classes are fairly small in size (+/- 280 lines), would a base class that extends to two other classes have any significant issues in terms of import? Granted the import function is only used on occasion but let's say i wanted to import 1000 records into the database, would a base classes + 2 extended classes slow down the process or speed it up? Or are the performance issues negligible against the improved code?
Re: single or separate classes.
Posted: Wed Apr 17, 2013 1:33 pm
by Christopher
social_experiment wrote:again thanks for the ideas

just a question regarding overhead: the classes are fairly small in size (+/- 280 lines), would a base class that extends to two other classes have any significant issues in terms of import? Granted the import function is only used on occasion but let's say i wanted to import 1000 records into the database, would a base classes + 2 extended classes slow down the process or speed it up? Or are the performance issues negligible against the improved code?
I think the difference will be negligible at worst. A tiny include (that is probably cached). The child classes will probably be very small -- only defining the table and fields, and maybe an extra method. I am assuming that the base class does the identical work for each importer. Obviously if you end up with a loop with a bunch of if() statements in it dealing with the differences, then you should just create two separate classes.
Re: single or separate classes.
Posted: Thu Apr 25, 2013 12:11 pm
by josh
You could copy & paste a new class, when it is done & your specifications are met, move any common code to a base class. This lends itself well to TDD so you can be sure you haven't broken anything when removing the duplicate code.