|
Hi fellow programmersNon native English?speaker here, so thanks for points about answer 3.I get the below question quite often in my clean code refactoring OR agile developer trainings after introducing principles: "What is the difference between SOC (Separation of Concerns) and SRP (Single Responsibility Principle)?"My answer has grown in the direction of 3 things:
- Timing
- when do you think about this principle in the back of your mind?
- SOC more as a process during design and problem decomposition (slicing)
- SRP more after the fact, when the code/system exists (What is this package responsible for)
- Flight level of the principle
- SRP is about things and their behavior?
- Things being functions, classes, packages, namespaces, modules,?
- SOC could be applied
- within a function (Is the concern of "x" clearly visible and separated)
OR
- on an architecture level (Where is the concern of "y" handled?)
- The terms "responsibility" VS "concern"?
- "responsibility" reminds me of OO (see flight levels)
- "concern" could be anything in my language world: activity, task, goal, responsibility, request, pure...
- It's more about "where is this concern visible or delegatable to"
What would you answer to "SRP vs SOC"? Thanks!!! Peter Gfader
|
I don't think I've ever pondered the difference before seeing your question. Personally, I would view SRP as business behaviour and SOC as technical implementation.
Single Responsibility would mean that if the business rules of one feature were to change, one module of the code should change, not several.
Separation of Concerns might mean things like keeping SQL/data-access out of HTML templates.
?
|
SRP is an instance of SOC in software design.
SOC is a broad principle.
SRP is to SOC As? BEAGLE is to DOG
On Wed, Oct 5, 2022 at 11:48, markkirschstein@... <markkirschstein@...> wrote: I don't think I've ever pondered the difference before seeing your question. Personally, I would view SRP as business behaviour and SOC as technical implementation.
Single Responsibility would mean that if the business rules of one feature were to change, one module of the code should change, not several.
Separation of Concerns might mean things like keeping SQL/data-access out of HTML templates.
?
|
I view SoC as meta-principle (i.e. a more generic, principle-of-principles) whereas other princes, like SOLID, or DRY, even LoD, or SLAP. are specific principles.
Specific instances (principles) that fall under the larger umbrella of SoC include: - Separate Interface from Implementation? - Separate Data from Representation - Command-Query Separation (CQRS) - Interface Segregation (ISP) - Separate Construction from Use - Separate Business logic/layer/domain from <<other>> (e.g., solution | presentation | ...)
As for the difference SRP and SoC (aside from the latter being more of a meta-principle)...
SRP is really an O-O take on the more fundamental Principle of Cohesion: - In fact, it really ought to have used the word 'Reason' or (better still) *Purpose* instead of 'purpose' -- largely because of how CRC technique/method used the term 'responsibility',?
SoC is about DeCoupling -- what things (concerns) to *break* *apart* so they can grow/evolve independently from one another!
In contrast, [high] Cohesion is about what to *keep* *together* because they are InterDependent/Inter-Related!?
One might even describe this difference as 'Entanglement' vs 'DisEntanglement' [In honor of the recently awarded 2022 Nobel Physics prize] ?
SRP is an instance of SOC in software design.
SOC is a broad principle.
SRP is to SOC As? BEAGLE is to DOG I don't think I've ever pondered the difference before seeing your question. Personally, I would view SRP as business behaviour and SOC as technical implementation.
Single Responsibility would mean that if the business rules of one feature were to change, one module of the code should change, not several.
Separation of Concerns might mean things like keeping SQL/data-access out of HTML templates.
?
|
toggle quoted message
Show quoted text
I view SoC as meta-principle (i.e. a more generic, principle-of-principles) whereas other princes, like SOLID, or DRY, even LoD, or SLAP. are specific principles.
Specific instances (principles) that fall under the larger umbrella of SoC include: - Separate Interface from Implementation? - Separate Data from Representation - Command-Query Separation (CQRS) - Interface Segregation (ISP) - Separate Construction from Use - Separate Business logic/layer/domain from <<other>> (e.g., solution | presentation | ...)
As for the difference SRP and SoC (aside from the latter being more of a meta-principle)...
SRP is really an O-O take on the more fundamental Principle of Cohesion: - In fact, it really ought to have used the word 'Reason' or (better still) *Purpose* instead of 'purpose' -- largely because of how CRC technique/method used the term 'responsibility',?
SoC is about DeCoupling -- what things (concerns) to *break* *apart* so they can grow/evolve independently from one another!
In contrast, [high] Cohesion is about what to *keep* *together* because they are InterDependent/Inter-Related!?
One might even describe this difference as 'Entanglement' vs 'DisEntanglement' [In honor of the recently awarded 2022 Nobel Physics prize] ?
SRP is an instance of SOC in software design.
SOC is a broad principle.
SRP is to SOC As? BEAGLE is to DOG I don't think I've ever pondered the difference before seeing your question. Personally, I would view SRP as business behaviour and SOC as technical implementation.
Single Responsibility would mean that if the business rules of one feature were to change, one module of the code should change, not several.
Separation of Concerns might mean things like keeping SQL/data-access out of HTML templates.
?
|
Good explanation, Brad!
Thanks! Now I just need to work on my typing when on my phone (or not reply from my phone).
My *CORRECTIONS* are applied *BELOW*! (in purple)??[Also see?]? ? I view SoC as meta-principle (i.e. a more generic, principle-of-principles) whereas other princ iples, like , or , even , or . are specific principles
Specific instances (principles) that fall under the larger umbrella of SoC include: - Separate Interface from Implementation? - Separate Data from Representation - Command-Query Separation () - Interface Segregation (ISP) - Separate Construction from Use - Separate Business logic/layer/domain from <<other>> (e.g., solution | presentation | ...)
As for the difference SRP and SoC (aside from the latter being more of a meta-principle)...
SRP is really an O-O take on the more fundamental Principle of Cohesion: - In fact, it really ought to have used the word 'Reason' or (better still) *Purpose* (instead of 'responsibility') -- largely because of how CRC technique/method used the term 'responsibility',?
SoC is about DeCoupling -- what things (concerns) to *break* *apart* so they can grow/evolve independently from one another!
In contrast, [high] Cohesion is about what to *keep* *together* because they are InterDependent/Inter-Related!?
One might even describe this difference as 'Entanglement' vs 'DisEntanglement' [In honor of the recently awarded 2022 Nobel Physics prize] ??
SRP is an instance of SOC in software design.
SOC is a broad principle.
SRP is to SOC As? BEAGLE is to DOG I don't think I've ever pondered the difference before seeing your question. Personally, I would view SRP as business behaviour and SOC as technical implementation.
Single Responsibility would mean that if the business rules of one feature were to change, one module of the code should change, not several.
Separation of Concerns might mean things like keeping SQL/data-access out of HTML templates.
?
|
Coupling and cohesion....
Cohesion: things that belong together and change together are kept together?
Coupling: things that belong and change independently are separate.?
Add signal to noise ratio, you really have something.
On Wed, Oct 5, 2022 at 15:00, Dave Nicolette <davenicolette@...> wrote: Good explanation, Brad! I view SoC as meta-principle (i.e. a more generic, principle-of-principles) whereas other princes, like SOLID, or DRY, even LoD, or SLAP. are specific principles.
Specific instances (principles) that fall under the larger umbrella of SoC include: - Separate Interface from Implementation? - Separate Data from Representation - Command-Query Separation (CQRS) - Interface Segregation (ISP) - Separate Construction from Use - Separate Business logic/layer/domain from <<other>> (e.g., solution | presentation | ...)
As for the difference SRP and SoC (aside from the latter being more of a meta-principle)...
SRP is really an O-O take on the more fundamental Principle of Cohesion: - In fact, it really ought to have used the word 'Reason' or (better still) *Purpose* instead of 'purpose' -- largely because of how CRC technique/method used the term 'responsibility',?
SoC is about DeCoupling -- what things (concerns) to *break* *apart* so they can grow/evolve independently from one another!
In contrast, [high] Cohesion is about what to *keep* *together* because they are InterDependent/Inter-Related!?
One might even describe this difference as 'Entanglement' vs 'DisEntanglement' [In honor of the recently awarded 2022 Nobel Physics prize] ?
SRP is an instance of SOC in software design.
SOC is a broad principle.
SRP is to SOC As? BEAGLE is to DOG I don't think I've ever pondered the difference before seeing your question. Personally, I would view SRP as business behaviour and SOC as technical implementation.
Single Responsibility would mean that if the business rules of one feature were to change, one module of the code should change, not several.
Separation of Concerns might mean things like keeping SQL/data-access out of HTML templates.
?
|
Thanks Tim. Tho it probably should say 'De-Coupling' in the definition you gave below?
More specifically, the phrase usually goes? - HIGH Cohesion and ... - LOW (or Loose) Coupling (The oversimplified message is 'Cohesion GOOD! Coupling BAD!!')
There is a principle to this effect with 'Cohesion' in its name, but not with 'Coupling' (unless it's preceded by one of: de-, no, or low/loose}
HOWEVER, back in '95, Meilir Page Jones attempted to unify "high cohesion + low/loose" coupling into a single concept of "Connascence" ?
Like SRP, the Cohesion principle is usually at the module/class level (sometimes package, although 'package cohesion' is a separate but related principle from SRP)
SoC however (like de-coupling & connascence) can apply at just about any level/layer both above AND below class/module.
Some will refer to a 'Coherence' Principle separately from 'Cohesion' (both for software-design, as well as 'teams') ?The difference between the two is usually one of the following:
1. cohesion is (sometimes) more about being physically connected, whereas 'coherence' is more about logical connection ...OR... 2. cohesion is more concerned with things that are part of the same elemental unit/granule, whereas coherence is more concerned with connectedness ACROSS one or more units/granules
In the latter case, its similar to the difference between cohesion & coherence in writing: - cohesion *within* a sentence - coherence *between* sentences in a single paragraph (and/or between succesive paragraphs)
Coupling and cohesion....
Cohesion: things that belong together and change together are kept together?
Coupling: things that belong and change independently are separate.?
Add signal to noise ratio, you really have something. On Wed, Oct 5, 2022 at 15:00, Dave Nicolette Good explanation, Brad! I view SoC as meta-principle (i.e. a more generic, principle-of-principles) whereas other princes, like SOLID, or DRY, even LoD, or SLAP. are specific principles.
Specific instances (principles) that fall under the larger umbrella of SoC include: - Separate Interface from Implementation? - Separate Data from Representation - Command-Query Separation (CQRS) - Interface Segregation (ISP) - Separate Construction from Use - Separate Business logic/layer/domain from <<other>> (e.g., solution | presentation | ...)
As for the difference SRP and SoC (aside from the latter being more of a meta-principle)...
SRP is really an O-O take on the more fundamental Principle of Cohesion: - In fact, it really ought to have used the word 'Reason' or (better still) *Purpose* instead of 'purpose' -- largely because of how CRC technique/method used the term 'responsibility',?
SoC is about DeCoupling -- what things (concerns) to *break* *apart* so they can grow/evolve independently from one another!
In contrast, [high] Cohesion is about what to *keep* *together* because they are InterDependent/Inter-Related!?
One might even describe this difference as 'Entanglement' vs 'DisEntanglement' [In honor of the recently awarded 2022 Nobel Physics prize] ?
SRP is an instance of SOC in software design.
SOC is a broad principle.
SRP is to SOC As? BEAGLE is to DOG I don't think I've ever pondered the difference before seeing your question. Personally, I would view SRP as business behaviour and SOC as technical implementation.
Single Responsibility would mean that if the business rules of one feature were to change, one module of the code should change, not several.
Separation of Concerns might mean things like keeping SQL/data-access out of HTML templates.
?
|
Try a brutal but simple approach.
Write down the class invariant CI? in terms of and class variables and instance variables v1, v2, ..., vn
ie.
The entire point of a class is to ensure CI( v1, v2, ..., vn) is
_always_ true at the end of the constructor and the start of the
destructor and the start and end of every public method.
Now look at it...? Can you rewrite it in the form CIa( va1, va2, ...) && CIb( vb1, vb2, ...)?
Where you have partitioned v1, v2, ..., vn into disjoint sets va1, ... and? vb1...
If
so.... you have (at least) two smaller classes A and B with variables
va1, ... and vb1, ... respectively and class invariants CIa and CIb
Repeat until you cannot make it simpler.
This plays nice with
I suspect there are more games you can play like this to make things simpler and more reliable.
On Tue, Oct 4, 2022 at 8:30 PM Peter Gfader < peter@...> wrote: Hi fellow programmers
Non native English?speaker here, so thanks for points about answer 3.
I get the below question quite often in my clean code refactoring OR agile developer trainings after introducing principles:
"What is the difference between SOC (Separation of Concerns) and SRP (Single Responsibility Principle)?"
My answer has grown in the direction of 3 things:
- Timing
- when do you think about this principle in the back of your mind?
- SOC more as a process during design and problem decomposition (slicing)
- SRP more after the fact, when the code/system exists (What is this package responsible for)
- Flight level of the principle
- SRP is about things and their behavior?
- Things being functions, classes, packages, namespaces, modules,?
- SOC could be applied
- within a function (Is the concern of "x" clearly visible and separated)
OR
- on an architecture level (Where is the concern of "y" handled?)
- The terms "responsibility" VS "concern"?
- "responsibility" reminds me of OO (see flight levels)
- "concern" could be anything in my language world: activity, task, goal, responsibility, request, pure...
- It's more about "where is this concern visible or delegatable to"
What would you answer to "SRP vs SOC"?
Thanks!!!
Peter Gfader
This communication is confidential. We only send and receive email on the basis of the terms set out at
|
Thanks for the article reference!
I think the use of "Class Invariants" relates most closely to what Bertrand Meyer called "Design by Contract". Each class not only has an "invariant", but each method also the option of specifying prerequisite conditions ("Require") and postrequisite conditions ("Ensure").
Inheritance played a role in this as well, because any subclass implementing its own version (specialization") of a method in its base class had to obey the rule:?"Require no more! Ensure no less!"
Meyer was also the creator of the OCP (Open-Closed Principle) as well as CQ[R]S (Commands-Query Separation/Segregation).
{ ?|??}? "And miles to go before I sleep" --Robert Frost
On Sun, Oct 9, 2022 at 4:55 PM John Carter via <john.carter= [email protected]> wrote:
Try a brutal but simple approach.
Write down the class invariant CI? in terms of and class variables and instance variables v1, v2, ..., vn
ie.
The entire point of a class is to ensure CI( v1, v2, ..., vn) is
_always_ true at the end of the constructor and the start of the
destructor and the start and end of every public method.
Now look at it...? Can you rewrite it in the form CIa( va1, va2, ...) && CIb( vb1, vb2, ...)?
Where you have partitioned v1, v2, ..., vn into disjoint sets va1, ... and? vb1...
If
so.... you have (at least) two smaller classes A and B with variables
va1, ... and vb1, ... respectively and class invariants CIa and CIb
Repeat until you cannot make it simpler.
This plays nice with
I suspect there are more games you can play like this to make things simpler and more reliable.
On Tue, Oct 4, 2022 at 8:30 PM Peter Gfader < peter@...> wrote: Hi fellow programmers
Non native English?speaker here, so thanks for points about answer 3.
I get the below question quite often in my clean code refactoring OR agile developer trainings after introducing principles:
"What is the difference between SOC (Separation of Concerns) and SRP (Single Responsibility Principle)?"
My answer has grown in the direction of 3 things:
- Timing
- when do you think about this principle in the back of your mind?
- SOC more as a process during design and problem decomposition (slicing)
- SRP more after the fact, when the code/system exists (What is this package responsible for)
- Flight level of the principle
- SRP is about things and their behavior?
- Things being functions, classes, packages, namespaces, modules,?
- SOC could be applied
- within a function (Is the concern of "x" clearly visible and separated)
OR
- on an architecture level (Where is the concern of "y" handled?)
- The terms "responsibility" VS "concern"?
- "responsibility" reminds me of OO (see flight levels)
- "concern" could be anything in my language world: activity, task, goal, responsibility, request, pure...
- It's more about "where is this concern visible or delegatable to"
What would you answer to "SRP vs SOC"?
Thanks!!!
Peter Gfader
This communication is confidential. We only send and receive email on the basis of the terms set out at
|
Thanks everyone on your thoughts...
I really like the thoughts around Coupling and Cohesion.
Peter
Thanks for the article reference!
I think the use of "Class Invariants" relates most closely to what Bertrand Meyer called "Design by Contract". Each class not only has an "invariant", but each method also the option of specifying prerequisite conditions ("Require") and postrequisite conditions ("Ensure").
Inheritance played a role in this as well, because any subclass implementing its own version (specialization") of a method in its base class had to obey the rule:?"Require no more! Ensure no less!"
Meyer was also the creator of the OCP (Open-Closed Principle) as well as CQ[R]S (Commands-Query Separation/Segregation).
{ ?|??}? "And miles to go before I sleep" --Robert Frost
On Sun, Oct 9, 2022 at 4:55 PM John Carter via <john.carter= [email protected]> wrote: Try a brutal but simple approach.
Write down the class invariant CI? in terms of and class variables and instance variables v1, v2, ..., vn
ie.
The entire point of a class is to ensure CI( v1, v2, ..., vn) is
_always_ true at the end of the constructor and the start of the
destructor and the start and end of every public method.
Now look at it...? Can you rewrite it in the form CIa( va1, va2, ...) && CIb( vb1, vb2, ...)?
Where you have partitioned v1, v2, ..., vn into disjoint sets va1, ... and? vb1...
If
so.... you have (at least) two smaller classes A and B with variables
va1, ... and vb1, ... respectively and class invariants CIa and CIb
Repeat until you cannot make it simpler.
This plays nice with
I suspect there are more games you can play like this to make things simpler and more reliable.
On Tue, Oct 4, 2022 at 8:30 PM Peter Gfader < peter@...> wrote: Hi fellow programmers
Non native English?speaker here, so thanks for points about answer 3.
I get the below question quite often in my clean code refactoring OR agile developer trainings after introducing principles:
"What is the difference between SOC (Separation of Concerns) and SRP (Single Responsibility Principle)?"
My answer has grown in the direction of 3 things:
- Timing
- when do you think about this principle in the back of your mind?
- SOC more as a process during design and problem decomposition (slicing)
- SRP more after the fact, when the code/system exists (What is this package responsible for)
- Flight level of the principle
- SRP is about things and their behavior?
- Things being functions, classes, packages, namespaces, modules,?
- SOC could be applied
- within a function (Is the concern of "x" clearly visible and separated)
OR
- on an architecture level (Where is the concern of "y" handled?)
- The terms "responsibility" VS "concern"?
- "responsibility" reminds me of OO (see flight levels)
- "concern" could be anything in my language world: activity, task, goal, responsibility, request, pure...
- It's more about "where is this concern visible or delegatable to"
What would you answer to "SRP vs SOC"?
Thanks!!!
Peter Gfader
This communication is confidential. We only send and receive email on the basis of the terms set out at
|
Peter Gfader