This is great— thanks for sharing
A Theory of Software Architecture
111–120 of 246 posts
Re: A Theory of Software Architecture
#112Earlier quoted context omitted.
Agree on the functional bit. Naming things: I try to not think about it for more than 10 seconds, and go with the best I've got by then. I find myself renaming things sometimes, and I'm eager to do this when a better name comes to me.
I did try that. That is how I ended up with 50 "Manager" classes in my app. At that point, it is a cognitive burden to handle so many "managers".
Shakespeare the software architect: "First kill all the Managers".
Re: A Theory of Software Architecture
#113I find it amusing how these software architecture gurus always demonstrate their teachings with a cookie-cutter CRUD app. There are software which do things other than making REST calls... Show me how you’d implement a basic MS Paint clone and we can talk!
What is it that makes you think you couldn't implement ms paint in this architecture? I've seen all sorts of thing with this sort of architecture, ranging from dungeon crawlers to distributed virtual machine orchestrators, to file system browsers, etc.
E.g. I don't see how the text tool would work. Where's the transient state stored while the text is being entered, but not yet finalized? Similarly, how would drawing a line work? That is, drawing a long squiggle, that is continuously updated while drawing, but will still be undone/redone with a single Undo/Redo operation.
I simply don't see how this fits the functional core + imperative shell pattern.
Re: A Theory of Software Architecture
#114Earlier quoted context omitted.
> Sometimes a big, fat block of code is just easier to understand. John Carmack made once the same comment: http://number-none.com/blow/blog/programming/2014/09/26/carm...
I haven't read that in awhile. But the argument was around optimisation rather how easy it is to understand.
The way I read the article, I believe his main point was to make reasoning about state easier, even at a small cost to performance, making code easier to test and debug.
Re: A Theory of Software Architecture
#115This is good advice and a good writeup, but I take exception to one (boldface!) line:
Coupling kills software
I hear this a lot but I think it’s highly overstated.
The “clear” final version is still strongly coupled -- you can’t call find_definition without it directly calling the build_url helper! The key aspect isn’t the coupling, it’s that the high-level imperative function is calling a simple, low-level, testable helper.
Coupling can be bad, sure, but not if it’s kept under control. And excessive decoupling can make programs much harder to understand and debug! Have you ever worked on an app where every reference to another object is injected via a DI framework, and where all the significant calls that actually do stuff are farmed out to asynchronous messages and callbacks, all in the name of decoupling and testability? That can make it really hard to debug problems. A good balance is what’s needed, not decoupling over all other concerns.
Re: A Theory of Software Architecture
#116This is good advice and a good writeup, but I take exception to one (boldface!) line: Coupling kills software I hear this a lot but I think it’s highly overstated. The “clear” final version is still strongly coupled -- you can’t call find_definition without it directly calling the build_url helper! The key aspect isn’t the coupling, it’s that the high-level imperative function is calling a simple, low-level, testable…
> every reference to another object is injected via a DI framework
And it's injected with an interface, not a concrete class, so you have to go on a giant easter egg hunt to even figure out which class is being injected... only to eventually discover that there's only one class that implements that interface.
Re: A Theory of Software Architecture
#117When I see a subroutine with a verb in its name I think of side-effects. In my book a pure function should be named after the result it returns, so in this case I would use the name `definition' instead of `find_definition' and `definition_url' instead of `build_url'. For predicates I try to avoid an "is" prefix when a simple adjective is sufficient.
Map, reduce, filter, fold, project, transform, group_by, bind, apply - any functional API you care to look is all verbs. Functions do work. That doesn't mean they have to have side-effects; if they're functional, they do work on the input and produce output. Doing is a verb. It's natural. Using a noun as a function name is at best justified when you have a situation where you want to hide whether data is being calcul…
It depends on the culture and the programming language. The advantage of using noun phrases for pure functions is that
1. only by reading the name of the function you know it's a pure function
2. a call to a pure function in an expression reads more naturally since operands are values and values are nouns.
Re: A Theory of Software Architecture
#118Earlier quoted context omitted.
Haven't you just described functional vs procedural programming?
No he described implicit arguments and mutation vs. explicit arguments and mutation. It's independent of OOP vs. functional, through it's easier to have implicit arguments and mutation in OOP so you see it more often there, especially if people somehow ended up believing that programming OOP means you need to create a class for everything and make all states a object member instead of e.g. a variable in the stack.
Yes! I often see code that where a method sets an instance variable, then calls another method that does some work based on that instance variable, which is then not used until the next time that first caller is used. The instance variable is redundant, and the control flow is obfuscated. I think the principle is just to only expose something when you really have to (harhar), and that the 70's suspicion of unstructured use of global scope should be equally directed to class scope.
Re: A Theory of Software Architecture
#119Earlier quoted context omitted.
> (..Manager, ..aggregator,etc.) Names ending in Manager are usually a poor choice. See Peter Coad's "-er-er" principle: > The “-er-er” principle. Challenge any class name that ends in “-er.” If it has no parts, change the name of the class to what each object is managing. If it has parts, put as much work in the parts that the parts know enough to do themselves. See also: http://www.carlopescio.com/2011/04/your-codi…
I think the commenter generally views things as code acting on entities. If so, that code is suited to being called an xxxManager, or xxxService, or xxxCoordinator, or xxxController. Of course we have returned to a place in history by doing so, of creating big balls of mud as complexity increases. Peter Coad advocated against this in favor of modeling the problem domain under consideration using an object oriented ap…
>modeling the problem domain under consideration using an object oriented approach
Really curious. Do you have any material that explains this way of design?
I work on mostly web apps. End of the day, it's really about moving data and transforming data. So most of my programs have no choice but to deal with data, and so, my whole design process revolves around gathering, storing, operating upon and transferring data.
Re: A Theory of Software Architecture
#120This is good advice and a good writeup, but I take exception to one (boldface!) line: Coupling kills software I hear this a lot but I think it’s highly overstated. The “clear” final version is still strongly coupled -- you can’t call find_definition without it directly calling the build_url helper! The key aspect isn’t the coupling, it’s that the high-level imperative function is calling a simple, low-level, testable…
> every reference to another object is injected via a DI framework And it's injected with an interface, not a concrete class, so you have to go on a giant easter egg hunt to even figure out which class is being injected... only to eventually discover that there's only one class that implements that interface.
But then despite that the class is getting a generated proxy that does basically nothing or is causing the problem and it is really hard to determine anything except tracing it at runtime to find out what actually is being run. People do some crazy things with Spring and interface injections in Java and it can get really Opaque quickly but also often it really is just 1 class implementing an interface and there are no tests using the interface at all.