behaves 0.1.1 → 0.2.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: a306c547822ce551aa1e2c6f8073eca5ba9c9e91526bfad490368845af6e5185
-  data.tar.gz: c31eaf7f25270f52bcce238b0bd6a601e1a4c96a38ada2f22546aa149f32af28
+  metadata.gz: cd22ae5f7d6af9cc2a76a8d7b73d7ec25af7c759afac262731ef56c79f1d9a3b
+  data.tar.gz: b5abbc034aa95a5067bed0ce7eb2f5472c6b3e89333d8128806499ea25d38fdc
 SHA512:
-  metadata.gz: 6d0a66ad83736a1c0bae7dfdbdca4bb7f9af48c6b8043f7cc0066e2dea68b16e9e776bc603272e15c063912dee3fa6972ccc0a178098fd891158f366b38421ed
-  data.tar.gz: 2dae6fcdc1e832fa8e2e2f4e6d9485f4925f6ba355b92b5a601288d379afe466b8c2e4062ae8d8c66c71d18561bc9bead9ef50bfad13b128376519d2768b28aa
+  metadata.gz: a809170ad8c43554ee5a6845ec558ce803a766ec216a088c7fb21b6b92c355dc5d618b340a48fdf5eb4cb80079d40c429622d8a344998a3a278454aa84414129
+  data.tar.gz: 1ed4e8d27bd2171cc0e2020c1fa869ff099c887ebaeb2ef35c4d639c715d5b5e3787910e272a99b7a5c0b5fe0e31fc0af29715f1de40364652bd32bca113c4ac

data/Gemfile.lock

@@ -1,7 +1,7 @@
 PATH
   remote: .
   specs:
-    behaves (0.1.0)
+    behaves (0.1.1)
 
 GEM
   remote: https://rubygems.org/

data/README.md

@@ -1,56 +1,57 @@
-## Installation
-
-Add this line to your application's Gemfile:
-
-```ruby
-gem 'behaves'
-```
-
+![CircleCI Badge](https://img.shields.io/circleci/build/github/edisonywh/behaves.svg)
+![RubyGems Badge](https://img.shields.io/gem/v/behaves.svg)
+![Code Climate maintainability](https://img.shields.io/codeclimate/maintainability/edisonywh/behaves.svg)
 
 # Behaves
 
-Behaves is a gem that helps you maintain contracts between different classes. This is especially useful for dealing for adapter patterns by making sure that all of your adapters define the required behaviors.
-
-For example, you can specify that class `Dog` and class `Cat` should both behave the same as `Animal`, or that your `ApiClientMock` should behave the same as the original `ApiClient` (more explanation below)
-
-The idea for `Behaves` stemmed from my research into [adapter pattern in Ruby](https://www.sitepoint.com/using-and-testing-the-adapter-design-pattern/) and José Valim's article on [Mocks and explicit contracts](http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-contracts/).
-
-I found that the current idiom to achieve `behaviors` in Ruby is through `Inheritence`, and then subsequently defining a "required" (I put quotation marks around it, because it's not exactly `required` until you run it) method, which does nothing except raising a `NotImplementedError`. While I don't necessarily think it's *bad*, I do think that there could be an alternative that's **more explicit**, **less boilerplate**, **cleaner ancestors hierachy**, thus the birth of `Behaves`.
-
-## Cons of inheritance
+Behaves is a gem that helps you define behaviors between classes. **Say goodbye to runtime error when defining behaviors.**
 
-Let's dive into the cons of implementing behaviors through `Inheritance`
+Behaves is especially useful for dealing with adapter patterns by making sure that all of your adapters define the required behaviors. See [usage below](https://github.com/edisonywh/behaves#usage) for more examples.
 
-First, I think this is a very opaque implementation - at a quick glance, there's no real way to know if there are any behaviors required. The only way to be sure is to dive into the parent class and look for any methods that does nothing but raises a `NotImplementedError`. This gets cascadingly worse if you have multiple hierachy of inheritance.
+*Detailed explanations in the sections below.*
 
-Secondly, with inheritance, the behavioral contract is dependent upon the method lookup chain - this poses a few issues:
+## Installation
 
-1) `Unused code` - You now have a stub method on your parent class that does nothing but raise an error, and it won't be used any longer after it's your behaviors are adhered to.
+Add this line to your application's Gemfile:
 
-2) `Fragile implementation` - You are reliant on the ancestor chain not being intercepted. For example, if someone else on your team defines a method that has the same name as your behavior, but sits higher up the chain (through `prepending` for example), your stub method is now useless and won't ever catch if a behavior is not implemented.
+```ruby
+gem 'behaves'
+```
 
-3) `Runtime errors` - There are possibility for runtime errors. If a child did not adhere to the required behaviors, your code won't actually know that until it tries to call the method on child class. Error on production? Not good.
+## Usage
 
-## How does `Behaves` solve this problem?
+This is how you define behaviors with `behaves`.
 
-Behaves aim to solve this problem by being **explicit** and **upfront**:
+First, define required methods on the `Behavior Object` with the `implements` method, which take a list of methods.
+```ruby
+class Animal
+  extend Behaves
 
-- A very clear `behaves_like Animal` that indicates that this class has a certain behaviors to adhere to, as implemented by `Animal`.
+  implements :speak, :eat
+end
+```
 
-- Guarantee to catch implementation deviation regardless of the ancestor chains.
+Then, you can turn any object (the `Behaving Object`) to behave like the `Behavior Object` by using the `behaves_like` method, which takes a `Behavior Object`.
+```ruby
+class Dog
+  extend Behaves
 
-- With the way Behaves is written, your code will fail to even load if you don't adhere to the behaviors upfront - **no more runtime errors in production**.
+  behaves_like Animal
+end
+```
 
-- No need to define a stub method that does nothing - behaviors checking are done through symbols, as defined in `implements` by the behaviorial class.
+Voilà, that's all it takes to define behaviors! Now if `Dog` does not implement `speak` and `eat`, your code will then throw error **on file load**, instead of **at runtime**.
 
-See below for more examples about how `Behaves` work.
+```diff
+- NotImplementedError: Expected `Dog` to behave like `Animal`, but `speak, eat` are not implemented.
+```
 
-## Usage
+This is in stark contrast to defining behaviors with inheritance. Let's take a look.
 
-Let's take a look how to define behaviors using `Inheritance`.
+### Inheritance-based behaviors
 
 ```ruby
-# Inheritance Behaviors
+# Inheritance - potential runtime error.
 class Animal
   def speak
     raise NotImplementedError, "Animals need to be able to speak!"
@@ -65,44 +66,98 @@ class Dog < Animal
   def speak
     "woof"
   end
-
-  def eat
-    "chomp"
-  end
 end
 ```
 
-You have now defined `Animal#speak` and `Animal#eat` which are not useful at all, along with all the issues I pointed out earlier.
+1) It is unclear that `Dog` has a certain set of behaviors to adhere to.
 
-Now let's take a look at how `Behaves` work.
+2) Notice how `Dog` does not implement `#eat`? Inheritance-based behaviors have no guarantee that `Dog` adheres to a certain set of behaviors, which means you can run into runtime errors like this.
 
 ```ruby
-class Animal
+corgi = Dog.new
+corgi.eat
+# => NotImplementedError, "Animals need to be able to eat!"
+```
+
+3) Another problem is you have now defined `Animal#speak` and `Animal#eat`, two stub methods of which they do nothing but raise an undesirable `NotImplementedError`.
+
+The power of `Behaves` does not stop here either.
+
+## Features
+
+### Multi-behaviors
+
+`Behaves` allow you to define multiple behavior for a single behaving object. **This is not possible with inheritance**.
+
+```ruby
+class Predator
   extend Behaves
 
-  implements :speak, :eat
+  implements :hunt
 end
 
-class Dog
+class Prey
   extend Behaves
 
-  behaves_like Animal
+  implements :run, :hide
+end
 
-  def speak
-    "woof"
-  end
+class Shark
+  extend Behaves
 
-  def eat
-    "chomp"
+  # Shark is both a `Predator` and a `Prey`
+  behaves_like Predator
+  behaves_like Prey
+end
+```
+
+### Inject Behaviors
+
+When someone decides to use `behaves` to define behaviors, they in turn lose the ability to utilize some other aspect of inheritance, one of it being inheriting methods.
+
+So, `Behaves` now ship with a feature called `inject_behaviors` for that need!
+
+```ruby
+class Dad
+  extend Behaves
+
+  implements :speak, :eat
+
+  inject_behaviors do
+    def traits; "Dad's traits!"; end
   end
 end
+
+class Child
+  extend Behaves
+
+  behaves_like Dad
+
+  def speak; "BABA"; end
+  def eat; "NOM NOM"; end
+end
+
+# Child.new.traits #=> "Dad's traits!"
 ```
 
-With `Behaves`, it is immediately obvious that Dog should behave like a certain class -> `Animal`, and you do not have to implement stub methods on `Animal`.
+This extends to more than just method implementation too, you can do anything you want! That's because the code inside `inject_behaviors` run in the context of the `Behaving Object`, also `self` inside `injected_behaviors` refers to the `Behaving Object`.
+
+*Do note that if you use this extensively, you might be better off using inheritance, since this will create more `Method` objects than inheritance.*
+
+## Tips
+If you do not want to type `extend Behaves` every time, you can monkey patch `Behaves` onto `Object` class, like so:
+
+> Object.send(:extend, Behaves)
 
 ## Thoughts
 
-Referring to the article by José Valim, I really liked the idea of being able to use Mock as a noun. However, while the idea sounds good, you've now introduced a new problem in your codebase -- your Mock and your original Object might deviate from their implementation later on. Not a good design if it breaks. Elixir has `@behaviors` & `@callback` built in to keep them in sync. `Behaves` is inspired by that.
+The idea for `Behaves` stemmed from my research into [adapter pattern in Ruby](https://www.sitepoint.com/using-and-testing-the-adapter-design-pattern/) and José Valim's article on [Mocks and explicit contracts](http://blog.plataformatec.com.br/2015/10/mocks-and-explicit-contracts/).
+
+I found that the current idiom to achieve `behaviors` in Ruby is through inheritence, and then subsequently defining 'required' methods, which does nothing except raising a `NotImplementedError`. This approach is fragile, as it **does not guarantee behaviors**, runs the **risk of runtime errors**, and has an **opaque implementation**.
+
+Thus with this comes the birth of `Behaves`.
+
+Also referring to the article by José Valim, I really liked the idea of being able to use Mock as a noun. However, while the idea sounds good, you've now introduced a new problem in your codebase -- your Mock and your original Object might deviate from their implementation later on. Not a good design if it breaks. Elixir has `@behaviors` & `@callback` built in to keep them in sync. `Behaves` is inspired by that.
 
 ## Development
 
@@ -117,7 +172,3 @@ Bug reports and pull requests are welcome on GitHub at https://github.com/edison
 ## License
 
 The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
-
-## Code of Conduct
-
-Everyone interacting in the Behaves project’s codebases, issue trackers, chat rooms and mailing lists is expected to follow the [code of conduct](https://github.com/[USERNAME]/behaves/blob/master/CODE_OF_CONDUCT.md).

data/lib/behaves/version.rb

@@ -1,3 +1,3 @@
 module Behaves
-  VERSION = "0.1.1"
+  VERSION = "0.2.0"
 end

data/lib/behaves.rb

@@ -6,21 +6,28 @@ module Behaves
     @behaviors ||= Set.new(methods)
   end
 
+  def inject_behaviors (&block)
+    @inject_behaviors ||= block
+  end
+
   def behaves_like(klass)
-    at_exit do
-      required = defined_behaviors(klass)
+    add_injected_behaviors(klass)
+    at_exit { check_for_unimplemented(klass) }
+  end
 
-      implemented = Set.new(self.instance_methods - Object.instance_methods)
+  private
 
-      unimplemented = required - implemented
+  def check_for_unimplemented(klass)
+    required = defined_behaviors(klass)
 
-      exit if unimplemented.empty?
+    implemented = Set.new(self.instance_methods - Object.instance_methods)
 
-      raise NotImplementedError, "Expected `#{self}` to behave like `#{klass}`, but `#{unimplemented.to_a.join(', ')}` are not implemented."
-    end
-  end
+    unimplemented = required - implemented
 
-  private
+    return if unimplemented.empty?
+
+    raise NotImplementedError, "Expected `#{self}` to behave like `#{klass}`, but `#{unimplemented.to_a.join(', ')}` are not implemented."
+  end
 
   def defined_behaviors(klass)
     if behaviors = klass.instance_variable_get("@behaviors")
@@ -29,4 +36,11 @@ module Behaves
       raise NotImplementedError, "Expected `#{klass}` to define behaviors, but none found."
     end
   end
+
+  def add_injected_behaviors(klass)
+    injected_behaviors = klass.instance_variable_get("@inject_behaviors")
+    if injected_behaviors
+      self.class_eval &injected_behaviors
+    end
+  end
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: behaves
 version: !ruby/object:Gem::Version
-  version: 0.1.1
+  version: 0.2.0
 platform: ruby
 authors:
 - Edison Yap
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2019-06-10 00:00:00.000000000 Z
+date: 2019-06-18 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: pry
@@ -92,7 +92,6 @@ files:
 - ".circleci/config.yml"
 - ".gitignore"
 - ".rspec"
-- ".travis.yml"
 - CODE_OF_CONDUCT.md
 - Gemfile
 - Gemfile.lock

data/.travis.yml

@@ -1,7 +0,0 @@
----
-sudo: false
-language: ruby
-cache: bundler
-rvm:
-  - 2.3.1
-before_install: gem install bundler -v 1.17.1