<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>OOP on BoochTek, LLC</title><link>https://blog.boochtek.com/categories/oop/</link><description>Recent content in OOP on BoochTek, LLC</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 23 Feb 2015 23:50:28 +0000</lastBuildDate><atom:link href="https://blog.boochtek.com/categories/oop/index.xml" rel="self" type="application/rss+xml"/><item><title>Hexagonal Rails Controllers</title><link>https://blog.boochtek.com/posts/hexagonal-rails-controllers/</link><pubDate>Mon, 23 Feb 2015 23:50:28 +0000</pubDate><guid>https://blog.boochtek.com/posts/hexagonal-rails-controllers/</guid><description>&lt;p&gt;I&amp;rsquo;ve had a long love-hate relationship with Rails. I love the MVC framework and how it&amp;rsquo;s improved our speed of writing web apps. But I&amp;rsquo;ve never really been completely happy with it. I don&amp;rsquo;t generally agree with most of its opinions. I prefer models that follow the Data Mapper pattern, not the Active Record pattern. This includes separating the persistence layer from the models&amp;rsquo; business logic. I prefer Slim or HAML to ERB. I prefer RSpec to Test::Unit or MiniTest. When Merb hit the scene, I was ready to make the jump, until Merb merged with Rails.&lt;/p&gt;</description></item><item><title>Includable ActiveRecord</title><link>https://blog.boochtek.com/posts/includable-activerecord/</link><pubDate>Mon, 10 Feb 2014 12:09:53 +0000</pubDate><guid>https://blog.boochtek.com/posts/includable-activerecord/</guid><description>&lt;p&gt;I created a Ruby gem recently, called &lt;a href="https://github.com/boochtek/includable-activerecord"&gt;includable-activerecord&lt;/a&gt;. It&amp;rsquo;s pretty small, but I thought I might explain why I created it, and discuss its implementation.&lt;/p&gt;
&lt;h1 id="classical-inheritance"&gt;Classical Inheritance&lt;/h1&gt;
&lt;p&gt;When you use ActiveRecord, you normally include it in your model like this:&lt;/p&gt;
&lt;pre&gt;&lt;code&gt;class User &amp;lt; ActiveRecord::Base
# ...
end
&lt;/code&gt;&lt;/pre&gt;
&lt;p&gt;Your &lt;code&gt;User&lt;/code&gt; class is inheriting from the &lt;code&gt;ActiveRecord::Base&lt;/code&gt; class. This is class-based inheritance, also called &amp;ldquo;classical&amp;rdquo; inheritance. (That&amp;rsquo;s &amp;ldquo;classical&amp;rdquo; as in &amp;ldquo;class&amp;rdquo;, not as a synonym for &amp;ldquo;traditional&amp;rdquo;.) Class-based inheritance represents an &amp;ldquo;is-a&amp;rdquo; relationship. So we&amp;rsquo;re saying that a user is an ActiveRecord base. Another way to say this is that &lt;code&gt;User&lt;/code&gt; is a subclass of &lt;code&gt;ActiveRecord::Base.&lt;/code&gt;&lt;br&gt;
&lt;br&gt;
There are a few problems with this. First, what is a &amp;ldquo;base&amp;rdquo;? The name was chosen because it&amp;rsquo;s a base class. But just like we don&amp;rsquo;t give factory classes names like &lt;code&gt;UserFactory&lt;/code&gt; (at least not in Ruby), we shouldn&amp;rsquo;t name base classes &lt;code&gt;Base&lt;/code&gt;.&lt;/p&gt;</description></item><item><title>Testing Rails Validators</title><link>https://blog.boochtek.com/posts/testing-rails-validators/</link><pubDate>Sun, 26 Jan 2014 23:27:07 +0000</pubDate><guid>https://blog.boochtek.com/posts/testing-rails-validators/</guid><description>&lt;p&gt;It&amp;rsquo;s challenging to test Rails custom validators.&lt;/p&gt;
&lt;p&gt;I recently had to write a validator to require that an entered date is before or after a specified date.&lt;/p&gt;
&lt;p&gt;It didn&amp;rsquo;t seem like writing the validator would be too difficult &amp;ndash; I&amp;rsquo;ve written custom validators before, and date comparisons aren&amp;rsquo;t all that tricky. But when it came time to write the tests, I ran into several issues. And since I always try to follow TDD / test-first, I was blocked before I even began.&lt;/p&gt;</description></item></channel></rss>