| andrewmcdonagh 2007-02-19, 9:55 pm |
| On Feb 14, 3:50 pm, LX-i <lxi0...@netscape.net> wrote:
> andrewmcdonagh wrote:
>
>
> It'll be a bit. As I type ...........
>
> (I have changed the DbUtil.cs file to be an interface, and created a
> SqlDbUtil.cs file with the SQL Server implementation. I am also in the
> process of changing the "string SQL together" methods to use parameters,
> so as to make them not liable to SQL injection attacks.)
>
I haven't had time to look through the code since your message, so
hopefully you are nearly ready to post a new complete version. (if you
want to...)
In the meantime, here's some (personal) guidelines for helping to see
refactorings to make when faced with a large class......
Its likely that the class is doing more than one job (i.e. has more
than one Responsibility) when...
1) If there are lots(more than 5) member variables
2) If there are lots of (more than 5) public methods
3) If there are lots of (more than 5) private methods
4) The entire class code contains more than 5 'if' statements (this
includes a Switch with more than 5 'case' statements.
5) The entire class code contains more than 5 loop statements (For,
While, Do statements).
When ever one or more of these Guidelines are broken, I look for ways
of extracting the related code out into its own class.
A good starting point is to look for relationships between groups of
member variables or methods.
e.g. a class with AddWidget, EditWidget, DeleteWidget,
ReportWidgetsSold, ReportWidgetsReturned methods could be broken into
a WidgetStore (add, edit, delete) and WidgetReporter classes
So in your codes example, I see a Source code parser, using a number
of small classes that know what to do with an individual piece of
source code (eg Java Comment, Cobol Comment, C# Comment classes, A
Language keyword Dictionary (Java Dict., Cobol Dict. etc) a number of
database CRUD classes for mapping between the OO world and the
Relational DB., etc...
These are guidelines though, not rules...
Regards
Andrew
|