In general OO programming is a different way of thinking about organising code and data. In procedural programming the code is in a sense primary with the focus on the algorithm. In OO programming the focus tends more to be on the data. An object is really a ball of data. A class describes the things that can be done to the data contained in an object.

I very often use OO techniques in small programs to save passing extra parameters around or to avoid using global variables. When writing modules OO techniques provide a number of advantages. OO:

• avoids pollution of the module user's name space by removing the need for exports.
• reduces the need for the module user to know about data storage and management within the module.
• allows the module user to alter or add to the behaviour provided by the module.

and so on. OO doesn't remove the utility of modules which are a way of organising code into libraries that can be reused. Nor does OO do away with subroutines, but it does change their role somewhat.

I'm not exactly sure what you're looking for, see perlobj. Tutorials has a section on Object Oriented Programming, perhaps spending some time looking through some of these would be a good place to start.

... still we have package and subroutine...

Perl 5 borrowed its object system from Python and took the approach that class and method are merely syntactic sugar for underlying operations that the runtime translates to symbol table lookups and function invocations anyway.

Even with that in mind, sometimes we write in higher level languages such as Perl to communicate our ideas to ourselves and other humans and not primarily to the computer. (Sometimes abstractions are nice.)

Objects let you bind data and behavior together in a way that permits the caller to not care at all what particular piece of code is being executed. As long as the object conforms to the API that the caller expects, the contents of the object and the way in which it does things are of no interest at all to the calling program.

This leads to programs that are much easier to write and test, and which are much less tightly bound together. Brad Cox, the inventor of Objective-C, called them "software ICs" and that's a good way to start thinking about objects. As long as the connections are what's expected and the outputs match, it doesn't matter which IC you use.

Objects give us a way to do this with software, making it a lot more reusable and dependable.

software investment capital, now there is an idear