# Implementing mvc - using observer pattern - beginner to OOP **URL:** \ **Category:** ruby-talk\ **Created:** [8 November 2008 05:57 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076 "2008-11-08T05:57:44Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![Adam\_Akhtar](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@Adam\_Akhtar](https://rubytalk.org/u/Adam_Akhtar)\ **Post date:** [8 November 2008 05:57 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/1 "2008-11-08T05:57:44Z")
Hi I started making a simple command line todo list application as a way to get better at OOP. I decided to use a flat file db gem called kirbybase. Anyway the more I started programming it, the more it started to resemble spaghetti code with ui getting mixed in with logic so I started using google to find some patterns that might help. One that came up was MVC which ive heard about from my very very limited rails experience. I tried implementing it (more like fudging it) but I dont think im giong abotu it the right way. Ive looked on google for ruby specific stuff but keep getting rails results that only provide an overview of it. Can anyone provide any light on how to go about implementing it. Will Kirby Base essentially be my model? Or will the model interact with kirbybase? If i use the observer pattern I guess the model should be the observable with the views being registerd observers. Right? What about the controller? What is it obesvign and who is observing it? All menues etc will live in the views i think with user choices e..g "add task" being registered in the controller along with the program logic... is that right? Regards to their interaction, do all talk to each other or is there a chain of command. I.e. the models seem to speak to the views by updating them, the controllers seem to talk to about the views and models? is that right? Finally does the singleton pattern come into play here? If i wrap the database into a class should only one instance be made? Apologies for my inexperience 馃槈 I know this may sound like overkill for a simply todo command line app but i think it will make great practice and setme up for rails in the future. any help will be of great assistance > **路路路** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Jean-Francois\_Tran](https://avatars.discourse-cdn.com/v4/letter/j/c89c15/32.png) [@Jean-Francois\_Tran](https://rubytalk.org/u/Jean-Francois_Tran)\ **Post date:** [8 November 2008 13:17 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/2 "2008-11-08T13:17:39Z")
2008/11/8 Adam Akhtar : > Hi I started making a simple command line todo list application as a way > to get better at OOP. I decided to use a flat file db gem called > kirbybase. > > Anyway the more I started programming it, the more it started to > resemble spaghetti code with ui getting mixed in with logic so I started > using google to find some patterns that might help. > > One that came up was MVC which ive heard about from my very very limited > rails experience. You should try SimpleConsole, [http://simpleconsole.rubyforge.org](http://simpleconsole.rubyforge.org) sudo gem install simpleconsole    -- Jean-Fran莽ois. > **路路路** > > -- > [http://twitter.com/underflow\_](http://twitter.com/underflow_) ---
**Author:** ![Bob\_Hutchison](https://avatars.discourse-cdn.com/v4/letter/b/65b543/32.png) [@Bob\_Hutchison](https://rubytalk.org/u/Bob_Hutchison)\ **Post date:** [8 November 2008 16:58 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/3 "2008-11-08T16:58:53Z")
Hi, > Hi I started making a simple command line todo list application as a way > to get better at OOP. I decided to use a flat file db gem called > kirbybase. > > Anyway the more I started programming it, the more it started to > resemble spaghetti code with ui getting mixed in with logic so I started > using google to find some patterns that might help. > > One that came up was MVC which ive heard about from my very very limited > rails experience. This is pretty much what MVC tries to deal with. There are variations on MVC as well. > I tried implementing it (more like fudging it) but I dont think im giong > abotu it the right way. Ive looked on google for ruby specific stuff but > keep getting rails results that only provide an overview of it. > > Can anyone provide any light on how to go about implementing it. You would have had better luck looking into the smalltalk world for MVC than the ruby world. These two papers are pretty good I think. The second paper talks about two kinds of model: application and domain -- this is important. \<[http://www.create.ucsb.edu/~stp/PostScript/mvc.pdf>](http://www.create.ucsb.edu/~stp/PostScript/mvc.pdf>); \<[http://www.jdl.co.uk/briefings/MVC.pdf>](http://www.jdl.co.uk/briefings/MVC.pdf>); Then read about value objects/models here: \<[Understanding and Using ValueModels](http://c2.com/ppr/vmodels.html) \> Value models seem like a bit of a pain, but worth knowing about. You won't likely need them at the start, and MVC + value models can be a bit complicated, but when your application starts getting complex they can help. As Jean-Fran莽ois pointed out, you don't have to do this yourself. On the other hand, if you are looking to learn OOP this is a pretty good way, it might be a hard way, but you'll certainly have a handle on OOP by the time you're done 馃檪 > Will Kirby Base essentially be my model? Or will the model interact with > kirbybase? MVC is an \*object oriented\* thing. So your model will interact with kirbybase. The rest of your questions are better answered by the papers I linked to. Cheers, Bob > **路路路** > > On 8-Nov-08, at 12:57 AM, Adam Akhtar wrote: > > > If i use the observer pattern I guess the model should be the observable > > with the views being registerd observers. Right? > > > > What about the controller? What is it obesvign and who is observing it? > > > > All menues etc will live in the views i think with user choices e..g > > "add task" being registered in the controller along with the program > > logic... is that right? > > > > Regards to their interaction, do all talk to each other or is there a > > chain of command. I.e. the models seem to speak to the views by updating > > them, the controllers seem to talk to about the views and models? is > > that right? > > > > Finally does the singleton pattern come into play here? If i wrap the > > database into a class should only one instance be made? > > > > Apologies for my inexperience 馃槈 > > > > I know this may sound like overkill for a simply todo command line app > > but i think it will make great practice and setme up for rails in the > > future. > > > > any help will be of great assistance > > -- > > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Adam\_Akhtar](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@Adam\_Akhtar](https://rubytalk.org/u/Adam_Akhtar)\ **Post date:** [11 November 2008 09:53 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/4 "2008-11-11T09:53:36Z")
Hi thanks for the replies. I looked into MVC and i think its proably overkill for what im doing and probably stretching my abilities too far at this stage though does look like a good pattern. One think I dont understand is what the controller would actually do in my case where im just using the command line. I feel like i only need a model and then a view/controller wrapped into one. Well ive decided to just scrap mvc and just get the thing working. I created two classes. One is a database class which wraps up kirbybase (a flat file db plugin for ruby) and the second is basically the U.I i.e. menu logic, getting input and presenting menus and stuff. Im just not sure how to code their communication to each other. class DB .. .. def insert (task) ... #some kirybbase calls here. .. end end class UI blahblahblah def menu puts "|A| to add a task" ... ... end def navigation menu input = gets.chomp case input when "A" add task etc etc etc end def add\_task new\_task = new\_task\_form add\_task\_to\_db(new\_task) end def add\_task\_to\_db(new\_task) \*\*what goes here? end def new\_task\_form puts "Enter title for task" new\_task = Task.new new\_task.title = gets.chomp return new\_task end in add\_task\_to\_db Im wondering the best way to pass the new\_task completed in the UI object over to my db object. Is there someway to let the db class see the value of new\_task? Should i be using an observer pattern here? Should they be observing one another (if possible?)? Im probably overlooking somthing dead simple here but im way confused. any help most appreciated. > **路路路** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Hugh\_Sasse](https://avatars.discourse-cdn.com/v4/letter/h/d6d6ee/32.png) [@Hugh\_Sasse](https://rubytalk.org/u/Hugh_Sasse)\ **Post date:** [11 November 2008 10:21 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/5 "2008-11-11T10:21:30Z")
> Hi thanks for the replies. I looked into MVC and i think its proably > overkill for what im doing and probably stretching my abilities too far It only needs to be a really simple controller. > at this stage though does look like a good pattern. One think I dont > understand is what the controller would actually do in my case where im > just using the command line. I feel like i only need a model and then a It would take requests from the UI and only access the database when it needs to. It will handle the business logic of what gets added and removed. The UI would concentrate on how stuff looks to the user. The idea, as you said that you want to get the hang of OO, is that each class has a well-defined role. If two classes are in each other's pockets then that is not good, because a change in one means a change in the other. If two becomes 8, then this gets truly horrible. The code that handles the money in your bank shouldn't care what cheques look like when they are printed. But you want some logic in there that handles what goes to a cheque when it's printed. If the bank decides that cheques should have a blue background this year, rather than yellow, then you don't want to change the code that sends the amounts to the cheque printer. > view/controller wrapped into one. > > Well ive decided to just scrap mvc and just get the thing working. I > created two classes. One is a database class which wraps up kirbybase (a > flat file db plugin for ruby) and the second is basically the U.I i.e. > menu logic, getting input and presenting menus and stuff. > > Im just not sure how to code their communication to each other. That communication is the role of the controller. > class DB > .. > .. > > def insert (task) > ... > #some kirybbase calls here. > .. > end > > end > > class UI > > blahblahblah > > def menu > puts "|A| to add a task" > ... > ... > end This bit below goes in your controller. It's a DB, so you will want to handle Create, Read, Update, Delete for the tasks. That's probably enough to start with, and Read and Update mean you'll need to search for tasks, so that means you'll need to Tell the UI to display them. > def navigation > menu > input = gets.chomp > case input > when "A" > add task > etc > etc > etc > end > > def add\_task     new\_task = UI.new\_task\_form     DB. add\_task(new\_task) > end > > def add\_task\_to\_db(new\_task) > \*\*what goes here?   # Nothing, it's already in the DB code. Isn't it? > end   This bit belongs in the UI > def new\_task\_form > puts "Enter title for task"   # don't put this here: new\_task = Task.new > # new\_task.title = gets.chomp > # return new\_task >    >   # You just want the UI to return a bunch of fields. the controller >   # can validate them, and tell the UI: UI.bzzzt("Try again!"). > end > > in add\_task\_to\_db Im wondering the best way to pass the new\_task > completed in the UI object over to my db object. Is there someway to let You don't, you just pass the possibly dodgy data back from the UI to the controller. The controller checks before it stuffs a load of spam into the DB. > the db class see the value of new\_task? Should i be using an observer > pattern here? Should they be observing one another (if possible?)? I don't think you need obsverver if the controller controls what is happening. It will sequence which bits of UI show up. It might get errors from the DB when you ask about all those tasks you didn't get round to adding. Then it will have to tell the UI to display error messages, rather than task lists. > Im probably overlooking somthing dead simple here but im way confused. > > any help most appreciated.         HTH         Hugh > **路路路** > > On Tue, 11 Nov 2008, Adam Akhtar wrote: ---
**Author:** ![Brian\_Candler](https://avatars.discourse-cdn.com/v4/letter/b/5f9b8f/32.png) [@Brian\_Candler](https://rubytalk.org/u/Brian_Candler)\ **Post date:** [11 November 2008 13:14 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/6 "2008-11-11T13:14:27Z")
Adam Akhtar wrote: > class DB > .. > .. > > def insert (task) > ... > #some kirybbase calls here. > .. > end > > end In a typical MVC, the model would be a class which represents the task, rather than a class which represents the database connection (the latter would be hidden away behind it). Hence something like:   t = Task.new   t.name = "Paint shed"   t.save! ...   t = Task.find\_by\_name("Paint shed")   t.completed\_at = Time.now   t.save! If you only have a DB class, then the controller can talk to it directly, but you've lost the "M" from MVC. This may be no loss - simple models are often dumb and just map directly to SQL rows. But sometimes it's useful to put logic in the model layer, e.g.   def full\_name     "#{first\_name} #{last\_name}"   end   def full\_name=(name)     f, l = name.split(" ", 2)     self.first\_name = f     self.last\_name = l   end Here we have a virtual accessor that makes it look like the model has a full\_name column, even though the database actually has two separate columns, first\_name and last\_name. > class UI > > blahblahblah > > def menu > puts "|A| to add a task" > ... > ... > end > > def navigation > menu > input = gets.chomp > case input > when "A" > add task > etc > etc > etc > end If you merge the view into the controller then you might get: class TasksController   def list     tasks = Task.find(:all)     puts "You have #{tasks.size} tasks"     tasks.each { |t| puts t.name }   end   def show(n)     task = Task.find(n)     puts "Showing task #{n}"     puts t.name   end   def create     print "Enter task name:"     name = gets.chomp     print "Enter completion date:"     date = gets.chomp     t = Task.new     t.name = name     t.date = date     t.save!     show(t.id)   end end But what's missing is the sequencing: after showing task n there may be associated actions (e.g. edit task n, delete task n, return to listing) Maybe a good way to approach this is to start as a simple Rails app with a sqlite3 backend. Then you can consider how best to build the UI part which will (a) show the current view, and (b) prompt for next action. > **路路路** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Adam\_Akhtar](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@Adam\_Akhtar](https://rubytalk.org/u/Adam_Akhtar)\ **Post date:** [11 November 2008 12:24 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/7 "2008-11-11T12:24:00Z")
Thank you so much for your help clearing that up. Im much closer to understanding how things fit together. Id just like to confirm somethings (please dont think im asking you to the write the code for me, im not, i just like to be a bit more certain before writing out lines of code 馃槈 ) > This bit below goes in your controller. It's a DB, so you will want to > handle > Create, Read, Update, Delete for the tasks. That's probably enough to > start > with, and Read and Update mean you'll need to search for tasks, so that > means you'll need to Tell the UI to display them. Ok so I have three classes now. DB which encapsulates the DB and all the tables (at the moment there is only one for tasks, in the future Id have anohter for categories, projects etc) Task\_Controller which handles the menu navigation logic and any logic such as what to do with a task when a user marks it as complete etc. It will have DB related tasks such as Create, Read, Update, Delete. Task\_UI which will have basically all the output to the screen such as menu text, prompts etc. From this > > def add\_task > >     new\_task = UI.new\_task\_form >     DB. add\_task(new\_task) > > > end Question 1 it seems your implying my class Task\_Controller should define an instance of the DB and the UI within it, is that correct? Question 2 Presuming Im correct about that, what is the relationship of the db to the view? When the DB is updated is it the DBs job to inform the view for it to update or does it inform the controller or .... C. do nothing at all and just let the controller tell the view to update when it thinks its best. >   This bit belongs in the UI > > > def new\_task\_form > > puts "Enter title for task" > >   # don't put this here: new\_task = Task.new > > > # new\_task.title = gets.chomp > > # return new\_task > >   # You just want the UI to return a bunch of fields. the controller >   # can validate them, and tell the UI: UI.bzzzt("Try again!"). > > > end ok so i shouldnt create an instance of task in the UI. Rahter just return a bunch of fields (a hash \ array? )which contain the input from the user and let the controller figure out what each field represents and whether its valid input. The controller will create a Task instance and then pass it to the DB. Question 3 When the UI presents say a form for a task to the user to fill is it good practice to have things like userinput = gets.chomp in the UI or should that be handled by the controller. Im wondering to what degree logic and presentation are seperated. > **路路路** > > -- > Posted via [http://www.ruby-forum.com/\](http://www.ruby-forum.com/%5C). ---
**Author:** ![Adam\_Akhtar](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@Adam\_Akhtar](https://rubytalk.org/u/Adam_Akhtar)\ **Post date:** [11 November 2008 13:31 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/8 "2008-11-11T13:31:15Z")
Thank you Brian and Hugh for your help. Ive got a much clearer picture of where i should be heading with this now. I have a good enough foundation to actually start coding something and then when mistakes and spaghetti come flying my way I can look at things a little more in detail and refactor. Thank you once again. You have been a great help!. > **路路路** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Adam\_Akhtar](https://avatars.discourse-cdn.com/v4/letter/a/c89c15/32.png) [@Adam\_Akhtar](https://rubytalk.org/u/Adam_Akhtar)\ **Post date:** [11 November 2008 12:24 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/9 "2008-11-11T12:24:27Z")
Fogot the Thank you once again for your and everyone elses help \ part. > **路路路** > > -- > Posted via [http://www.ruby-forum.com/](http://www.ruby-forum.com/). ---
**Author:** ![Hugh\_Sasse](https://avatars.discourse-cdn.com/v4/letter/h/d6d6ee/32.png) [@Hugh\_Sasse](https://rubytalk.org/u/Hugh_Sasse)\ **Post date:** [11 November 2008 13:02 UTC](https://rubytalk.org/t/implementing-mvc-using-observer-pattern-beginner-to-oop/50076/10 "2008-11-11T13:02:27Z")
> Thank you so much for your help clearing that up. Im much closer to > understanding how things fit together. Id just like to confirm > somethings (please dont think im asking you to the write the code for > me, im not, i just like to be a bit more certain before writing out > lines of code 馃槈 ) > > \> This bit below goes in your controller. It's a DB, so you will want to > \> handle > \> Create, Read, Update, Delete for the tasks. That's probably enough to > \> start > \> with, and Read and Update mean you'll need to search for tasks, so that > \> means you'll need to Tell the UI to display them. > > Ok so I have three classes now. > DB which encapsulates the DB and all the tables (at the moment there is > only one for tasks, in the future Id have anohter for categories, > projects etc) > > Task\_Controller which handles the menu navigation logic and any logic > such as what to do with a task when a user marks it as complete etc. It > will have DB related tasks such as Create, Read, Update, Delete. > > Task\_UI which will have basically all the output to the screen such as > menu text, prompts etc. Sounds OK to me. > \>From this > > \>\> def add\_task > \> new\_task = UI.new\_task\_form > \> DB. add\_task(new\_task) > \>\> end > > Question 1 > it seems your implying my class Task\_Controller should define an > instance of the DB and the UI within it, is that correct? Yes, and I should have lowercased those, as they should be instance methods not class methods. Having Upppercase variables makes that unclear. > Question 2 > Presuming Im correct about that, what is the relationship of the db to > the view? When the DB is updated is it the DBs job to inform the view > for it to update or does it inform the controller or .... C. do nothing > at all and just let the controller tell the view to update when it > thinks its best. I think there are varying schools of thought on this, because it depends what is easiest to do. For your case, I'd go through the controller. The controller will ask the DB for info, for updates, and so on, so it should get the responses. It may need to filter the information to pick out the pertinent stuff. That way you can change the DB to SQLite3 or whatever later, and only the DB and controller will be affected, if you've not managed to keep all the effects inside the DB classes. IIRC "Head First Design Patterns" (a good book, if you accept the cognitive psychology that drives the quirky style) I think says that often the Model (database) can just send stuff to the UI. But you are mainly concentrating on separation of concerns for this work, so unless performance becomes a problem, I'd go through the controller. > \> This bit belongs in the UI > \>\> def new\_task\_form > \>\> puts "Enter title for task" > \> # don't put this here: new\_task = Task.new > \>\> # new\_task.title = gets.chomp > \>\> # return new\_task > \> # You just want the UI to return a bunch of fields. the controller > \> # can validate them, and tell the UI: UI.bzzzt("Try again!"). > \>\> end > > ok so i shouldnt create an instance of task in the UI. Rahter just > return a bunch of fields (a hash \ array? )which contain the input from Yes, you can wrap them into a similar object, but they may not be valid things to create a real Task. When do you want this to end: 30-FEB-2009 for example. > the user and let the controller figure out what each field represents > and whether its valid input. The controller will create a Task instance > and then pass it to the DB. Yes > Question 3 > When the UI presents say a form for a task to the user to fill is it > good practice to have things like > > userinput = gets.chomp > > in the UI or should that be handled by the controller. Im wondering to > what degree logic and presentation are seperated. I'd say that's entirely in the court of the UI. Why? Because it would do different stuff if it was a web form, Tk dialogue box, interface operated by a blink-switch ....         Hugh > **路路路** > > On Tue, 11 Nov 2008, Adam Akhtar wrote: