Question

They always talk about extendability and flexibility when writing code, but here I am wanting to expand my webapp and I have no idea how to do it.

---

What I have:

I have a completed webapp that works similarly to a calendar (though not exactly), a school has a list of teachers, each teacher has a number of tests assigned to him, the school gets a list of possible times for tests, and has to fit the teachers into the possible test times, using several rules. That much is DONE

What I want to do:

Now that the application is complete, I recieved a request to support a user/pass system, and every user will have a specific calendar that matches him (user == school in this context).

The problem:

I want to preform the shift with minimal code alteration (to the source classes). I can extend the source class, but that would mean

1. To change all the times the class is referred to in the code to the new name
2. Simply adding more code

The point is to have each user a database for his own.

LET ME JUST CLARIFY, MAKING THE USER PASS LOGIN SYSTEM IS NOT THE PROBLEM, THE PROBLEM IS TO EXTEND THE CODE TO ACCOMMODATE THE MULTIPLE USER ENVIRONMENT

---

Database Structure:

Fixed Tables:

teachers

id | name

Monthly Tables:

The program is updated each month, and history save is required, therefore these tables are added EVERY MONTH.

schedule_month_year – The actual schedule.

id | datetime | teacherid

requests_month_year – Contains the requests from the teachers (I want a test on dd/mm, or I don’t want on dd/mm)

id | teacherid | wantsornot

teachers_month_year – Contains information about teachers and how many tests they have for this month.

teacherid | tests

---

I’m looking for good advice here, maybe I initially wrote my code wrong, in which case, how do you write code preparing for events you don’t know that might happen? (The code I currently have was already re-written nearly from scratch because I was requested to add a change too large to accommodate).

Answer 1

Sometimes I get the idea that extensibility is a hyped up buzzword. It’s not really. It does have merit. However, many touting the benefits of extensibility leave the impression that you can extend an application with virtually no work. This illusion falls apart in the face of database interactions because changes/additions to a database structure invariably necessitate changes in code. The truth behind extensible software is that it’s not easy to extend; rather, it’s easier than the alternative.

In this specific case, Maxem has the right idea. The fact that it “requires a change of all queries, which is quite a lot” is inconsequential. Since you have a working app, the extra work entails only those things required to extend it as opposed to a complete rewrite/redesign. If all you have to do is add some databases and change some queries, then you’re in a good position.

how do you write code preparing for events you don’t know that might
happen?

Design principles and patterns seek to answer this very question.

You may also benefit from Agile software development which addresses the issue of changing requirements among other things.

I believe experience also plays a crucial role here. In the future, when you design an app intended for a single user, you’ll instinctively start thinking about how it might be extended to multiple users and design the app accordingly. Please understand that I’m not implying you’re inexperienced. My point here is that each new experience adds to your arsenal of techniques.