model-view-controller pattern def save_name(selfname)with open(self filenameself _get_append_write()as data_filedata_file write("{}\nformat(name)class timemodel(object)def __init__(self)pass def get_time_of_day(self)time datetime datetime now(if time hour return "morningif <time hour return "afternoonif time hour > return "eveningalternativelywe could use database to store the greetings instead of saving them in different files the beauty of it all is that it does not matter to the rest of the system what we do in terms of storage just to illustrate this factwe will alter our model to store the greeting in json file rather than in plain text implementing this functionality will require the json package in the standard library the hardest part of adapting this approach to programming is that you have to decide what goes where how much do you place in the modelor what level of processing goes into the viewherei like the concept of fat controllers and skinny models and views we want models to just deal with the creationretrievalupdatingand deletion of data views should only concern themselves with displaying data everything else should sit in the controller sometimesyou might implement helper classes for the controllerand that is goodbut do not let yourself get tempted into doing more than you should in model or view classic example of model doing too much is having one model that requires another modellike having userprofile class that requires user class so you know which user the profile belongs to the temptation is there to send all the information to the userprofile model' constructor and have it create the user instance on the flyit is all data after all that would be mistakeas you would have the model controlling some of the flow of the programwhich should rest on the controller and its helper classes much better