Separation of concerns keeps a web application’s responsibilities in distinct components rather than mixing them together. It makes architecture cleaner and leaves units easier to test, revise, and assess when generated code needs correction. section 5.4 section 6.3
In AI-assisted work, treat the principle as a design decision that requires human judgment. Generate scaffolding quickly, then inspect whether the result fits the intended architecture; refactor or override suggestions that combine responsibilities poorly. section 5.0 section 5.3.11
Keep database access out of application logic
Place SQLite connection and cursor handling in a DatabaseConnection class, then give a Questions class the cursor it needs to retrieve question rows. This separates resource management from question retrieval and avoids embedding database connections throughout the application. section 5.3.4 section 5.4
class Questions:
def __init__(self, cursor):
self.cursor = cursor
def fetch_data(self):
self.cursor.execute("SELECT * FROM questions") # Adjust SQL query as needed
return self.cursor.fetchall()
The Questions class accepts a cursor and limits its job to fetching question data, illustrating a focused database-retrieval component. section 5.3.4
Maintain separation of concerns while moving quickly:
- Start with core functionality, but retain a clean architecture rather than accepting unnecessary feature scope or overengineering. section 5.3.4
- Plan the database schema before generating code, since weak design can create future technical debt. section 5.4
- Test critical paths and database behavior after generated changes; review proposed diffs and verify each implementation stage. section 5.4 section 6.3
