I have model named Order which belongs to User, Admin, Device etc.
I want to see total of orders for specific object like user.
so I have to write in user.rb model
def total_sales
// there are some dates & status conditions too
orders.sum(:total)
end
but for admin, device etc. I have to write exact same code in admin.rb & device.rb
I want to write code on just one place & write everywhere,
I was thinking to write a generic class like
class Calculate
def initialize(object)
#object = object
end
def total_sales
// there are some dates & status conditions too
#object.orders.sum(:total)
end
end
and than call it like
//sales of user
object = Calculate.new(user)
object.total_sales
//sales of admin
object = Calculate.new(admin)
object.total_sales
But I am not sure if this is standard way,
Whats the better way achieve this.
Use mixin for this, create a module like below.
module CommonMethods
def total_sales
// there are some dates & status conditions too
self.orders.sum(:total)
end
end
include the module in each class like User, Admin, Device etc.
class User
include CommonMethods
end
Related
I am working with ruby on rails and I am basically trying to include two modules into the same model/class with both modules having the same method names. An example will be demonstrated below, however my questions are:
Is there a way to include module conditionally? or
Is there a way to invoke based on the specific instance of the class.
An example is a simple complete profile wizard.
How its suppose to work
Case 1: If the user is lets say a Transporter, step_one is completed when the user has a company_name is present.
Case 2: On the otherhand if the user is a Client, step_one is completed when the user has a telephone present.
class User < ApplicationRecord
include ClientWizard
include TransporterWizard
end
module ClientWizard
def step_one_completed?
self.name.present?
end
end
module TransporterWizard
def step_one_completed?
self.company_name.present?
end
end
No, module methods all exist within the class's namespace. Consequently, this doesn't seem like a particularly good use case for modules.
You could give the methods module-specific names (client_wizard_step_one_completed?), but I'd recommend instead defining the wizards as separate classes, and passing the user instance as a parameter.
class User < ApplicationRecord
def client_wizard
ClientWizard.new(self)
end
end
class ClientWizard
def initialize(user)
#user = user
end
def step_one_completed?
#user.name.present?
end
end
I am currently refactoring a User model with over 800 lines of code (with several hundred more that have been added via mixins). Currently there are quite a few methods in the model like the ones below that are simply used to identify a type of user based off of some specific criteria.
def is_a_manager?
# logic to determine manager
end
def is_a_teacher?
# logic to determine teacher
end
def is_a_parent?
# logic to determine parent
end
def is_a_student?
# logic to determine student
end
def is_a_coach?
# logic to determine coach
end
def is_a_employee?
# logic to determine employee
end
What is the best way to refactor this code? Should I just put it in a concern and Include it in the class? Or should I extract all of these methods into its own separate class such as a UserIdentifier.new(user).is_teacher?? Or is this kind of refactor completely unnecessary?
You can use dry concept to check type:
def method_name(user_type)
//logic example
type == user_type
end
call method like:
User.method_name("Teacher")
I hope this help you.
I have a model called Coupon, which can either be set to have a money_off or percent_off attributes (it can only have one set at a time).
Also depending on whether the Coupon is money_off or percent_off changes which methods are used.
Im wondering if i should be using Single table inheritance to eseentially sub class Coupon and have a sub class that deals with percent off coupons and another dealing with money off coupons?
I would then like to know how a user would be able to select this from the view.
Here's an example that illustrates the usage of strategies (about which Yam posted a more detailed answer):
class Coupon < Struct.new(:original_price, :amount_off, :type)
def price_after_discount
discount_strategy.call(self)
end
private
def discount_strategy
# note: no hardcoding here
klass = type.to_s.camelize # :money_off to 'MoneyOff'
"Coupon::#{klass}".constantize.new
end
class MoneyOff
def call(coupon)
coupon.original_price - coupon.amount_off
end
end
class PercentOff
def call(coupon)
coupon.original_price * (1.0 - coupon.amount_off / 100.0)
end
end
end
Coupon.new(150, 10, :money_off).price_after_discount # => 140
Coupon.new(150, 10, :percent_off).price_after_discount # => 135.0
Now, instead of creating a strategy internally, we can accept it in constructor, thus making the strategy "injectable".
The best way is to determine which functionality you require for each class. If you only need a small amount of changes, then stick to a single class with an enum:
#app/models/coupon.rb
class Coupon < ActiveRecord::Base
enum type: [:percent, :money]
def value
if type.percent?
# ...
elsif type.money?
# ...
end
end
end
This will allow you to use the type in your instance methods, which shouldn't cause such a problem if you didn't have a lot of changes to make within the class.
This would allow you to call:
#coupon = Coupon.find x
#coupon.value #-> returns value based on the type
--
The alternative (STI) would be more of a structured change, and would only work if you were referencing each class explicitly:
#app/models/coupon.rb
class Coupon < ActiveRecord::Base
end
#app/models/percent.rb
class Percent < Coupon
def amount
# ...
end
end
#app/models/money.rb
class Money < Coupon
def takeout
# ...
end
end
An important factor here is how you call these.
For the above classes, you have to reference the subclassed classes on their own:
#percentage_coupon = Percent.find x
#money_coupon = Money.find y
This will obviously be more cumbersome, and may even cause problems with your routes & controllers etc.
.... so it may be best going with the single class :)
What you can do is maintain the strategy internally, and provide methods such as price, discounted?, discounted_price. In addition, whether or not the admin chose to enter percentages or fixed units, you can still supply both methods: discount_pct, discount_units which would internally realize how to compute their return values.
This way the original class still supports the concept (same as the data model), yet is also flexible enough to allow various ways of providing it the necessary input. Whether you wish to show customers the pct off, or the fixed price units, you can do so independently of the admin's preferred method of input.
Even internal methods can use these abstractions. And if it turns out you're if/elsing all over the place internally, you can create nested classes for strategies and instantiate the right one once you get the record from the DB.
I am really struggling with the delegate concept and how to put it into practice.
I have a Contract model which has the following fields:
company_id,
contract_type (Standard, Unlimited, Guaranteed etc etc),
fixed_cost,
cost_per_hour,
included_time,
time_credit,
there is an Invoice model which belongs to Contract and has the following fields:
contract_id,
startdate,
enddate,
total_time_used,
start_credit,
end_credit,
total_cost
I want to run a service object to create an Invoice instance, populate the total_time_used(from another table), start_credit (from the Contract table) and then calculate the total_cost. This is calculated using data from the Contract table and the methodology is different depending on the contract_type in the Contract model e.g. Standard, Unlimited.
I don't want a big if statement in the service object as there may end up being multiple types of contract. I see that I can have Standard, Unlimited classes with the same named method but different functionality e.g. calculate_cost but I can't quite see how to actually do it such that this method also uses data retrieved from the Contract table.
Does that make sense - probably not but if it does any guidance will be gratefully received.
Your service object class should look like:
class Service
attr_reader :contract
delegate :method1, :method2, to: :contract
def initialize(contract)
#contract = contract
end
end
Then you can call method1 and method2 directly inside Service
Delegate? You mean inheritance? It seems like your problem is calculating total cost, based on the type of contract. This is typically solved using inheritance on Contract. e.g. define a StandardContract and UnlimitedContract which both derive from Contract. Problem here is: when using ActiveRecord models you will have to switch to single table inheritance (STI).
An alternative is just extracting the calculation. So in lib/contract_calculator.rb you write
class ContractCalculator
def initialize(contract)
#contract = contract
end
def total_cost(invoice)
# default implementation or empty?
end
end
and then you can add your sub-classes. In lib\standard_contract_calculator.rb
class StandardContractCalculator < ContractCalculator
def total_cost(invoice)
# do the calculation for a standard-contract
end
end
In lib\unlimited_contract_calculator.rb
class UnlimitedContractCalculator < ContractCalculator
def total_cost(invoice)
# do the calculation for a standard-contract
end
end
Now you can add the following code to Contract
def calculator
#calculator = if contract_type == 'Standard'
StandardContractCalculator.new(self)
elsif contract_type == 'Unlimited'
UnlimitedContractCalculator.new(self)
else
ContractCalculator.new(self)
end
end
def total_cost(invoice)
calculator.total_cost(invoice)
end
I made some shortcuts, like I have no idea how you decide what type of contract it is. So that "factory" code (creating the correct calculator based on the contract) you will definitely have to adapt. I assumed invoice to be a parameter, for simplicity. You could also hand it down in the constructor?
Hopefully this will get you started in the right direction.
I am using Rails 4.0.2 and Devise 3.2.2 to handle user registration / authentication.
I would like to write a custom method for Devise's current_user , this method is for checking how many times does the current_user sign in. I will be using sign_in_count
Do I write the method in the User model or should I define the method in Users Controller ?
Is it possilbe to write something like the below
def count
user = current_user
user.sign_in_count
end
and call current_user.count ?
Thanks
----edited----
What if I need to add other methods, am I able to add something like the below
#app/controllers/post_controller.rb
before_action :check_time
def check_time
time = User.last_sign_in_at(current_user)
if # something
# do bla bla
end
end
Do I write the method in the User model or should I define the method in Users Controller ?
It depends where (& when) you want to use the method
If you're going to use it as part of the "controller-level" interactivity, you'll want to put it into the UsersController, but if it's going to be used on "model-level" (by multiple controllers / models), you may wish to put it into the model
Something you need to be aware of is that current_user is a helper, and is not available at model level:
#app/controllers/products_controller.rb
def lookup
sign_ins = User.sign_in_count(current_user)
if sign_ins > 10
#do something
end
end
#app/models/user.rb
Class User < ActiveRecord::Base
def self.sign_in_count(user)
user = find(user.id)
user.sign_in_count
end
end
But as stated by #apneadiving, a far more efficient way to do this is to reference the current_user.sign_in_count attribute directly
Update
In reference to your update, you'll be best reading up about class & instance methods
You could perform the method like this:
#app/controllers/post_controller.rb
before_action :check_time
private
def check_time
time = current_user.last_sign_in_at
if # something
# do bla bla
end
end
In my references to model / controller methods - you'd use model methods if you wanted to give standard functionality on an app-wide level (such as User.weight_gain?). If you're using controller-centric data, you're best to keep it all in the controller