Not really. I am in palm coast so ONETUG is about an hour and a half drive. With the recent rise in gas prices I find it hard to make the trek.

JAXDUG is a lot closer to me and I have done one presentation there last month. I’ll probably go back soon and do some more presentations on more OSS.

I was in orlando for the code camp recently. That was really neat.

This got me reading your other blog posts; pretty good stuff. I enjoyed the “Open Source” thing – although the comments sorta strayed into the weeds there toward the end. Were you thanking “Joe Healy” (the “Fish”)? If ya see him, tell him Vic from The Fund says “hey”!

Anyway I’m basically in agreement with you though, and will probably add some stuff like I posted on Mats Helander’s blog.

BTW, do you appear regularly at ONETUG?

Kinda off-topic, so apologies for taking up the space…

The whole reason that checkingaccount has no implementation is because this is an example. I’m sure if I would have been writing actual classes here everything would have ended up much different.

The whole reason that I used this was to keep it as simple as possible while still illustrating my point.

Excellent points however.

The realization that not all bank accounts pay interest is the 1st thing that shoulda happened when modeling “BankAccount”; then would follow the move from the general to the specific. Figuring this out later is OK I guess, but is really just determining that “CheckingAccount” doesn’t have that feature.

“Colin Jack”s comments got me thinkng, but then I realized that responsibility separation doesn’t have to mean “outside the fam”, so inheritance looks like a reasonable way to breal out responsibility. He has a point though on the whole “implementation vs interface” thing. Actually this is a bad example because if anyone were to look at this class diagram, they’d ask why “CheckingAccount” has no implementation (“class proliferation” problem). From this look (if the names weren’t attached), you’d logically conclude that a savings account is just a specialized checking account. This represents an impedance mismatch between technical and business worlds. In the “real world”, savings accounts came 1st, then checking accounts, which in business seems normal, but plays havoc on the OO-minded because the newer thing should extend capabilities, not taking them away (like the ability to acrue interest going away). Designers would then have to flipSome checking accounts are indeed interest-baring as well so leaving it there would help their refactoring down the road, but just an example of how the example could lead to confusion about the problem, especially when the questionable things centr around what the demo is aluuding to (responsibility in this case).

Anyway (whew!), I think the problem people have with adhering to this seemingly simple principle stems from the another impedance mismatch between responsibilities and reasons to change. There has to be some kind of “apples-to-apples” endeavor to get on equal terms before you can even compare the 2. Reasons to change can be anything; in this case, the “BankAccount” class’s “Deposit” or it’s “Withdraw” truly represent to distinct functions (and hence, reasons to change. If I change the “Withdraw” ‘responsibility’, it affects “BankAccount” ‘clients’ (like my wife) who only care about this activity – which is OK (nothing broken yet), but it also affects those only interested in making deposits (like my company’s automatic salary deposit system) because this class’s code has been cracked open (possibily introducing subtle bugs to other than the target code) and now has to be regression tested, redeployed, etc., which affects all clients of the class. Now we’ve violated the defined intention of SRP, which is to avoid this by the isolation of responsibilities/reasons to change. I have 2 “reasons to change” but still only 1 stated responsibility to “manage the account”.

By the same token, the granularity of the responsibility of “managing a bank account” that’s being encapsulated/represented by “BankAccount” is really relative, isn’t it? Withdrawing and depositing at this granularity level, represent 2 entirely different concerns; under this interpretation, does this mean that “BankAccount” is no longer singly responsible/should be broken out? If the responsibility is interpreted as “all things that happen to a bank account”, then we’re OK, and changes to either “Deposit” and “Withdraw” functionality can be ‘interpreted’ as non-disruptive beacuse they combine to represent a single resposibility.

In the extreme, strict adherence to this principle would mean that each method would be in a class by itself because technically/depending on your altitude/distance from the abstraction, they can be seen as separate responsibilities and reasons to change. Concersely, another extremity is you can move further away and say that an entire system has a single responsibility and should all be in 1 class!

I think something that helps reduce this impedance mismatch (in conjunction with thinking about
‘reasons to change”) – as alluded to above – is focusing on:
- Data shared between methods
- The impact to the bject’s client/user of making a change.
- Usage scenarios
W/ respect to the “BankAccount” model: that 1st extreme case (all methods in a separate class) provides maximum isolation of the client from change, but results in loss of encapsulation because multiple classes are operating on the bank account. In the 2nd extreme case (all methods in 1 class), this solves the encapsulation problem, but potentially affects every single client using the system when things change.

We have to come up with “reasonable” solutions, so thinking about all 4 things (reasons to change, shared data, client impacts, usage scenarios) seems a more noteworthy voice of “reason”. Applying these, you seem to end up not with separate “Withdrawl” and “Deposit” classes or a big “Bank” class (e.g. w/ “Deposit” method that also takes the account number), but 2 (parent-child) account classes that seems to reasonably satisfy SRP.

I see SRP related to the “business” responsiblities of the class and not aspects of it’s identity, information hiding mechanisms, or state management (such as serialization). Although I can see an argument for using a momento to do serialization, but that’s a limitation of the language (platform) and not the domain.

Now if the BankAccount class did something like saving to the database or managing transactions, then it would have more than one reason to change and I think that would fall under the SRP.

Well, my $0.02

I guess though that this is really just handling implementation SRP because you’ve separated the code (though into a subclass rather than a totally separate class) but you’ve not got interface SRP. In this case that’s fine but in a lot of cases I think you really need to break the behavior out completely.

Just in general my favourite descriptions of SRP comes in “Working Effectively With Legacy Code”, I particularly like the ScheduledJob example.