DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Newsletter
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Related

  • Testing Business Programs Without Constructing Domain Objects
  • Momento Migrates Object Cache as a Service to Ampere® Altra®
  • Why I Ditched Redis for Cloudflare Durable Objects in My Rate Limiter
  • Real-Object Detection at the Edge: AWS IoT Greengrass and YOLOv5

Trending

  • Microsoft Fabric Throttling: Diagnose Before You Scale
  • Top Gen AI Frameworks for Go in 2026: A Hands-On Comparison
  • Evaluating RAG in Production — What the Numbers Actually Revealed
  • AI Agents Need an Identity Plane: Rethinking Enterprise Authorization for Autonomous Software

Draft This article hasn't been published, so readers can't see it.

In moderation This article is waiting for review, so readers can't see it yet.

Deleted This article has been deleted, so readers can't see it.

  1. DZone
  2. Coding
  3. Languages
  4. Vertical vs. Horizontal Decomposition of Responsibility

Vertical vs. Horizontal Decomposition of Responsibility

Objects with too many responsibilities are often prime candidates for refactoring. We take a look at the Decomposition of Responsibility pattern for performing these refactorings. Read on to find out more about the pattern and how to use (and not use) it.

By 
Yegor Bugayenko
·
Sep. 02, 16 · Tutorial
Post on X (opens in a new tab) Share on LinkedIn (opens in a new tab)
11.9K Views

Join the DZone community Save articles, join the discussion, and download Refcards and Trend Reports with a free account.

Join for free Already a member? Log in

objects responsible for too many things are a problem. because their complexity is high, they are difficult to maintain and extend. decomposition of responsibility is what we do in order to break these overly complex objects into smaller ones. i see two types of this refactoring operation: vertical and horizontal. and i believe the former is better than the latter.

once upon a time in america (1984) by sergio leone
once upon a time in america (1984) by sergio leone

let's say this is our code (in ruby):

class log
  def initialize(path)
    @file = io.new(path, 'a')
  end
  def put(text)
    line = time.now.strftime("%d/%m/%y %h:%m ") + text
    @file.puts line
  end
end

obviously, objects of this class are doing too much. they save log lines to the file and also forward them — an obvious violation of a famous single responsibility principle . an object of this class would be responsible for too many things. we have to extract some functionality out of it and put that into another object(s). we have to decompose its responsibility. no matter where we put it, this is how the log class will look after the extraction:

class log
  def initialize(path)
    @file = io.new(path, 'a')
  end
  def put(text)
    @file.puts line
  end
end

now it only saves lines to the file, which is perfect. the class is cohesive and small. let's make an instance of it:

log = log.new('/tmp/log.txt')

next, where do we put the lines with formatting functionality that were just extracted? there are two approaches to decompose responsibility: horizontal and vertical. this one is horizontal :

class line
  def initialize(text)
    @line = text
  end
  def to_s
    time.now.strftime("%d/%m/%y %h:%m ") + text
  end
end

in order to use log and line together, we have to do this:

log.put(line.new("hello, world"))

see why it's horizontal? because this script sees them both. they both are on the same level of visibility. we will always have to communicate with both of them when we want to log a line. both objects of log and line are in front of us. we have to deal with two classes in order to log a line:

image title

to the contrary, this decomposition of responsibility is vertical :

class timedlog
  def initialize(log)
    @origin = log
  end
  def put(text)
    @origin.put(time.now.strftime("%d/%m/%y %h:%m ") + text)
  end
end

class timedlog is a decorator, and this is how we use them together:

log = timelog.new(log)

now, we just put a line in the log:

log.put("hello, world")

the responsibility is decomposed vertically. we still have one entry point into the log object, but the object "consists" of two objects, one wrapped into another:

image title

in general, i think horizontal decomposition of responsibility is a bad idea, while vertical is a much better one. that's because a vertically decomposed object decreases complexity, while a horizontally decomposed one actually makes things more complex because its clients have to deal with more dependencies and more points of contact.

Decomposition (computer science) Object (computer science)

Published at DZone with permission of Yegor Bugayenko. See the original article here.

Opinions expressed by DZone contributors are their own.

Related

  • Testing Business Programs Without Constructing Domain Objects
  • Momento Migrates Object Cache as a Service to Ampere® Altra®
  • Why I Ditched Redis for Cloudflare Durable Objects in My Rate Limiter
  • Real-Object Detection at the Edge: AWS IoT Greengrass and YOLOv5

Partner Resources

×

Comments

Loading comments

The comments didn't load

Please try again in a moment.

Likes

Loading

The next likes didn't load. Please try again.

The likes didn't load

Please try again in a moment.

See who liked this

Log in or join DZone for free to see who liked this article.

Log in Join for free
  • RSS
  • X
  • Facebook

ABOUT US

  • About DZone
  • Support and feedback
  • Community research

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 215
  • Nashville, TN 37211
  • [email protected]

Let's be friends:

  • RSS
  • X
  • Facebook