Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Single Responsibility Principle

blog.8thlight.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: The Single Responsibility Principle

#11

Post by mattgreenrocks »

spion wrote: post #10
mattgreenrocks wrote: post #7

Earlier quoted context omitted.

A lot of people seem to chafe at these principles because they convey truths about a intangible reality they may not even be able to perceive. They only see more work for little payoff. They don't have the body of knowledge and experience (nor the intuition) to know when when to abstract more. We're also in a post-enterprise era, where any sort of deliberate design is often mocked by way of strawman AbstractComposerF…

They don't chafe because they convey truths about a intangible reality they may not even be able to perceive. They chafe because nothing is actually being conveyed. Its a bunch of words removed from any actual meaning - from the concrete problems that caused the person to arrive to the truth being "conveyed". They're like the conclusion part of an essay with all the rest left out. They tell nothing to people that don…

Yeah, the actual context is rarely ever delivered. And that matters a lot. Sometimes I wonder how well it would be received, though. Not to mention many books on software engineering tend to be written in a more abstract style than most blog posts. I'm not sure of the precedent for this is there; it would certainly help.

The GoF book does a decent job balancing context with theory, IMO.

Re: The Single Responsibility Principle

#12

Post by zwieback »

spion wrote: post #10
mattgreenrocks wrote: post #7

Earlier quoted context omitted.

A lot of people seem to chafe at these principles because they convey truths about a intangible reality they may not even be able to perceive. They only see more work for little payoff. They don't have the body of knowledge and experience (nor the intuition) to know when when to abstract more. We're also in a post-enterprise era, where any sort of deliberate design is often mocked by way of strawman AbstractComposerF…

They don't chafe because they convey truths about a intangible reality they may not even be able to perceive. They chafe because nothing is actually being conveyed. Its a bunch of words removed from any actual meaning - from the concrete problems that caused the person to arrive to the truth being "conveyed". They're like the conclusion part of an essay with all the rest left out. They tell nothing to people that don…

I remember first hearing about Uncle Bob's principles and the GoF patterns in a lunch meeting a company in town (Rogue Wave Software) held for anyone interested. When I heard those guys talking about object oriented design and system architecture in general I could just listen in awe. This was before the AbstractFactoryFactory antipattern (Java was just starting) and I thought if I could just gain the level of understanding the RW guys had I'd be golden.

15 years later I've written enough software to understand the principles but no amount of study got me there, just lots of practice and fixing my own mistakes.

Re: The Single Responsibility Principle

#13

Post by spion »

mattgreenrocks wrote: post #11
spion wrote: post #10

Earlier quoted context omitted.

They don't chafe because they convey truths about a intangible reality they may not even be able to perceive. They chafe because nothing is actually being conveyed. Its a bunch of words removed from any actual meaning - from the concrete problems that caused the person to arrive to the truth being "conveyed". They're like the conclusion part of an essay with all the rest left out. They tell nothing to people that don…

Yeah, the actual context is rarely ever delivered. And that matters a lot. Sometimes I wonder how well it would be received, though. Not to mention many books on software engineering tend to be written in a more abstract style than most blog posts. I'm not sure of the precedent for this is there; it would certainly help. The GoF book does a decent job balancing context with theory, IMO.

I liked the GOF book. But what I'd really love to read about are the descriptions and (architectural) histories of complete, real software systems, especially about the design decisions and the reasons behind those decisions.

I think such information will be received with great interest - it would be like receiving a shot of condensed experience in readable form. Not exactly the same with actual experience of course, but way better than just abstract principles that leave me unconvinced.

Re: The Single Responsibility Principle

#14

Post by YZF »

mattgreenrocks wrote: post #7
stiff wrote: post #5

While he might understand what he is talking about, based on a corpus of experience, people who learn about this "principle" as they learn to program do not typically understand it and tend to draw only the wrong conclusions from it. What makes for coupling, and how to avoid it, you simply learn with a lot of practice, and there are not many clearcut guidelines you can formulate, it all varies depending on the proble…

A lot of people seem to chafe at these principles because they convey truths about a intangible reality they may not even be able to perceive. They only see more work for little payoff. They don't have the body of knowledge and experience (nor the intuition) to know when when to abstract more. We're also in a post-enterprise era, where any sort of deliberate design is often mocked by way of strawman AbstractComposerF…

The principles apply to any language. I wrote a lot of C++ and today I write a lot of Python and the principles of building solid maintainable systems hold the same for both.

I think there are other factor at work here:

- The size of the project. I think most code written today is in the context of tiny systems, e.g. a bit of Javascript that goes with a single web page or some trivial backend code within an existing framework.

- The life cycle of the project. Most software projects have a short life time. This is for various reasons, some of them technical, some of them business related.

- You pay for bad design much farther down the road so it's harder for people to see the causation.

- The investment of individual engineers. If you move from one startup to the other every year you may not care that much about principles that will affect maintainability. You should but a lot of people don't. By the time coupling matters you'll already be hacking somewhere else. Being disconnected from the results of your work creates a difficulty in understanding design principles.

- Not Invented Here. People generally aren't open to receiving lessons from other people's experience. Learning often has to happen through individual experience.

I don't think there are many successful, large, long term, software projects where everything is a jumbled mess with no design intent and everything coupled with everything.

Re: The Single Responsibility Principle

#15

Post by [deleted] »

YZF wrote: post #14
mattgreenrocks wrote: post #7

Earlier quoted context omitted.

A lot of people seem to chafe at these principles because they convey truths about a intangible reality they may not even be able to perceive. They only see more work for little payoff. They don't have the body of knowledge and experience (nor the intuition) to know when when to abstract more. We're also in a post-enterprise era, where any sort of deliberate design is often mocked by way of strawman AbstractComposerF…

The principles apply to any language. I wrote a lot of C++ and today I write a lot of Python and the principles of building solid maintainable systems hold the same for both. I think there are other factor at work here: - The size of the project. I think most code written today is in the context of tiny systems, e.g. a bit of Javascript that goes with a single web page or some trivial backend code within an existing…

[deleted]

Re: The Single Responsibility Principle

#16

Post by icebraining »

spion wrote: post #13
mattgreenrocks wrote: post #11

Earlier quoted context omitted.

Yeah, the actual context is rarely ever delivered. And that matters a lot. Sometimes I wonder how well it would be received, though. Not to mention many books on software engineering tend to be written in a more abstract style than most blog posts. I'm not sure of the precedent for this is there; it would certainly help. The GoF book does a decent job balancing context with theory, IMO.

I liked the GOF book. But what I'd really love to read about are the descriptions and (architectural) histories of complete, real software systems, especially about the design decisions and the reasons behind those decisions. I think such information will be received with great interest - it would be like receiving a shot of condensed experience in readable form. Not exactly the same with actual experience of course,…

Have you seen the Architecture of Open Source Applications[1]? I think it fits very well with what you just described. It explains not only the what, but also the why, with real examples of successful applications.

[1] http://aosabook.org/en/index.html

Re: The Single Responsibility Principle

#17

Post by spion »

icebraining wrote: post #16
spion wrote: post #13

Earlier quoted context omitted.

I liked the GOF book. But what I'd really love to read about are the descriptions and (architectural) histories of complete, real software systems, especially about the design decisions and the reasons behind those decisions. I think such information will be received with great interest - it would be like receiving a shot of condensed experience in readable form. Not exactly the same with actual experience of course,…

Have you seen the Architecture of Open Source Applications[1]? I think it fits very well with what you just described. It explains not only the what, but also the why, with real examples of successful applications. [1] http://aosabook.org/en/index.html

I remember seeing it and promptly forgetting about it. Thats precisely what I needed. Thank you.

Re: The Single Responsibility Principle

#18

Post by Arnor »

My team and I have been working on a problem over the last week or so that screams modularity problems. Each time we think we have it solved, someone says "Wait, there's this report only 2 of us have ever heard about that doesn't work because X, Y, Z." The discussion has lasted a couple weeks and is starting to push deployment times back.

Essentially, we have a distributed set of `devices` which interact with `customers`. Each customer has a `session` with the device. During the session, the `customer` may make various types of `payments` (coin or credit card) for various types of `fees`. Additionally, the customer may receive one or more `tickets`. The data model is getting pretty big with:

* Devices

* Sessions

* Line Items

* Allocations

* Payments

* Adjustments

* Violations

* Fees

For accounting purposes, we need to be able to map our payments to the fees and violations they are paying for. Customers might make a single payment to cover multiple violations and those violations may be across multiple sessions.

The number of times I've heard "this new solution fixes X but breaks π" is frustrating, but I don't see how this could be separated out. Perhaps others have insights that would simplify all of this, but it seems to me that the essential fact of our system is that the payment/line item/allocation system is responsible for many tasks/reports. I read articles like this and pine for:

A) A project where true modularity is achievable.

B) The skills to make my current project truly modular.

Re: The Single Responsibility Principle

#19

Post by AnimalMuppet »

spion wrote: post #9
stiff wrote: post #5

While he might understand what he is talking about, based on a corpus of experience, people who learn about this "principle" as they learn to program do not typically understand it and tend to draw only the wrong conclusions from it. What makes for coupling, and how to avoid it, you simply learn with a lot of practice, and there are not many clearcut guidelines you can formulate, it all varies depending on the proble…

Yup. Which is why I believe that if you really want to teach someone software design principles, you have to be prepared show them an actual, real software system; the real problem you encountered; the reason why you picked a particular solution; and the results of that choice (both pros and cons). All the details. Given that data, its easy for a developer to extrapolate (more general) principles that may apply for t…

I think it's like this: Six months to two years after starting a moderately-sized code base, you start to see why these things are important. You see that they're actually saying something fairly (though not totally) concrete. The more experience you have bumping into the issues, the more concrete the advice becomes.

But I can't give that to you in something that you can read in an hour, or even a day. I might be able to give it to you in something you could read in a month (of 8-hour days reading). It's really hard to show in a one-page example.

Re: The Single Responsibility Principle

#20

Post by spion »

AnimalMuppet wrote: post #19
spion wrote: post #9

Earlier quoted context omitted.

Yup. Which is why I believe that if you really want to teach someone software design principles, you have to be prepared show them an actual, real software system; the real problem you encountered; the reason why you picked a particular solution; and the results of that choice (both pros and cons). All the details. Given that data, its easy for a developer to extrapolate (more general) principles that may apply for t…

I think it's like this: Six months to two years after starting a moderately-sized code base, you start to see why these things are important. You see that they're actually saying something fairly (though not totally) concrete. The more experience you have bumping into the issues, the more concrete the advice becomes. But I can't give that to you in something that you can read in an hour, or even a day. I might be abl…

An essay of 10-100 pages with references to the corresponding code is completely acceptable. The problem is, nobody actually does this while they're learning about it (or rather, they have other more important things to do, like the actual refactor) so there are little or no records of it.

GoF almost managed to do it, except they removed the real system context. One can almost learn something from that book :)

Post reply on HN