Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Theory of Software Architecture

danuker.go.ro

Post reply on HN
Print view View original

121–130 of 246 posts

Re: A Theory of Software Architecture

#121

Post by PaulDavisThe1st »

aryehof wrote: post #29
jonahx wrote: post #9

Earlier 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…

I have an object called TransportMaster, with concrete implementations X_TransportMaster, Y_TransportMaster, Z_TransportMaster. The application instance may contain any number of any mixture of these objects, and they may be created and destroyed at any time by the user. Their use within the application is also subject to the user's whims.

Why would a TransportMasterManager, which provides factory methods, enumerations, a collection of the current set of TM's, and knowledge of the current user choice for which TM's is being used for what, have "no place" in this design?

Re: A Theory of Software Architecture

#122

Post by w_t_payne »

With this architecture, it feels like the very outermost level - the framework and drivers - would ideally have little or no application-specific logic in it whatsoever, and would exist simply to glue together the various functional components with I/O and distribute them to whatever computational resources are required for their execution.

This, to me, feels very very similar to a model-based approach, where the outermost level is a modeling framework that does nothing more than route data between different functional components and IO components.

I have a strong hunch that this outermost layer does not need to consist of anything more than a suitable framework plus some configuration data specifying (a) the mapping from functional components to hardware resources and (b) the data flow between functional components.

If this is indeed the case, then, extracting individual components or subsets of the system for testing should simply be a matter of providing a suitable transformation of the configuration data, and re-executing the framework.

Re: A Theory of Software Architecture

#123

Post by forest_dweller »

tonyarkles wrote: post #116
iainmerrick wrote: post #115

This 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.

I agree sometimes it can be an hunt if someone used some crazy implementation of the strategy pattern. However if you are following SOLID you shouldn't depend on a concrete class.

I'm dealing with a project at the moment where they haven't done DI and everything is dependant on concret classes and I just can't write tests (without huge setup methods) for anything non-trivial and I have these large constructors initialising things in every class.

Re: A Theory of Software Architecture

#124

Post by SNACKeR99 »

chrisweekly wrote: post #112
kumarvvr wrote: post #26

Earlier quoted context omitted.

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".

Before we shuffle off this mortal stack.

Re: A Theory of Software Architecture

#125

Post by cryptos »

kumarvvr wrote: post #119
aryehof wrote: post #29

Earlier quoted context omitted.

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.

I don't know Peter Coad, but the approach reminds me of domain driven design (DDD). Most business logic would be in objects named entities, but DDD has also services, since there might be logic that affects multiple entities (actually special entities called "aggregate root").

Re: A Theory of Software Architecture

#126

Post by rvense »

peterwwillis wrote: post #97
rvense wrote: post #91

Earlier quoted context omitted.

I think that fn x() { doStuff(); moreStuff(); forgotSomething(); } is pretty bad code, but that's probably because I consider procedures with no arguments and no return value a sign that something is poorly factored. However, fn x(y) { foo = doStuff(y); bar = moreStuff(foo); if (isSomething(bar)) { return theRest(bar) } else { return theBest(bar); } } can be a good way to separate the why from the how and clearly com…

The former example was much easier for me to understand than the latter, even if it wasn't factored well. But I'm assuming that the functions aren't mucking about with global state or something equally distasteful.

Well, if we assume that both are doing the same work, then the explicitly named variables y, foo, and bar of my second example would, in the first example, have to be global variables, or at least things that are defined in the scope of the definition/call of x.

Given that, I have to say that I, err, and I'm sorry if this sounds a little arrogant, but I don't really believe you when you say that it's easier to understand. It might be easier on the eyes, sure, but to really understand how the first one works, you'd have to look into all the defined helper functions, and see which outer-scope variables they touch (global/module/class scope), and also, probably, have some knowledge of where x is called. In a style closer to the second example, there are less outside dependencies.

Of course, this is all very abstract. I'm not saying there aren't cases where a few variables in global (or class) scope that get mutated by bare functions can't work at all, but as a rule I don't consider it a good style.

Re: A Theory of Software Architecture

#127

Post by PaulDavisThe1st »

makach wrote: post #43

We have built software for a long time and we have learned a lot. There are many good ways (patterns) to reuse when you need to solve a particular problem. Uncle Bob speaks the truth. For me, the challenge has never been with the architecture or our combined technical knowledge. What I have observed as the main challenge is that most technologists start solving the problem before they know what the problem is.

An equally large challenge is that solving a problem with software (and sometimes hardware) tends to lead to new problems that are experienced as part of the original problem.

Another equally large challenge is that the person/people with the problem to be solved doesn't actually understand the problem and is incapable of describing it in a way that makes it a priori understandable.

Re: A Theory of Software Architecture

#128

Post by nahname »

speedgoose wrote: post #32

I understand that the point of his example is to introduce the reader to a variant of the very classic multitier architecture with layers. https://en.wikipedia.org/wiki/Multitier_architecture But I prefer the first version of the example, because while it's named "complex code" I think it's the simplest version. I think that there is no need to decouple this simple and straightforward function in three functions that…

There are people who cannot use an abstraction unless they understand every line of code behind it. Abstractions are blockers, rather than aids. This lowers the value of abstraction for those individuals.

Others find it tiresome to read every line of code and develop intuition around abstractions instead. The "find_definition" function will be all that is parsed.

The funny thing is people shift between the two as the scope of the project increases.

Re: A Theory of Software Architecture

#129

Post by marcosdumay »

tarruda wrote: post #105
wsc981 wrote: post #78

Earlier 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 don’t think that purely functional programming writ large is a pragmatic development plan, because it makes for very obscure code As a functional programming enthusiast, I agree with this. Recently I worked on rewriting a relatively large backbone web application in React/Redux (For those that don't know, Redux is a framework for writing JS in a more functional style). While moving all app logic to functional sty…

> Doing side effects from functions that are assumed to be pure.

That completely goes away as soon as your language has purity declared at the type system.

It's just not available for Javascript development, like most nice FP features.

Re: A Theory of Software Architecture

#130

Post by PaulDavisThe1st »

makach wrote: post #79
username90 wrote: post #66

Earlier quoted context omitted.

If the people asking you to solve a problem don't know what problem they want solved then there isn't much you can do except try to solve something and see if they complain. You could argue that you should talk more with the stakeholders, but most of them don't have the skills required to accurately identify their own problems. Instead they need to see something running and then notice when things are missing, which…

An business analyst appeared in the wild (..) as a consequence of stakeholders not knowing or having the necessary skills. BAs are experts in illiciting user requirements and transforming them into specifications and goals you can use to solve a problem. Unless you know your goal you will never be able to deliver on your customer's expectations.

BA's work on business software which is typically written to help support processes and workflows that lean toward structure, definition, repeatability and so forth.

There's lots of software in the world (all creative software, for example) that doesn't share these attributes, and all the skills of a BA are useless.

The scope of software is larger than webdev and larger than business.

Post reply on HN