On the SOLID Principles

[Terence McGhee]

After reviewing what's written here: goo.gl/HDUMuJ

I'm really surprised at just how many devs don't understand what the SOLID principles really are. Too much of what I read on the Internets (blog posts, stack exchange) is just plain wrong. 

Especially the SRP. So many devs think they know what this means and when I read their explanations, it's clear that they have no idea what they're talking about.

I think that all devs need to understand and apply these principles and there must be something we can do (as a community) to get the real teachings of the SOLID principles assimilated to the group. 

[Per Lundholm]

Thanks for the pointer.

What are the most common mistakes people do when explaining SRP, you think?

Cheers
Per

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discu...@googlegroups.com.
To post to this group, send email to clean-code...@googlegroups.com.
Visit this group at http://groups.google.com/group/clean-code-discussion.

[Frédéric Bouquet]

Hi,

I'm not sure to understand what you mean about the article. Do you
mean it's wrong ?
I'm a bit surprises about the explanation the author gives for Open
Close Principle. I don't think inheritence is a good solution for many
cases I see it used in my day to day life. I see many
programs/projects with inheritence used to facotize code, where I
would prefer delegating things to an other service.
I would use sub-classes when there's a real meaning, not for only
factorize code. What do you thing about it ?

Cheers


2013/11/23 Terence McGhee <terence...@gmail.com>:

> --
> The only way to go fast is to go well.
> ---
> You received this message because you are subscribed to the Google Groups
> "Clean Code Discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clean-code-discu...@googlegroups.com.
> To post to this group, send email to clean-code...@googlegroups.com.
> Visit this group at http://groups.google.com/group/clean-code-discussion.

--
Frédéric Bouquet
Twitter/Github : bouquetf
http://www.espacedefouille.org/

[Terence McGhee]

@Per Lundholm

The main thing that I see devs continually get wrong with SRP is that they think it means literally "a class has a single responsibility". This is too vague and not useful. It's very similar to Uncle Bob's explanation of what it means for a function to do "one thing". That term leaves itself open to too much relativity.

The SRP really means "a class does not have more than one reason to change". This is a subtle, but very important difference.

And, in order to determine SRP violations (or compliance) we need to identify actors / roles and make sure that our classes / functions are in allegiance to one and only one actor.

On Monday, November 25, 2013 1:37:24 AM UTC-6, Per Lundholm wrote:

Thanks for the pointer.

What are the most common mistakes people do when explaining SRP, you think?

Cheers
Per

Den 23 nov 2013 18:06 skrev "Terence McGhee" <terence...@gmail.com>:

After reviewing what's written here: goo.gl/HDUMuJ

I'm really surprised at just how many devs don't understand what the SOLID principles really are. Too much of what I read on the Internets (blog posts, stack exchange) is just plain wrong. 

Especially the SRP. So many devs think they know what this means and when I read their explanations, it's clear that they have no idea what they're talking about.

I think that all devs need to understand and apply these principles and there must be something we can do (as a community) to get the real teachings of the SOLID principles assimilated to the group. 

--
The only way to go fast is to go well.
---
You received this message because you are subscribed to the Google Groups "Clean Code Discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to clean-code-discussion+unsub...@googlegroups.com.

[Terence McGhee]

@Frédéric Bouquet

I don't know if I'd go so far as to say the article is wrong in the strictest sense, but I would definitely say that it's misleading and doesn't come from a place of full understanding of the material.

That being said, I didn't really have a problem with their explanation of the OCP. 

I agree with you that, in many cases, there are better alternatives to sub classes. And in the instances where there are sub classes, they should be done correctly. Hence, the reason the SOLID principles exist in the first place: to help govern the decisions we make in our code.

> email to clean-code-discussion+unsub...@googlegroups.com.

[Frédéric Bouquet]

Hi Tarence,

> The SRP really means "a class does not have more than one reason to change".
> This is a subtle, but very important difference.

Thank for the clarification, I understand better. It's true, the
difference may seems small, but important...

[Frédéric Bouquet]

> I don't know if I'd go so far as to say the article is wrong in the
> strictest sense, but I would definitely say that it's misleading and doesn't
> come from a place of full understanding of the material.

I agree, wrong is a bit strong, I was trying to find out the right
word but... i didn't success. You know, I'm french and everybody knows
how good french are in english ;)

> That being said, I didn't really have a problem with their explanation of
> the OCP.
>
> I agree with you that, in many cases, there are better alternatives to sub
> classes. And in the instances where there are sub classes, they should be
> done correctly. Hence, the reason the SOLID principles exist in the first
> place: to help govern the decisions we make in our code.

In fact, I feel it hard to test parent classes while practicing TDD,
in the "behavior based" way. It's one of the main reason I think I'm
now trying to come back to state based tests. (Not sure about the
right terms)

[Илья Фофанов]

Terence, could you give a good example that helps to understand the difference between "class should have single responsibility" and "there is should be only one reason to change a class"? First of all, it would be very helpful to see the way of how to determine the actors (users of a class as I understand).

[Sebastian Gozin]

class ReadAndFormatBook {
  def findBookById(id) {
    def book = Sql.query("select id, author, title, blurb from book where id = $id")
    return """
      $title
      written by $author
      ------------------------
      $blurb
    """
  }
}

I now have at least 2 actors who can demand changes.
- Infrastructure may want to move the data from SQL to a different persistence strategy or table structure.
- Presentation may want to change how the book is rendered

[Uncle Bob]

The SRP sound-bite is: "Gather together those things that change for the same reasons; separate those things that change for different reasons."

[Илья Фофанов]

вторник, 26 ноября 2013 г., 23:06:07 UTC+4 пользователь Sebastian Gozin написал:

I now have at least 2 actors who can demand changes.
- Infrastructure may want to move the data from SQL to a different persistence strategy or table structure.
- Presentation may want to change how the book is rendered

 Hmm... yes I agree. But I notice that there is a significant inductive bounce (I mean that nobody can understand the string of logic you has been thinking with intention to determine the actors).
So the problem of actors determination stays. I dont want to say that I want you to give me a few steps that will always provide me the answer to the question of who are the actors. Maybe there are any questions that propgrammer may ask himself with intention to determine the actors? Besides, maybe you can make a list of the most popular reasons to change a class?
I want to notice that it's very difficult for a beginner to grasp the statements such as "Gather together those things that change for the same reasons; separate those things that change for different reasons." Eventually, it takes a long time to understand all these concepts.

[Sebastian Gozin]

I tend to start with the following:
- transport (e.g: web)
- business (the application itself)
- io (e.g: files, sql, mongo, redis, e-mail, etc...)

Other than that I'll wait till a request for change points one out to me and take the appropriate steps to separate them.

[Andreas Schaefer]

in which ways do SRP and SOC (separation of concerns) relate, what differnciates them?

"I tend to start with the following:
- transport (e.g: web)
- business (the application itself)
- io (e.g: files, sql, mongo, redis, e-mail, etc...)"

I'd say that this is "just SOC" as it is of a more general, more technical nature that potentially applies to all use cases if a change is required in one of them, e.g. the database guys request to change the persistance mechanism from one system to another.

opposed to that, all of the layers (transport, persistance, business rules) would'd be affected, if for an actor a specific use case needed to regard a new field in an entity. or just the business rules would be affected if only a validation rule change is required.

maybe we could say that SRP not only applies SOC, but it also groups things together .. regarding contexts, actors, use cases?

[Sebastian Gozin]

Lately I've been thinking that this SOC is simply an application of SRP yes.
I'm not sure which came first and frankly I don't think it matters. I do feel SRP explains the 'why' better.

I don't feel like it matters if the actor wants the change for technical reasons. If you review the cleancoders episode on SRP you will notice the example of database guys "infrastructure" is used together with visual designers "presentation" and business rules "policy".
I simply added web protocols "transport" as an actor.

Should there be more subtle differences I'd love to know as well.