[rads]

> First, the name merely combines two values. What will happen when requirements change and we need to ensure that the provided experience includes at least 3 years of activity? The meaning of has_public_experience? will change along with its behavior and lead to surprises for developers unfamiliar with these particular details. It will no longer merely be existince of experience allowed for the public.

The problem is not the boolean, it's that we're using the wrong name for the method. Just choose a better name:

    class ProfilePresenter < ::Presenter
      def display_experience?
        profile.has_experience? && profile.experience_public?
      end
    end

The advantage of this over a block is that you can use this in more than one spot on the page. What if you wanted to show a special badge for users with experience in a different place? You'll end up extracting out this logic anyways -- it will just be hidden by another layer.

> This leads us to the second problem: the intent of the method is to display features, not query for values. Were we to stick with a query method like has_public_experience? we would end up considering the content inside the view along with the meaning of the method every time we read this code.

When you move up and down the ladder of abstraction[1], make it clear. When you're talking about "has_experience? && experience_public?", the new name "with_experience" does not communicate that we're hiding details, nor does "block.call" when you look at the new method. The name "display_experience?" makes it clearer that we're now moving to a higher rung, the view.

[1] http://worrydream.com/LadderOfAbstraction/

[saturnflyer]

Thanks for some fantastic feedback. I haven't read the worrydream link yet, but will check it out.