Skip to main content

A little background first. I've been working on a fairly large Rails application which quickly grew into a breeding ground for "smelly" code. One antipattern we were using a lot was storing objects in an STI lookup table and having lots of scattered logic based on the name of the object.

Here's a dumbed down example of what we had:

class Lookup < ActiveRecord::Base
end

class AlarmStatus < Lookup
  has_many :alarm_logs
end

class AlarmLog < ActiveRecord::Base
  belongs_to :alarm_status
end

Then all over our application we would do things like:

case @alarm_log.alarm_status.name
when "active"
  # Do something
when "verified"
  # Do something
when "inactive"
  # Do something
end

This is obviously bad for a lot of reasons, but let's just say it was everywhere. After a few months of this, a consultant came along and pointed out our "code smell" and made some suggestions on how to refactor, which included a Ruby implementation of Java's Enum class.

We ended up using this frequently in our app, and have extracted into a ruby gem called classy_enum. The premise of classy_enum is that you get the power of OOP mixed with the strictness of an enumerated type, which is pretty much what we were trying to mimic with our STI Lookup model.

Example of defining an enum:

class Priority < ClassyEnum::Base
  enum_classes :low, :medium, :high

  def send_email?
    false
  end
end

class PriorityHigh < Priority
  def send_email?
    true
  end
end

The gem's READMEREADME has some other usage examples, including how to integrate it with a Rails project.

I may be asking for a lot here, but I would love some feedback from anyone willing to give it. It seems like a really cool solution to our problem and I can't imagine we're the only ones who have attempted to solve this before. Here's a list of questions that would be really useful for us:

  • Is this a common problem?
  • Does our solution make sense? Is there a better way to do it?
  • Is the documentation clear?
  • Would you use this in your application? Why or why not?
  • How could we improve it?
  • How is the code quality?

A little background first. I've been working on a fairly large Rails application which quickly grew into a breeding ground for "smelly" code. One antipattern we were using a lot was storing objects in an STI lookup table and having lots of scattered logic based on the name of the object.

Here's a dumbed down example of what we had:

class Lookup < ActiveRecord::Base
end

class AlarmStatus < Lookup
  has_many :alarm_logs
end

class AlarmLog < ActiveRecord::Base
  belongs_to :alarm_status
end

Then all over our application we would do things like:

case @alarm_log.alarm_status.name
when "active"
  # Do something
when "verified"
  # Do something
when "inactive"
  # Do something
end

This is obviously bad for a lot of reasons, but let's just say it was everywhere. After a few months of this, a consultant came along and pointed out our "code smell" and made some suggestions on how to refactor, which included a Ruby implementation of Java's Enum class.

We ended up using this frequently in our app, and have extracted into a ruby gem called classy_enum. The premise of classy_enum is that you get the power of OOP mixed with the strictness of an enumerated type, which is pretty much what we were trying to mimic with our STI Lookup model.

Example of defining an enum:

class Priority < ClassyEnum::Base
  enum_classes :low, :medium, :high

  def send_email?
    false
  end
end

class PriorityHigh < Priority
  def send_email?
    true
  end
end

The gem's README has some other usage examples, including how to integrate it with a Rails project.

I may be asking for a lot here, but I would love some feedback from anyone willing to give it. It seems like a really cool solution to our problem and I can't imagine we're the only ones who have attempted to solve this before. Here's a list of questions that would be really useful for us:

  • Is this a common problem?
  • Does our solution make sense? Is there a better way to do it?
  • Is the documentation clear?
  • Would you use this in your application? Why or why not?
  • How could we improve it?
  • How is the code quality?

A little background first. I've been working on a fairly large Rails application which quickly grew into a breeding ground for "smelly" code. One antipattern we were using a lot was storing objects in an STI lookup table and having lots of scattered logic based on the name of the object.

Here's a dumbed down example of what we had:

class Lookup < ActiveRecord::Base
end

class AlarmStatus < Lookup
  has_many :alarm_logs
end

class AlarmLog < ActiveRecord::Base
  belongs_to :alarm_status
end

Then all over our application we would do things like:

case @alarm_log.alarm_status.name
when "active"
  # Do something
when "verified"
  # Do something
when "inactive"
  # Do something
end

This is obviously bad for a lot of reasons, but let's just say it was everywhere. After a few months of this, a consultant came along and pointed out our "code smell" and made some suggestions on how to refactor, which included a Ruby implementation of Java's Enum class.

We ended up using this frequently in our app, and have extracted into a ruby gem called classy_enum. The premise of classy_enum is that you get the power of OOP mixed with the strictness of an enumerated type, which is pretty much what we were trying to mimic with our STI Lookup model.

Example of defining an enum:

class Priority < ClassyEnum::Base
  enum_classes :low, :medium, :high

  def send_email?
    false
  end
end

class PriorityHigh < Priority
  def send_email?
    true
  end
end

The gem's README has some other usage examples, including how to integrate it with a Rails project.

I may be asking for a lot here, but I would love some feedback from anyone willing to give it. It seems like a really cool solution to our problem and I can't imagine we're the only ones who have attempted to solve this before. Here's a list of questions that would be really useful for us:

  • Is this a common problem?
  • Does our solution make sense? Is there a better way to do it?
  • Is the documentation clear?
  • Would you use this in your application? Why or why not?
  • How could we improve it?
  • How is the code quality?
deleted 90 characters in body; edited tags; edited title
Source Link
Jamal
  • 35.2k
  • 13
  • 134
  • 238

Looking for Feedback on RubyGem for Enums

A little background first... I've I've been working on a fairly large Rails application which quickly grew into a breeding ground for "smelly" code. One antipattern we were using a lot was storing objects in an STI lookup table and having lots of scattered logic based on the name of the object. 

Here's a dumbed down example of what we had:

class Lookup < ActiveRecord::Base
end

class AlarmStatus < Lookup
  has_many :alarm_logs
end

class AlarmLog < ActiveRecord::Base
  belongs_to :alarm_status
end

Then all over our application we would do things like:

case @alarm_log.alarm_status.name
when "active"
  # Do something
when "verified"
  # Do something
when "inactive"
  # Do something
end

This is obviously bad for a lot of reasons, but let's just say it was everywhere. After a few months of this, a consultant came along and pointed out our "code smell" and made some suggestions on how to refactor, which included a Ruby implementation of Java's Enum class.

We ended up using this frequently in our app, and have extracted into a ruby gem called classy_enum. The premise of classy_enum is that you get the power of OOP mixed with the strictness of an enumerated type, which is pretty much what we were trying to mimic with our STI Lookup model.

Example of defining an enum:

class Priority < ClassyEnum::Base
  enum_classes :low, :medium, :high

  def send_email?
    false
  end
end

class PriorityHigh < Priority
  def send_email?
    true
  end
end

The gem's README has some other usage examples, including how to integrate it with a Rails project.

I may be asking for a lot here, but I would love some feedback from anyone willing to give it. It seems like a really cool solution to our problem and I can't imagine we're the only ones who have attempted to solve this before. Here's a list of questions that would be really useful for us:

  • Is this a common problem?
  • Does our solution make sense? Is there a better way to do it?
  • Is the documentation clear?
  • Would you use this in your application? Why or why not?
  • How could we improve it?
  • How is the code quality?

Thanks for taking the time to read this and anything you provide is greatly appreciated!

Looking for Feedback on RubyGem for Enums

A little background first... I've been working on a fairly large Rails application which quickly grew into a breeding ground for "smelly" code. One antipattern we were using a lot was storing objects in an STI lookup table and having lots of scattered logic based on the name of the object. Here's a dumbed down example of what we had:

class Lookup < ActiveRecord::Base
end

class AlarmStatus < Lookup
  has_many :alarm_logs
end

class AlarmLog < ActiveRecord::Base
  belongs_to :alarm_status
end

Then all over our application we would do things like:

case @alarm_log.alarm_status.name
when "active"
  # Do something
when "verified"
  # Do something
when "inactive"
  # Do something
end

This is obviously bad for a lot of reasons, but let's just say it was everywhere. After a few months of this, a consultant came along and pointed out our "code smell" and made some suggestions on how to refactor, which included a Ruby implementation of Java's Enum class.

We ended up using this frequently in our app, and have extracted into a ruby gem called classy_enum. The premise of classy_enum is that you get the power of OOP mixed with the strictness of an enumerated type, which is pretty much what we were trying to mimic with our STI Lookup model.

Example of defining an enum:

class Priority < ClassyEnum::Base
  enum_classes :low, :medium, :high

  def send_email?
    false
  end
end

class PriorityHigh < Priority
  def send_email?
    true
  end
end

The gem's README has some other usage examples, including how to integrate it with a Rails project.

I may be asking for a lot here, but I would love some feedback from anyone willing to give it. It seems like a really cool solution to our problem and I can't imagine we're the only ones who have attempted to solve this before. Here's a list of questions that would be really useful for us:

  • Is this a common problem?
  • Does our solution make sense? Is there a better way to do it?
  • Is the documentation clear?
  • Would you use this in your application? Why or why not?
  • How could we improve it?
  • How is the code quality?

Thanks for taking the time to read this and anything you provide is greatly appreciated!

RubyGem for Enums

A little background first. I've been working on a fairly large Rails application which quickly grew into a breeding ground for "smelly" code. One antipattern we were using a lot was storing objects in an STI lookup table and having lots of scattered logic based on the name of the object. 

Here's a dumbed down example of what we had:

class Lookup < ActiveRecord::Base
end

class AlarmStatus < Lookup
  has_many :alarm_logs
end

class AlarmLog < ActiveRecord::Base
  belongs_to :alarm_status
end

Then all over our application we would do things like:

case @alarm_log.alarm_status.name
when "active"
  # Do something
when "verified"
  # Do something
when "inactive"
  # Do something
end

This is obviously bad for a lot of reasons, but let's just say it was everywhere. After a few months of this, a consultant came along and pointed out our "code smell" and made some suggestions on how to refactor, which included a Ruby implementation of Java's Enum class.

We ended up using this frequently in our app, and have extracted into a ruby gem called classy_enum. The premise of classy_enum is that you get the power of OOP mixed with the strictness of an enumerated type, which is pretty much what we were trying to mimic with our STI Lookup model.

Example of defining an enum:

class Priority < ClassyEnum::Base
  enum_classes :low, :medium, :high

  def send_email?
    false
  end
end

class PriorityHigh < Priority
  def send_email?
    true
  end
end

The gem's README has some other usage examples, including how to integrate it with a Rails project.

I may be asking for a lot here, but I would love some feedback from anyone willing to give it. It seems like a really cool solution to our problem and I can't imagine we're the only ones who have attempted to solve this before. Here's a list of questions that would be really useful for us:

  • Is this a common problem?
  • Does our solution make sense? Is there a better way to do it?
  • Is the documentation clear?
  • Would you use this in your application? Why or why not?
  • How could we improve it?
  • How is the code quality?
edited tags
Link
konijn
  • 34.4k
  • 5
  • 71
  • 267
Source Link
Loading