Skip to content

Commit 93dbee1

Browse files
webprowebpro
committed
Move/extemd SoC
1 parent caf9206 commit 93dbee1

File tree

2 files changed

+44
-34
lines changed

2 files changed

+44
-34
lines changed

‎README.md

Lines changed: 22 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -11,6 +11,7 @@ The list was inspired by [The Principles of Good Programming](http://www.artima.
1111
* [KISS (Keep It Simple Stupid)](#kiss)
1212
* [YAGNI](#yagni)
1313
* [Do The Simplest Thing That Could Possibly Work](#do-the-simplest-thing-that-could-possibly-work)
14+
* [Separation of Concerns](#separation-of-concerns)
1415
* [Keep Things DRY](#keep-things-dry)
1516
* [Code For The Maintainer](#code-for-the-maintainer)
1617
* [Avoid Premature Optimization](#avoid-premature-optimization)
@@ -22,7 +23,6 @@ The list was inspired by [The Principles of Good Programming](http://www.artima.
2223
* [Law of Demeter](#law-of-demeter)
2324
* [Composition Over Inheritance](#composition-over-inheritance)
2425
* [Orthogonality](#orthogonality)
25-
* [Separation of Concerns](#separation-of-concerns)
2626

2727
### Module/Class
2828

@@ -83,6 +83,27 @@ Resources
8383

8484
* [Do The Simplest Thing That Could Possibly Work](http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html)
8585

86+
## Separation of Concerns
87+
88+
Separation of concerns is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. For example the business logic of the application is a concern and the user interface is another concern. Changing the user interface should not require changes to business logic and vice versa.
89+
90+
Quoting [Edsger W. Dijkstra](https://en.wikipedia.org/wiki/Edsger_W._Dijkstra) (1974):
91+
92+
> It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant.
93+
94+
Why
95+
96+
* Simplify development and maintenance of software applications.
97+
* When concerns are well-separated, individual sections can be reused, as well as developed and updated independently.
98+
99+
How
100+
101+
* Break program functionality into separate modules that overlap as little as possible.
102+
103+
Resources
104+
105+
* [Separation of Concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)
106+
86107
## Keep things DRY
87108

88109
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
@@ -228,22 +249,6 @@ Source: [Be Orthogonal](http://www.artima.com/intv/dry3.html)
228249
229250
Source: [Orthogonality](http://en.wikipedia.org/wiki/Orthogonality_(programming))
230251

231-
## Separation of Concerns
232-
233-
Separation of concerns is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. For example the business logic of the application is a concern and the user interface is another concern. Changing the user interface should not require changes to business logic and vice versa.
234-
235-
Why
236-
237-
* Simplify development and maintenance of software applications.
238-
239-
How
240-
241-
* Break program functionality into separate modules that overlap as little as possible.
242-
243-
Resources
244-
245-
* [Separation of Concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)
246-
247252
## Maximise Cohesion
248253

249254
Cohesion of a single module/component is the degree to which its responsibilities form a meaningful unit; higher cohesion is better.

‎index.md

Lines changed: 22 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -18,6 +18,7 @@ The list was inspired by [The Principles of Good Programming](http://www.artima.
1818
* [KISS (Keep It Simple Stupid)](#kiss)
1919
* [YAGNI](#yagni)
2020
* [Do The Simplest Thing That Could Possibly Work](#do-the-simplest-thing-that-could-possibly-work)
21+
* [Separation of Concerns](#separation-of-concerns)
2122
* [Keep Things DRY](#keep-things-dry)
2223
* [Code For The Maintainer](#code-for-the-maintainer)
2324
* [Avoid Premature Optimization](#avoid-premature-optimization)
@@ -29,7 +30,6 @@ The list was inspired by [The Principles of Good Programming](http://www.artima.
2930
* [Law of Demeter](#law-of-demeter)
3031
* [Composition Over Inheritance](#composition-over-inheritance)
3132
* [Orthogonality](#orthogonality)
32-
* [Separation of Concerns](#separation-of-concerns)
3333

3434
### Module/Class
3535

@@ -90,6 +90,27 @@ Resources
9090

9191
* [Do The Simplest Thing That Could Possibly Work](http://c2.com/xp/DoTheSimplestThingThatCouldPossiblyWork.html)
9292

93+
## Separation of Concerns
94+
95+
Separation of concerns is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. For example the business logic of the application is a concern and the user interface is another concern. Changing the user interface should not require changes to business logic and vice versa.
96+
97+
Quoting [Edsger W. Dijkstra](https://en.wikipedia.org/wiki/Edsger_W._Dijkstra) (1974):
98+
99+
> It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant.
100+
101+
Why
102+
103+
* Simplify development and maintenance of software applications.
104+
* When concerns are well-separated, individual sections can be reused, as well as developed and updated independently.
105+
106+
How
107+
108+
* Break program functionality into separate modules that overlap as little as possible.
109+
110+
Resources
111+
112+
* [Separation of Concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)
113+
93114
## Keep things DRY
94115

95116
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
@@ -235,22 +256,6 @@ Source: [Be Orthogonal](http://www.artima.com/intv/dry3.html)
235256
236257
Source: [Orthogonality](http://en.wikipedia.org/wiki/Orthogonality_(programming))
237258

238-
## Separation of Concerns
239-
240-
Separation of concerns is a design principle for separating a computer program into distinct sections, such that each section addresses a separate concern. For example the business logic of the application is a concern and the user interface is another concern. Changing the user interface should not require changes to business logic and vice versa.
241-
242-
Why
243-
244-
* Simplify development and maintenance of software applications.
245-
246-
How
247-
248-
* Break program functionality into separate modules that overlap as little as possible.
249-
250-
Resources
251-
252-
* [Separation of Concerns](https://en.wikipedia.org/wiki/Separation_of_concerns)
253-
254259
## Maximise Cohesion
255260

256261
Cohesion of a single module/component is the degree to which its responsibilities form a meaningful unit; higher cohesion is better.

0 commit comments

Comments
 (0)