Tag Archives: Data Hiding

Stupid Doc Tricks In Elixir

July 16, 2014 By in Elixir, User Groups Tags: , Leave a comment

So last night we had our first Detroit Erlang/Elixir meetup and as part of it I wanted to do a little coding exercise to help people to get their feet wet with Erlang and/or Elixir, as they chose.  We simply worked through FizzBuzz and we came up with two different Elixir solutions and two different Erlang solutions. I never stop being surprised by developer creativity.

That said, I keep striving to improve the code I write and striving to use the tools that the language provides me.  Elixir has module attributes and it’s also got module documentation as a first class citizen in the language.  So I thought to myself why not extend my simple fizzbuzz code a bit to use these two features–to better learn how to use them.  Here’s the code such as it is:


defmodule FizzBuzz do
@fizz 3
@fizzmsg "Fizz"
@buzz 5
@buzzmsg "Buzz"

@moduledoc "
Ye olde FizzBuzz test in all of its glory.
If the number is a multiple of #{@fizz} then print #{@fizzmsg}.
If the number is a multiple of #{@buzz} then print #{@buzzmsg}.
If it's a multiple of both then print #{@fizzmsg<>@buzzmsg}.
Else print the number itself.

Example usage:
iex> for i <- 1..100, do: FizzBuzz.getFB(i)
1
2
#{@fizzmsg}
4
#{@buzzmsg}
"

  def getFB(n) do
    cond do
      rem(n,@fizz) == 0 and rem(n,@buzz) == 0 ->
        IO.puts @fizzmsg <> @buzzmsg
      rem(n,@fizz) == 0 ->
        IO.puts @fizzmsg
      rem(n,@buzz) == 0 ->
        IO.puts @buzzmsg
      true ->
        IO.puts "#{n}"
    end
  end
end

Now the code itself isn’t anything very special.  But the module attributes and the fact that I can avoid specifying magic numbers is just awesome.  What if I wanted to change the code to print “Argh!” on 3 instead of “Fizz”?  Of course were I to change the number for “Fizz” then I would need to make more extensive changes but this does cover one common type of change. With the code set up in this way, I only need to change things in one place and my docs will be updated as well as my code.

I know this is sort of a “Stupid Doc Trick” but it still seemed worth sharing with others.  The idea of only needing to change a constant in one place and having everything else update is a very appealing one.

You Might As Well Make All Your Class Members Public

February 18, 2012 By in Software Engineering Tags: , , 5 Comments

So recently some of us were discussing the fact that F# 3.0 is going to add a feature to make it more amenable to OO programmers.  F# 3.0 will add automatic “getters” and “setters” for members of a class. A small digression; I prefer the terms “inspector” and “mutator” because they seem more precise.

If it were up to me, though, most OO code would not use inspectors and mutators.  Why? Because the use of inspectors and mutators can defeat information hiding which is one of the principle benefits of object orientation. I’ll explain.  Let’s pretend we have a class C which contains a data member _m1.  This data member is an integer.  Something like this:

public class C
{
    private integer _m1;
    public integer m1 {
        get
        {
            return _m1;
        }
        set
        {
            _m1 = value;
        }
}

Now let’s say you need to reference m1 from other places in your code.  Everywhere you need to reference m1, you need to specify that m1 is an integer.  Every place in code that you need to set m1, you have to set an integer.  Now later on we may find that m1 needs to be a floating point.  Because I’ve got a public getter and setter, I now need to know about code which is referencing my class and I may need to modify that code.  This is violating the whole notion of encapsulation that we adopted OO to get.  And what if I’m sharing my code to other teams?  I might break their code and never even know about it.  At this point I might as well dispense with the private _m1 member because it’s not helping anything and in fact it’s just more work to maintain. I might as well not bother using private members.

Now some might say—well, what are you suggesting?  No inspectors or mutators?  I’d suggest we don’t need them as much as I’ve seen some OO programmers abuse this facility.  I’d also suggest another way to get back the encapsulation is to hide the actual type of the member behind something that indicates the significance of the value.   Like this example:

using EmployeeCount=System.Int32;

public class C
{
    private EmployeeCount _m1;
    public EmployeeCount m1 {
        get
        {
            return _m1;
        }
        set
        {
            _m1 = value;
        }
}

If I hide the actual type of _m1 behind EmployeeCount if I ever need to change the type of _m1 I only need to change it in one place and I don’t have to worry about code which accesses my class.  I’ve regained the encapsulation that I lost via opening part of the class’ internal details.