Separation of Concerns

Transcription

1 Separation of Concerns and its relation to software engineering, process and car bumpers Charles Féval feval.ca

2 About me Dev manager at BuildDirect Not technically a software engineer in Canada. I don't speak Portuguese. If it does not make sense, assume it's my accent. I don't like grated coconut At some point of my life I've coded in PHP and enjoyed it. It's past story. I'm very ashamed. Don't blame me. If it sounds fishy it's probably because I'm a filthy liar. I'm definitely not an expert. Some of this will sound like common sense.

3 > About common sense That what is self-evident to one person can be seen as silly by another should give us pause about the reliability of common sense as a basis for understanding the world. - Duncan J. Watts - Everything is Obvious

4 > My goal today SoC is a simple concept, so why talking about it? SoC is a very versatile tool SoC has to be a conscious process to be effective SoC can bring enormous value when it's applied

5 It all started on a sunny Sunday at Granville Island

6 > But actually, it started on a sunny Sunday at Granville Island

7 Separation of Concerns Attributed to Dijkstra: 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. The keyword here is focus: deal entirely with one thing.

8 > Applying Separation of Concerns (SoC) SoC is: A thinking pattern (one thing at a time) An improvement process (baby steps) A strategy (divide to conquer) A philosophy (carpe diem) SoC is a disturbingly universal approach

9 > We are wired against SoC We are tempted to infer a cause-and-effect relationship when all we have witnessed is a sequence of events. This is the post-hoc fallacy. - Duncan J. Watts - Everything is obvious Post-hoc fallacy, circular reasoning, attribution bias, hallo effect, anchoring Our brains are wired to see connections where there are none even though it's a simple concept, it has to be applied consciously.

10 > Everything is somewhat connected Brains evolve to match patterns and connect the dots Mixing concerns is the natural state of things (2nd law) Changing natural behaviours is uncomfortable -resistance from ourselves and from others.

11 Customer record When coding When discussing

12 Modularity / decoupling System elements should have exclusivity and singularity of purpose Singularity: it should solve only one concern Exclusivity: it should be the only one solving the concern Rule of thumb: if an element description contains the word and, it's probably addressing two concerns, and it would probably be better off decomposed. System element is a very generic term, should be interpreted at each level of abstraction.

13 > Examples FileSystem: Abstracts the access to filesystem for consumers to perform IO on hard drive FileManager: manages files Person: contact information about a person following RFC 6350 Person: person's contact info and methods to export as JSON PersonSerializer: perform JSON or XML serialization of Person PersonJsonSerializer: perform JSON serialization of a Person /person/{id}: endpoint to retrieve a person's contact info and its purchase history /person/{id}: endpoint to retrieve contact info and avatar

14 > Some technology examples HTML, CSS, JavaScript separate handling of layout, styling and behaviour through three technologies MVC frameworks try to separate handling of data, presentation and logic. Better yet: the onion architecture Databases and webservers separate data storage from code execution

15 > Horizontal SoC - Technical

16 > Vertical SoC - Functional

17 > SoC by aspect

18 > It's a matter of balance Everything should be made as simple as possible, but not simpler. - Albert Einstein Benefits from SoC is a U shaped curve

19 > Outcomes from applying SoC to system design Top-down approach to reasoning which results in: System is easier to understand System is easier to maintain It's an organic way to ensure cohesion Enhance reusability (from both accessibility and genericness) These outcomes are also a good framework to check that SoC was applied correctly

20 Software engineering: SOLID Core engineering principles introduced as the 'first 5' by Uncle Bob Single responsibility principle Open for extension / Close for modification Liskov substitution principle Interface segregation principle Dependency inversion principle Software is better SOLID than DRY See also: composition over inheritance principle

21 > SOLID and SoC All 5 SOLID principles help proper SoC

22 > Single Responsibility Principle Modules should deal with only one concern Principle: A software module has only one responsibility. Rule of thumb applies: it should be possible to describe it using one sentence without using the word and. Lemma: that which has a responsibility should embrace it entirely.

23 > Open Close Principle / Liskov Substitution Principle Principle: One is mirror to the other: OCP: don't let people do stupid things with your class and LSP: don't do stupid things with someone else's classes Focus on solving one problem, prevent it to be mixed with other problems. If an element's conceptual boundaries (a.k.a. the concern it solves) are clearly defined, one will be less tempted to breach OCP and LSP.

24 > Interface Segregation Principle Interface should not cover coffee-making and pea-sorting Principle: keep your interfaces small and focused If multiple concerns need be addressed, then multiple interfaces you should have. The thing that saves your data and the thing that saves your logs do not have the same end so should not have the same implementation. Lemma: your interface shall be whole, File.Open and File.Save are in the same interface because they address the same concern: FileSystem access.

25 > Dependency Inversion Principle Leave it to the higher levels to decide Principle: High-level modules should not depend on low-level modules. Both should depend on abstractions. What and how are two different concerns, they need to be addressed separately. Your class's responsibility is to do its job, not to decide where to log stuff. Except if its job is to decide where to log stuff.

26 Composition over Inheritance Favour code reuse through composition rather than inheritance OCP: The problem of the Flying house Square and rectangle: is square a specialized rectangle, or is rectangle an extended square? different sets of constraints and business rules different modules square might leverage the rectangle implementation they might implement their common rules and methods as a common module (drawrect)

27 > Business rules are evolving Let's consider these rules: 1. All shapes are blue. Rectangles have 4 sides and a 90 angle. Squares have 4 equal length sides and 90 angles. 2. Rectangles are blue, squares are red 3. Squares have a yellow border 4. Rectangles have 5 sides Inheritance makes evolution more complex because it breaks SoC.

28 About quotes If you don't find a quote to support your claim, quote yourself. - Charles Féval... still better than lying.

29 Problem solving If a problem is too complex, it's probably because it's not decomposed enough - Charles Féval Seems common sense, yet consciously applying it is challenging. Why, what, how, whom and when are separate concerns.

30 Organizing work Mixed concerns is the natural state of things Separating concerns is uncomfortable. People

31 Iterations / small batches Separating concerns is the root of iterating. Separating concerns = decomposing & decoupling Decomposing = reducing batch size Reducing batch size reducing cycle time Reducing cycle time reduces chances of interruption Reducing interruptions makes you happy.

32 > Multi-tasking / Focused Delivery Worse than concerns vaguely related being put together: mixing stuff that has nothing in common You guys in the business are punch drunk on projects, taking on new work that doesn t have a prayer of succeeding. Why? Because you have no idea what capacity you actually have. - The Phoenix Project - Gene Kim, Kevin Behr, George S pafford

33 >... Humans are bad at multi-tasking, as much as teams are bad at multi-tasking. Your own capacity is 1. You team capacity is n (where n = count(members)). Read Principles of Product Development Flow

34 > Personal organization: GTD and Pomodoro Getting Things Done is a methodology advocating getting everything out of your mind to achieve a state of flow. Relies heavily on separating several phases to tracking your tasks. Pomodoro is a time management method that relies on splitting your work into chunks doable in 25 minutes sections.

35 SoC & Organization Organizations which design systems [...] are constrained to produce designs which are copies of the communication structures of these organizations - Melvin Conway Clear boundaries decrease the number of communication channels replaces friction and territorial wars by cooperation A cohesive architecture requires a cohesive separation of duty

36 SoC & ToC Theory of constraints is a process improvement process. Its theory is that the global throughput of a system is limited by a single constraint. To increase throughput you need to focus on optimizing the process for the constraint. Iterates on 5 steps: identify the current constraint, decide how to exploit it subordinate the rest of the process to the constraint elevate it iterate on the new constraint

37 Exceptions SoC does not seem to apply for Negotiating, trading, etc. Just be aware that if you're not leading it, it might be that somebody plays on one of your human bias. When stuff is actually hard-linked together (e.g.: CAP theorem), in which case you're still gonna be better of separating concerns, even though they impact each other.... i.e. SoC still usefull (I will not admit that I'm wrong)

38 Conclusion Separating concerns means dealing exclusively and singularly with one aspect of a problem. SoC is universal SoC has to be a conscious process Don't mix getting a PS4 in a discussion about budget. Focus on the PS4, deal with budget later.

39 Thanks?!?