Page 1 of 1
Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 9:57 am
by BDKR
For a time when I was looking for work (not as of late as I'm very happy where I am now), I was often suprised at the looks on interviewers faces when I would use the term "Responsibility Driven Design". The look on their faces was blank! I, OTOH would allways think, "And these guys are judging me?".
But anyway, I've often laughed to myself when I heared the term Seperation of Concerns because I immediately recognized it as a an analog for Repsonsibility Driven Design.
From
http://www.wirfs-brock.com/Design.html:
Our approach, known as Responsibility-Driven Design, is a way of designing complex software systems using objects and component technology. Responsibility-Driven Design was conceived in 1990 as a shift from thinking about objects as data + algorithms, to thinking about objects as roles + responsibilities. Responsibility-Driven Design catalyzes object technology with practical techniques and thinking tools.
In a responsibility-based model, objects play specific roles and occupy well-known positions in the application architecture. It is a smoothly-running community of objects. Each object is accountable for a specific portion of the work. Objects collaborate in clearly-defined ways, contracting with each other to fulfill the larger goals of the application. By creating such a “community of objects,” assigning specific responsibilities to each, you build a collaborative model of your application.
From
http://en.wikipedia.org/wiki/Separation_of_concerns:
In computer science, separation of concerns (SoC) is the process of breaking a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program. Typically, concerns are synonymous with features or behaviors.
SoC is a long standing idea that simply means a large problem is easier to manage if it can be broken down into pieces; particularly so if the solutions to the sub-problems can be combined to form a solution to the large problem. SoC can be supported in many ways: by process, by notation, by organization, by language mechanism and others.[1]
If the above two definitions of the terms in question aren't analogs then I need to be shot.
Anyway, why is one term picked up and not the other? Is this an issue with community? Something tribal? Thoughts?
Re: Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 11:24 am
by Maugrim_The_Reaper
One could could be interpreted as a methodology, the other a component of OOP best practice. Or put another way, the second recognises it's been elevated to the position of being taken for granted so doesn't need a methodology name since it's not debatable

.
Re: Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 11:58 am
by Christopher
I think Maugrim is on to it. Methodologies are for programmers to argue about.

Best Practices are something to use until something better comes along.
I'd say DRY is the latest incarnation of Separation of Concerns, but it did not replace it -- just added some attitude.
Re: Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 12:00 pm
by alex.barylski
I would say it's a cultural thing...although seperation of concerns sounds more practical than responsibility driven development...
Re: Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 12:55 pm
by BDKR
Hockey wrote:...although seperation of concerns sounds more practical than responsibility driven development...
Why? How is "
roles + responsibilities" (from RDD definition above) different then "
features or behaviors" (from SoC definition above)? Especially when during a design process one can say "This object is
responsible for such and such
behaviour". Amongst two synonyms, how can one be more practical then the other?
Not trying to be argumentative here. Just curious why you say this. Perhaps there is something I'm not considering here.
Re: Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 1:02 pm
by BDKR
Maugrim_The_Reaper wrote:One could could be interpreted as a methodology, the other a component of OOP best practice. Or put another way, the second recognises it's been elevated to the position of being taken for granted so doesn't need a methodology name since it's not debatable

.
I could argue that methodologies and best practices are the same you know. The American Heritage Dictionary lists as it's definition of methodology...
A body of practices, procedures, and rules used by those who work in a discipline...
http://dictionary.reference.com/browse/methodology
That's not the whole thing, but just to give you an idea.

Re: Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 1:37 pm
by alex.barylski
Not trying to be argumentative here. Just curious why you say this. Perhaps there is something I'm not considering here
Good Question. I admit to having put much thought into my answer and you have apparently caught me with my pants down.
Responsibility Driven Development. Without a firm understanding of what it really represents, I guess it could be interpreted many ways.
Responsible for what? It sounds more like a ideaology or methodology than a best practice to me...
Seperating your concerns...is...well...all about separating your conerns. If you understand what a concern is it makes immediate sense, whereas if you don't know what constitutes a responsibility (is it about being disciplined and keeping presentation logic out of business logic or is it about taking a proactive role towards security or performance perhaps???) the term is vague.
Maybe it's the word 'separation' that sets the stage for me...'concerns' like 'responsibility' could mean a lot of things to the un-initiated whereas seperation in the context of programming is pretty well understood.
Regardless of whether there is analog between the two...I would still personally prefer to keep them separate. Much like TDD and BDD are analogous, I personally see them as different. Otherwise why would different terms be used in the first place and one not just adopt the others name? Probably, becuase there are differences.
Cheers

Re: Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 2:45 pm
by Christopher
I did a little research on the two terms you mentioned.
- Responsibility-Driven Design what created in 1990 by Rebecca Wirfs-Brock. I think I have heard of her, she wrote a book and based her consulting business on the idea. It is sort of her trademark methodology.
- Separation of Concerns is from Edsger W. Dijkstra way back in 1974. Now I have heard of that guy.

It is a catch-phrase for a fundamental way of thinking about programming that has resonated with programmers for decades.
So the meta-answer to your question is that the dialectic sorted out which would last...
PS - A I recall that Dijkstra guy hated GOTOs so much that he succeeded in pushing all of us toward some little thing called Structured Programming.

Re: Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 3:01 pm
by BDKR
arborint wrote:
So the meta-answer to your question is that the dialectic sorted out which would last...
It's interesting to me just how influenced we are by our teachers. I didn't realize it until I started this conversation. The vast majority of my initial learnings on the subject of OO was from Timothy Budd (
http://web.engr.oregonstate.edu/~budd/Books/). I've come to realise that he really is a big RDD guy and passed the whole RDD/OOD thing off to me.
Re: Differing terms for the same shizzle.
Posted: Tue Jan 22, 2008 3:12 pm
by Christopher
BDKR wrote:It's interesting to me just how influenced we are by our teachers. I didn't realize it until I started this conversation. The vast majority of my initial learnings on the subject of OO was from Timothy Budd (
http://web.engr.oregonstate.edu/~budd/Books/). I've come to realise that he really is a big RDD guy and passed the whole RDD/OOD thing off to me.
I agree and often find I am most influenced by who I am currently reading. It is also interesting how the right idea at the right time can have such a profound impact on me ... whereas a year earlier it just went in one ear and out the other.
It is not as if RDD did not make it ... it's just by another name (or two).
PS - I also wonder if there was a little sexism involved here as Software Engineering has always been a bit of a boys club...
Re: Differing terms for the same shizzle.
Posted: Tue Jan 29, 2008 3:40 am
by Ollie Saunders
Interesting thread.
One could could be interpreted as a methodology, the other a component of OOP best practice. Or put another way, the second recognises it's been elevated to the position of being taken for granted so doesn't need a methodology name since it's not debatable
I view a methodology as higher level than development practice. Methodologies usually offer solutions to "how to create software" not just how to write good code. They fill a different role but there's definitely blurring between the two. A methodology usually contains many best practices.
Also I would be tempted to say that agile and it's derivative offspring are best practice methodologies these days.
When I hear Responsibility Driven Design I actually don't think of that completely as a methodology because it's actually specific to code design.
Re: Differing terms for the same shizzle.
Posted: Tue Jan 29, 2008 1:44 pm
by BDKR
ole wrote:
When I hear Responsibility Driven Design I actually don't think of that completely as a methodology because it's actually specific to code design.
Programming in it's entirety (small thrown together hacks excepted) normally includes a design phase. Ergo, design
is methodolgy.
SofC (as in Seperation of Concerns) and RDD is methodolgy for realizing good design by way of influencing how problems are thougth about and looked at. SofC and RDD both provide mental and logical guidlines for that which is recondite: the project in front of you.
Re: Differing terms for the same shizzle.
Posted: Tue Jan 29, 2008 4:39 pm
by dml
BDKR wrote:
How is "roles + responsibilities" (from RDD definition above) different then "features or behaviors" (from SoC definition above)? Especially when during a design process one can say "This object is responsible for such and such behaviour". Amongst two synonyms, how can one be more practical then the other?
There's an emphasis in the Wirfs-Brock definition on thinking in terms of interfaces and interactions between components, as opposed to what components are doing internally. It's an emphasis that certainly needed to be made in 1990 when most developers didn't have OO experience... maybe it's more part of developers' implicit thought processes in 2008.
Is responsibility a synonym for behaviour - as long as we're only looking at behaviour that's visible to the components that interact with the object, as opposed to what an object does internally to get the job done.
How can one definition be more practical... An emphasis on roles is practical if your component is doing a job that's well understood and likely to endure, but the way it does the job is less well defined, more likely to change, and has messy details. On the other hand, some objects just "do what it says on the tin", and it's pointless abstraction to try to distinguish what it's doing from the role it's playing.
Re: Differing terms for the same shizzle.
Posted: Tue Jan 29, 2008 5:08 pm
by BDKR
dml wrote:
BDKR wrote:
How is "roles + responsibilities" (from RDD definition above) different then "features or behaviors" (from SoC definition above)? Especially when during a design process one can say "This object is responsible for such and such behaviour". Amongst two synonyms, how can one be more practical then the other?
There's an emphasis in the Wirfs-Brock definition on thinking in terms of interfaces and interactions between components, as opposed to what components are doing internally.
Which makes all the sense in the world as RDD and SofC both apply to the design phase right? That's how I'm thinking about it.
dml wrote:
It's an emphasis that certainly needed to be made in 1990 when most developers didn't have OO experience... maybe it's more part of developers' implicit thought processes in 2008.
Excellent! Something I can't comment on one way or the other but very likely all the same. Back in 1990 I was a prison guard fighting with convicts and going to school.
Good post.
