In article <[EMAIL PROTECTED]>, Chris Carlen <[EMAIL PROTECTED]> wrote:
> Why would OOP be better? Different is not better. Popular is not > better. What the academics say is not better. Less lines of code might > be better, if the priority is ease of programming. Or, less machine > execution time or memory usage might be better, if that is the priority. Short answer: Increasing programmer productivity is better, and OO frequently accomplishes this. Longer answer: Consider OOP as one tool in the toolbox. It isn't "best" for every conceivable problem, but neither is procedural programming, functional programming, table driven state machines, or any other style of design and/or programming. Each works well in some situations and poorly in others. Having a large number of tools at your disposal, and knowing which ones to use, is a big plus. Let's talk about design versus implementation for a moment, since OO really applies to both, but in different ways. You mentioned state machines, and that is a good example of a design technique. You can look at a problem and convert it to a state machine (design), then implement the state machine in whatever language your computer understands. Over the years, finite state machines have proven to be very effective models because: 1) there are plenty of real world problems that map cleanly to a state machine 2) state machines are easy to implement reliably in most computer languages 3) if you have already implemented a state machine for problem A, then implementing it for problem B is pretty easy - the real work is translating problem B into a state machine OOD is similar. There are a large number of problems for which an object oriented design is a good fit. Once you have an OO design, you then need to implement it, and languages with good OO support make this a lot easier. >From what I have seen, the advantages of OO tend to increase with the size of the project. For example, polymorphism generally lets M clients work with N different kinds of objects by writing M+N chunks of code rather than M*N. When M or N is small, this difference in minor, but as M and N increase, it becomes significant. By combining state and function, objects provide a good means of encapsulating operations and keeping client code independent of lower level code. This is a very big win since it allows for the evolution of the lower level code without breaking all of the client code. As with polymorphism, the benefits of encapsulation tend to increase with the size of the project. Even before OO languages were popular, it was quite common to use some basic OO design in order to increase encapsulation. If you look at almost any GUI framework from the 80's or early 90's you'll find lots of C code with structs that the user is not supposed to mess with, and then functions that take pointers/handles/indexes to those "magic" structs as the first argument. This is really OO design implemented in a procedural language. In fact, GUI frameworks are an excellent example of a domain for which OO has established itself a very good way to model the problem. I could probably spend a lot more time on the merits of OO, but I think if you really want to understand its benefits you need to work with it in a domain for which OO is useful. It is possible that the specific projects you work on really wouldn't benefit much from OO, and that is why you haven't had the "a-ha!" moment. Forcing an OO model onto a problem just for the sake of OO will only result in frustration. Dave -- http://mail.python.org/mailman/listinfo/python-list
