author doesn't understand accessors (set/get methods)

The purpose of accessor methods is to abstract the data in your class. Having a protected bullets counter is only scarcely different from making it private and having getbullets() and setbullets() methods.

The *reason* you abstract the bullets counter into accessor methods is so you don't have to have a bullets counter at all (!)

What if you are building a class of automatic weapons, and you want to implement all firing methods in terms of a burst. Your tommy gun fires a ten-round burst. Your pistol fires a 1-round burst. You want to talk about your bullets in terms of bursts, instead of bullets.

Having a protected bullets counter fixes your implementation in terms of bullets, not bursts. You want to write your data access in terms of bursts and the operations you wish to use on bursts, like burstfire() which consumes a burst and reload() which puts a new magazine in, containing however many bursts it contains.

Now, you might decide that the operations you want to support are firing bullets, not firing bursts. In that case, the operations on bullets are expend() and reload(). Now you aren't counting bullets. You're performing allowed operations on your chosen abstraction. It's not the choice of abstraction that matters, it's the use of abstraction.

Interface/abstract class - not an either/or

Many people (self included) would argue that a better solution to your first example is to keep the interface of Weapon and introduce a parent class to Pistol and TommyGun called AbstractWeapon. That way you get to keep the independence of the interface (any class can implement Weapon without being a subclass of *your* AsbtractWeapon). The best of both worlds.

"lucky enough to know the Template Method pattern"?

Honestly!

testability

As a recently self taught professional (they keep paying me) C++ programmer (and probably not a very good one) I have not written many test and I've certainly not done so in a systematic way. One of the best points of this article is to highlight the correlation between good design and testable code. I must educate myself further on good testing practices.

Interface/Abstract question

As by AC above, but also consider: there is a consistent logical path from Requirements to Interfaces to Abstracts to Concretes. Although we can realize short-term gains by skipping one of these steps, keeping all steps provides a useful overview, metadata for the construction of documentation and to help focus testing and debugging, and checks to prevent or minimize the final project drifting from the requirements.

Why do you think your math teacher always told you to show your work?

Gets the Point; Then Drops It

The point is, Keep It Simple, Stupid. Java (and all OO) is inherently a complex way to implement most business applications. Most business objects are already abstractions of reality (money, deadlines, interest rates, taxes). Adding another level of abstraction is about as useful as learning to fart the Warsaw Concerto. Which is why you will always see OO examples of classes as something tangible- guns, fruit or books. Try doing payroll, instead, and COBOL suddenly looks very advanced and useful by comparison. Finally, after 26 years of this, my rule of thumb in code reuse for business applications is that if it doesn't substitute for a system routine (e.g. Date or Time) then it probably isn't worth coding as a separate routine or method. Just put inline.

Bingo!!!

Reading the article reminded me of the IBM 'buzz word bingo' commercial. Lots of buzz words to say that nothing (except the buzz words) has changed much over the years. Programmers have been using these same concepts for decades, thing is, we just didn't make up fancy names for them.

Oh, and what James Anderson said about the Y2K fiasco (I second that). It really irritates me when people refer to it as a bug or a programming mistake. It was done, on purpose, for some very good business reasons. And, those of us who knew much about computers knew that the century change would be at most an irritation, no airplanes falling out of the sky.

98, 99, ... (text required by Reg comment posting system)

Yes but "those of us who knew much about computers " also knew that

a) the potential scope was, at the time, unknown

and

b) doing nothing was not an option

Additionally I recall that much robustness improvement came out of the "Y2k" work as a by-product of the reviews and testing work.

Aircraft falling from the sky was not likely, but it was not possible to say how unlikely at the time.

More likely was out-by-one (or worse) errors in flight navigation systems or air traffic control, or counters logging flying hours that scheduled component replacements.

Failure to replace components _could_ have resulted in aircraft loss when the component failed.