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:
From http://en.wikipedia.org/wiki/Separation_of_concerns: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.
If the above two definitions of the terms in question aren't analogs then I need to be shot.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]
Anyway, why is one term picked up and not the other? Is this an issue with community? Something tribal? Thoughts?
