#1
  1. No Profile Picture
    http://stealthwd.ca
    Devshed Novice (500 - 999 posts)

    Join Date
    Dec 2005
    Posts
    688
    Rep Power
    200

    Naming convention to reuse code


    Hey everyone. I've been making a CMS for the company I work for. I've been trying to make everything as modular as possible, and so far its looking alright. Essentially every database table has its own class to get data, insert records, update, delete, etc etc etc.... Here's my question... Lots of the functions do the same thing, just on different tables. Do you think its ok to give some of the more generic functions more generic names...

    Example, each class has a function to return all records, so instead of something like getCustomers, or getOrders, what if I just named them getRecords (or something like that). So each class would have a getRecords function, and it would be easier to reuse front end code.

    Any ideas why this would be bad or any reason?

    Thanks!
  2. #2
  3. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,301
    Rep Power
    7170
    It's sort of a tradeoff: it's good from a re-usability standpoint but bad from a readability standpoint. I would say the good aspects of it probably outweigh the bad aspects because you can work around the readability downsides of it if you have good comments.

    Having more generic function names makes proper OOP inheritance easier to implement (because the same function name is appropriate for a wider variety of mutually exclusive purposes).

    It also makes it easier to program because you don't have to look up or remember the name of the get method for class X if the get method for all classes is called getRecords.

    Additionally, it makes writing flexible code easier - if you have a listing function that lists all of the records in an object and it accepts objects of many different types you don't need to program separate get calls for each object type. This greatly simplifies the code and makes it far easier to add support for new classes.

    Comments on this post

    • medialint agrees
  4. #3
  5. No Profile Picture
    http://stealthwd.ca
    Devshed Novice (500 - 999 posts)

    Join Date
    Dec 2005
    Posts
    688
    Rep Power
    200
    Originally Posted by E-Oreo
    It's sort of a tradeoff: it's good from a re-usability standpoint but bad from a readability standpoint. I would say the good aspects of it probably outweigh the bad aspects because you can work around the readability downsides of it if you have good comments.

    Having more generic function names makes proper OOP inheritance easier to implement (because the same function name is appropriate for a wider variety of mutually exclusive purposes).

    It also makes it easier to program because you don't have to look up or remember the name of the get method for class X if the get method for all classes is called getRecords.

    Additionally, it makes writing flexible code easier - if you have a listing function that lists all of the records in an object and it accepts objects of many different types you don't need to program separate get calls for each object type. This greatly simplifies the code and makes it far easier to add support for new classes.
    Cool thanks. I was originally thinking each class would have its own getRecord function, but from what I understand you're staying you think there should be only one getRecord function that can work for different objects?


    Also, from the readability standpoint, I don't think it makes it any more difficult for what i'm doing since they can tell what class the function is from when they use it. I'm using php so for example it would be something like pages->getRecords();, so its obviously from the pages class.
    Last edited by Dameon51; November 17th, 2009 at 03:14 PM.
  6. #4
  7. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,301
    Rep Power
    7170
    Cool thanks. I was originally thinking each class would have its own getRecord function, but from what I understand you're staying you think there should be only one getRecord function that can work for different objects?
    It depends very much on the particular class. If you have a bunch of getRecord functions that have exactly the same code except that the table name is different then you should abstract the getRecord function out to a parent class. Of course, the good part of OOP inheritance is that you can then override the getRecord function for any classes that needs a custom implementation.

    Comments on this post

    • Dameon51 agrees
  8. #5
  9. No Profile Picture
    http://stealthwd.ca
    Devshed Novice (500 - 999 posts)

    Join Date
    Dec 2005
    Posts
    688
    Rep Power
    200
    Originally Posted by E-Oreo
    It depends very much on the particular class. If you have a bunch of getRecord functions that have exactly the same code except that the table name is different then you should abstract the getRecord function out to a parent class. Of course, the good part of OOP inheritance is that you can then override the getRecord function for any classes that needs a custom implementation.
    Awesome! I setup one of my classes to do it this way and I can see how this will save time in the long run. Thanks alot!

    Comments on this post

    • medialint agrees
  10. #6
  11. No Profile Picture
    http://stealthwd.ca
    Devshed Novice (500 - 999 posts)

    Join Date
    Dec 2005
    Posts
    688
    Rep Power
    200
    Originally Posted by E-Oreo
    It depends very much on the particular class. If you have a bunch of getRecord functions that have exactly the same code except that the table name is different then you should abstract the getRecord function out to a parent class. Of course, the good part of OOP inheritance is that you can then override the getRecord function for any classes that needs a custom implementation.
    Ok, here's another concern\question, is how far do I push this?

    I've done my basic functions for a class like this.. so I have a getAllRecords and a getRecordByID in a parent class thats abstracted from the children.

    But those children of course have slightly more complicated functions.... these are just examples but say i had getPersonByAge and getTreeByHeight functions. Does it make sense to make a function getByConditional function that handle the SQL where clause, or is that just over complicating things?

    And how about UPDATE and INSERT functions, do you think its a good idea to do it with these too????
    Last edited by Dameon51; November 17th, 2009 at 04:50 PM.
  12. #7
  13. No Profile Picture
    Lost in code
    Devshed Supreme Being (6500+ posts)

    Join Date
    Dec 2004
    Posts
    8,301
    Rep Power
    7170
    Update / Insert functions are usually OK to abstract to a super class because their functionality is generally very clear to the end developer and the queries they generate are generally very simple.

    Personally I am not a fan of getByConditional type functions as you are describing. Select statements can quickly become very complex, especially when joins are involved, and trying to abstract something like the WHERE clause of a select query into function arguments is very difficult to do effectively. In general your getByConditional function will either be so complex that it takes several pages of documentation to understand so developers won't take the time to learn to use it, or else it will not be powerful enough so developers end up not using it anyway. In either case, it really only serves to confuse your code and the people reading it.

    Although a getAll method does involve a select statement it is generally a very simple select statement that doesn't require many arguments. You might consider making an abstract get method that operates on only two parameters: a field name and a field value. This would allow very simple select statements to be abstracted to a parent class. Anything more complex than SELECT _ FROM _ WHERE _ = _ I would recommend having completely separate functions for.
  14. #8
  15. No Profile Picture
    http://stealthwd.ca
    Devshed Novice (500 - 999 posts)

    Join Date
    Dec 2005
    Posts
    688
    Rep Power
    200
    Originally Posted by E-Oreo
    Update / Insert functions are usually OK to abstract to a super class because their functionality is generally very clear to the end developer and the queries they generate are generally very simple.

    Personally I am not a fan of getByConditional type functions as you are describing. Select statements can quickly become very complex, especially when joins are involved, and trying to abstract something like the WHERE clause of a select query into function arguments is very difficult to do effectively. In general your getByConditional function will either be so complex that it takes several pages of documentation to understand so developers won't take the time to learn to use it, or else it will not be powerful enough so developers end up not using it anyway. In either case, it really only serves to confuse your code and the people reading it.

    Although a getAll method does involve a select statement it is generally a very simple select statement that doesn't require many arguments. You might consider making an abstract get method that operates on only two parameters: a field name and a field value. This would allow very simple select statements to be abstracted to a parent class. Anything more complex than SELECT _ FROM _ WHERE _ = _ I would recommend having completely separate functions for.
    Great, thanks for the advice. This is going to help me out a lot and has made me realize I've got to read up more on OO programming and use it more.
  16. #9
  17. No Profile Picture
    Contributing User
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Feb 2004
    Location
    London, England
    Posts
    1,585
    Rep Power
    1373
    You don't say what language you are using - that would be useful to know.

    Do a google search for ORM (Object Relational Mapping) + your language. An ORM is a library for converting between objects in the language and tables in a database. A good ORM will hide all the details of persisting objects to the database, so you can concentrate on designing the objects and their interactions.

    Dave
  18. #10
  19. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Dec 2009
    Location
    UK
    Posts
    197
    Rep Power
    149
    This is a bit tangential, but might be food for thought.

    We have database stored procedures for each table:

    MyTable_Get, MyTable_Save, MyTable_Delete

    these are used for standard CRUD data management.

    We mechanically generate these (using SQL as it happens!), together with the CMS templates for the actual data entry forms, and some other "stuff".

    We do handcode changes to them, but on an 80:20 rule this is relatively rare.

    If we add/change a column in a table we regenerate the SProcs / CMS and then use a DIFF tool to compare them against the current code - which allows us to merge in code for the new columns if we have modified the standard code for that table, otherwise we just accept the regenerated code if the code has not been "human enhanced"

IMN logo majestic logo threadwatch logo seochat tools logo