Friday, December 29, 2017
@andre the issue is you are trying to dump walls of code (text) in a single file. The complexity of your application will increase a lot, you will have one BIG simulate method that does everything, such big methods are hard to understand after a few weeks even by the developer that wrote them. In general good code is written in a way that hides complexity from the rest of the system, so, what its actually maintainable is to have code that works by hiding complexity. Something like a model, for example, User.first, its nice to use because its hiding the complexity of connecting to the DB, building the query and mapping record into a ruby object, imagine having that code dumped into each model file, wouldnt it make finding your own code or navigating around different part of the code confusing? now imagine dumping that code directly in the controller, having a controller connect to the DB, build the query and handle the edge case and then loading a ruby object with the returned record? that would surely make controllers a mess, instead of having the short methods like
-- ```
def index
@users = User.all
end
```
it would be
```
def index
HUGE ALL OF CODE THAT NO ONE WANTS TO READ
end
```
you are talking the path of the second example.
So how is this problem solved? there are several best practices, like encapsulation, and limiting responsibility of what you are putting in a file. In Object Oriented Programming we aim at hiding complexity inside classes, think of classes as kitchens, like the ones in cafeterias,
they have a small window, an order comes in on a small piece of paper and a dish comes out, how the dish is made and how many cooks are in the kitchen is not something that customers or waiter should be concern. Your controller is a class, it takes one argument calles the
Request object from rails, that object has the params and session information, the controller uses it to decide if it should respond with success, redirect or deny access. During one of those decisions it might ask a class for a value, and there is a chance that a class is an active record model, but the controller does not know that and does not care where User.first got its value, to the controller its just a ruby object, period. You are trying to change that pattern, you want to make a controller that will calculate a "Simulation" something that might imply a lot of code and needless complexity.
You will have this
```
def simulate
HUGE CHUNK OF CODE THAT YOU WILL NOT UNDERSTAND IN A MONTH FROM NOW
end
```
Instead you should have something like this
```
def simulate
@simulation = Simulation.new(HomeTeam.new(params[:home_team]), AwayTeam.new(params[away_team]))
if @simulation.valid? # check if the simulation makes sense inside that method and hide everything from the controller
flash[:notice] = "this are the results"
else
flash[:error] = 'Simulation parameters are invalid'
redirect_to :show
end
end
```
In the above example the controller does not know where the simulation values come from, its only responsibility is the decision of where to send the user, this is what rails does, it scopes stuff, this is why its split into model, view and controller, to make your code simpler.
Like it was mentioned by Hassan, you need to read about Object Oriented programming because you are creating a very complex solution for a very simple problem.
Let me finish by saying that if this is a throw away project you are doing to learn, this is the right moment to learn OOP. If you think the reading we suggesting is too much effort for a throw away app you are mistaken, reading/learning OOP will prepare you for your career as a developer since the mistake you are making right here is a very beginners mistake and it will show in any job you apply to.
On Mon, Dec 25, 2017 at 9:35 PM, André Luiz Abdalla Silveira <andreluizsa00@gmail.com> wrote:
First of all, Happy holidays to you folks.--Secondly, I'd like to deeply appreciate the help you're giving meHassan, I'll search for this material you've suggested ^^. But I didn't understand why this doesn't belong to the controller (since it's on the controller), but I hope I can make it clearer at the end of this message. I also have a difficulty on describing my problem as a set of tests, since it's not completely clear to me the complete set of states of execution my app will go throughRadhames, I couldn't understand what you tried to tell me there (copying what you said) --> "the controller is a class that should only be handle handling where to direct the request, not actually performing operations on the data or whatever."Talking about what I want to do. My long-term goal is to simulate a MLB season game by game (with every kind of play and player). To achieve it, I want to build a method to simulate a match. By now, and as a short-term goal, I want to produce a generic result, and important for me is building a good algorithm not depending on where to build it (controller, model, or helper -- it sounds a little freak to me to make on the view (I'm doing it, but I swear it's just provisory LOL))In a close future, I want to take the simulation to next level, creating a model for pitchers and batters. But again, it's something for future steps.I know I have a long way to go through on learning Rails, but on groups like these, my learning goes fasterAgain, thank you, Hassan and Radhames
Em sábado, 23 de dezembro de 2017 06:03:24 UTC-2, André Luiz Abdalla Silveira escreveu:Guys, I'm making a baseball league application, and I'm facing some challenges. Biggest of them is trying to make a match simulation method (I didn't think a view was necessary for it). This method is in matches_controller.rb, but again, there isn't any view for that. How do you think I should handle it? Have you ever faced any similar trouble?Git repository: https://github.com/dede999/myMLB PS: I love sports at all, so if you have a hockey application to share (it doesn't have to be written in Rails), please do it
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com .
To post to this group, send email to rubyonrails-talk@googlegroups.com .
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/acd64e74- .d9bc-4440-9e51-cdd0ca24d833% 40googlegroups.com
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscribe@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/CANkJ5gm%2B0-7pB9WKqhigsQA1%2BUdG5ScQ%2BwFTpTq%2BD-Bhx%2BQmaQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment