Perlmonks oop

http://www.perlmonks.org/index.pl?node_id=318257 The definition of OO is unclear: Do we allow single-dispatch? Multiple-dispatch? Single-inheritance? Multiple-inheritance? Do we have prototype-based inheritance? Some class-based model? Something more sophisticated (like Perl 6's roles)? Is everything an object? Do we call it object-oriented if you have lots of accessor methods? For every one of these choices I can name languages and OO environments that made that choice. I can name ones that didn't. I can find people who argue that each option is the "right" choice. Yet these choices profoundly alter what it means to be "object oriented". They alter the kinds of strategies that you can use. And, as indicated in the SCICP quote, each combination is unsatisfactory in some ways.

Yet despite this, you can find plenty of people who are quick to argue that something is "not real OO".

And now allow me to address each of the original points in turn: Everything in the real world is an object (class is the collective abstraction of object). I think that I've argued that the real world isn't. And further, the "world" inside of our programs necessarily has a lot of stuff which has very little to do with the real world. Programming is the way used to resolve real world problems. First, my experience is that programming is more about communication and understanding between people than about what the program is supposed to do. Second, programs deal with a world at several degrees of remove. Third, I find that it is better for programs provide tools, not solutions. Oh, computers can apply the simple rules, but you have to leave complex problem solving to people. We're better at it. In order to be able to resolve the problem, especially through a machine, you need a way to (observe and ) describe the entities concerned, and the process to resolve the problem. An ongoing tension in good design is how much you can leave out of the model. For example, look at spreadsheets. Myriads of problems have been effectively solved with spreadsheets (often by people who didn't know that they were programming), even though spreadsheets are innately horrible at really modelling any of the entities which those problems were about. OO is one way to describe real world (or to be precise, to perceive it and then describe it.) This I mostly agree with. But I would point out that every variation of OO is a different way to describe things (both real and invented), and I also claim that none of those ways are completely satisfactory. And to address the point that started all of this, anyone who really believes that There is simpy no such thing as "useless OO". should read Design Patterns Considered Harmful. Yes, adding OO can not only be useless, it can be actively counter-productive effort.

design patterns
http://www.perlmonks.org/index.pl?node=Design%20Patterns%20considered%20harmful I've learned the hard way over the past several years that when you see the Design Patterns book show up on a junior developer's desk, you need to watch them very, very carefully for the next six months. Otherwise, you'll turn around one morning and discover a set of Builder pattern classes, flanked by Facades, sitting in the middle of what should have been a simple object model. Something about that book tickles an urge to build. It is like a box full of shiny power tools, all crying "play with me! use me!" Patterns start popping up like warts, complicating otherwise simple regions of code. And unlike ordinary messy code, this is messiness at the structural level. It costs a lot more to undo. And yes, this can even happen in Perl-based systems. I really do like the book. It lays out a taxonomy of reusable design and implementation elements that I've reached for, judiciously, many times. Lots of problems are solved quite flexibly using a Strategy pattern. Template methods can reduce coupling. In good hands, design patterns are a powerful tool. But the chaos in that book's wake caused by immature developers can be enormous.

So my recommendation is that if you see Design Patterns appear on someone's desk, and you're not confident in their judgement, start checking in with them more often. Ask them how they like the book, and where they're seeing opportunities to use design patterns. Then talk them out of half of those "opportunities". Your code base will thank you.

And if you're not sure you're ready for the book, I say go for it. It's a great book. Just watch yourself. If you feel yourself making excuses for going out of your way to use a design pattern, stop, take a deep breath, and ask someone you trust for advice.

links
Design patterns, Noun , Nouns and verbs oop