I'm in the process of migrating a short Python project (2000 LOC) from procedural style to OOP style. I've thus far created classes and inheritance structures without too much trouble and found obeying the SOLID rules to be quite natural. Today, however, I found myself in an odd situation:
I had written very a generic function of the sort:
#unsafe, executes arbitrary query on db
def select_anything(mysql_cursor,query):
mysql_cursor.execute(query)
I then started adding more convenient varieties such as:
#safer, select statement only
def select_some1(mysql_cursor,table,columns):
mysql_cursor.execute("SELECT columns FROM table")
#safer, select statement+filter only
def select_some2(mysql_cursor,table,optional_columns,required_columns):
mysql_cursor.execute("SELECT columns++required_columns FROM table WHERE required_columns are NOT NULL")
Quickly after, I got the strong desire to build out a class hierarchy for this function (using call to mimic a function). Starting with the generic function as the parent and then defining specializations as children, I could reuse code. But this completely breaks the SOLID rules. For example, it operates in the opposite direction required by Liskov: only the parent can substitute the child (not accounting for transformation of arguments from one to the other)!
Speaking only about the OOP aspects of this, what is this anti-pattern called? Is it correct at all to model a functions as classes (with only one unique callable member) in the attempt to use OOP techniques?
FYI, after some thought, I'm going down the road of a single heavily templated function with large/many arguments and then defining separate lighter/more convenient functions (so no OOP) which build up the arguments and call the templated function. For example, the template function could look like:
select_most(from_table,{columns:(where,set)}):
# TBD
# all arguments to be limited and safe
# columns = selected columns
# where = filter rule per column (combined with AND)
# set = set statement per column
# where and set to be a small subset of what is possible in SQL
Aucun commentaire:
Enregistrer un commentaire