single or separate classes.
Moderator: General Moderators
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
single or separate classes.
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?
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?
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
Re: single or separate classes.
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?
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
Re: single or separate classes.
Yes, the first import will stay in place along with the second type of importrequinix wrote:Might you need to use the original import code at some time in the future?
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 linesrequinix 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?
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
Re: single or separate classes.
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.
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: single or separate classes.
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.
(#10850)
- social_experiment
- DevNet Master
- Posts: 2793
- Joined: Sun Feb 15, 2009 11:08 am
- Location: .za
Re: single or separate classes.
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 stagejraede wrote:Couldn't you just extend the main class for each import type you have?
again thanks for the ideasChristopher 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.
“Don’t worry if it doesn’t work right. If everything did, you’d be out of a job.” - Mosher’s Law of Software Engineering
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: single or separate classes.
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.social_experiment wrote:again thanks for the ideasjust 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?
(#10850)
Re: single or separate classes.
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.