Here i leartnt principally of how to use OO in an Agile methodology, cause a good OO is necesarry if we want a true agility.
There are two main camps when it comes to defining OO: structural (if it uses polymorphism and inheritance, it’s object oriented) and architectural (OO systems are models of real or imaginary things and of the way that these things interact as they perform some useful activity). I fall firmly in the second camp; structure is an important implementation detail, but doesn’t affect the object-oriented nature of the system one iota. I’ve even programmed what I think of as object-oriented systems in assembly language, with nary a class definition or virtual method in sight.
The objections to OO come largely from people so entrenched in the first camp that they don’t know that the second camp exists. For example, they say that Java is too complicated and wordy — which is certainly true — therefore OO is bad — which is not. They say that Java is too hard to deploy — also true — therefore OO is bad. They say that design patterns can add too much complexity to what should be a simple system — again, true, but that’s a good-versus-bad design argument, not a critique of OO. They say that it’s sometimes best to program with functional-programming techniques instead of inheritance — also true, but functional programming in no way renders the system less object oriented.
In an Agile world, following HSP gives you the freedom of changing implementation without the effects of that change rippling out to the rest of the program, and this property is, again, essential when constant change is in the picture.