Sure, I guess I tacitly assumed that anyway.
But on a software project where you are doing OO, there might be
other business drivers that would cause one to 'skimp' a bit on
the purity of following SOLID principles because the overall value
would be improved (not to mention that 'reason for change' is the
fundamental arbiter within SRP and is just a bit vague).
In which case, it isn't a principle (as you defined it) or
principles can, in fact, be broken here.
Since linguistic definition 'debates' aren't my forte, I don't
care which it is, as long as the point is understood.
--- In email@example.com
, "Chad Myers" <chad.myers@...>
> Please allow me to clarify/be more specific:
> When I said "Software Design", I should have said "Object
> This is one school of study. Different principles and rules
> different schools (i.e. functional).
> On Wed, Jan 14, 2009 at 1:45 PM, jdn3times <jdn3times@...> wrote:
> > But I would argue that within given contexts, you can always
> > follow one of the SOLID principles (not to mention that e.g.
> > difficult to interpret perfectly).
> > But, thanks, it helps to figure out more precisely what you
> > jdn