model-view-controller pattern return 'wdef read_names(filename)with open(filename' 'as data_filenames data_file read(split('\ 'return names def write_name(filenamename)with open(filenameget_append_write(filename)as data_filedata_file write("{}\nformat(name)once the code is encapsulated into an objectyou will find that as program grows different types of data are requiredand each of these gets placed into its own model object usuallymodel objects each end up in their own file what remains is the code that is focused on delivering some sort of information back to the user in our casethis is done via the standard output port to the console thisas you have guessed by nowis called the view code here are the remaining view functions from our previous program view_ functions py def main(name)print(get_message(name)as am certain you noticedthe grouping of functions is not as clear-cut as we would like it to be ideallyyou should be able to change anything in either one of the groups of functions (without changing their interfaces)and this should not have any effect on the other modules before we make clean split and encapsulate the three classes of functions into separate classeslet' look at the elements that go into the pattern controllers the controller is the heart of the patternthe part that marshalls all the other classes users interact with the controllerand through it the whole system the controller takes the user inputhandles all the business logicgets data from the modeland sends the data to the view to be transformed into the representation to be returned to the user