Discussion on:

Poll: Is object-oriented programming too complicated?

... is that programming is an inherently difficult process and cannot be simplified beyond a certain point. Are we at that point with OOP? Possibly not, but I don't think we're too far from it.

Maybe what's "broken" is not OOP, but the "patterns" meme. Sometimes I think we try too hard to force things into a standard pattern rather than building an appropriate one for the problem at hand from first principles. Trouble is that needs a more pure computer science approach than most programmers are familiar or comfortable with.

Personally I think to be a good programmer, you need to have an inherent love of the esoteric and the formal (read mathematical) approach to computing.

Many instructors teach OOP is a way that's too complicated, and a lot of new programmers design systems are way too complicated. OOP can be very simple, and understanding even its most basic concepts goes a long way to making code more discrete and decoupled. The more advanced concepts (e.g., the more complex kinds of polymorphism) are rarely useful anyway.

Some languages also make it way too complicated. C++ is a great language, but the way it composes classes and inheritance has always confused me. It's been years since I've worked with PHP, but (at least its early) class/object structures were hard to read. C# and Java on the other hand are very clear in their OOP implementations.

OO after all came out of the complexities of attempting to describe over-complicated designs in procedural code.

Is OO too complex? No.
Is applying it in environments where everything but the existing code is allowed to change, complicated? Most definitely....

I wished for the option Yes - but if your project scope is large coupled with longevity it's an important paradigm to use.

There are other paradigms such as Logic, Functional, OO Based and Modular that have their niche. E.G. I wouldn't suggest OOP for an embedded project as it would be like swatting a fly with a nuclear powered sledgehammer.

OOP is inherent in good programming. I have 26 year of programming experience and have seen theory come and go. The basic concept of breaking code into manageable pieces is a solid fundamental practice and the thought of reusing code that has been proven is also sound. Where OOP supporters get off base is when the theory overshadows common sense and experience in evaluating programmers. The theory is never more valuable than either of these assets. Design Patter = Simpleton... lol

I don't know if they teach this anymore, but when I was in CS 20 years ago we learned about a method of programming called "abstract data typing." The idea was you have some data structures, each of which can be instantiated multiple times, and you have sets of procedures that work on those data structures, with each set of procedures assigned to each data structure type. We used to use this concept in C to make complex systems a little more manageable.

Modern "OOP" languages accomplish this by having the programmer set up classes with member variables (the data structures), and associated procedures. Each procedure has an implicit "this" pointer/reference, so that when it's called, the object that references the procedure (I'm talking syntactically, not how it actually happens) is passed into the procedure automatically, so that it can access the structure's variables without the programmer passing in the structure explicitly every time. In addition, there are compiler checks to make sure the type tags match up (a method of making sure you don't call the wrong procedure for a data structure), and that access constraints are enforced on both structure variables, and procedures. The language makes it look like everything is one happy unit, but it's really not. It's an abstraction on top of the ADT concept. The problem with this scheme is while this helps manage complexity some (which is more attributable to an extra layer of scoping than anything else), you're not dealing with "objects" in the best sense of the concept.

In one better conception, the procedures are somehow directly linked with the information they manipulate. In other words, there's no need to have a type bind them together, because they are bound together implicitly. Secondly, procedures represent a "protocol" for the object, and anything that can work with that protocol can work with it. In effect the object's protocol (interface) is its type! This allows more flexibility in object relationships, because any method that can work with a protocol with one object can work with any other object that conforms to the same protocol. Translating this into "type" parlance, this means that any object can span multiple "types" just by conforming to multiple protocols.

By adhering to this "protocol" concept, you isolate different implementations, because all a method ever cares about is the behavior of the protocol of another object.

What I've seen with modern "OOP" languages is programmers have to add in a LOT of cruft just to get to something that approaches this concept, creating abstract interfaces, which allow looser binding to object types. The problem with this scheme is it assumes that type tags can substitute for the notion of a protocol-type. They can't, really.

Secondly, the static typing we have in our languages tends to get in the way. This is the reason "OO" languages developed templates and generics, and later a "dynamic" type. They're all "escape hatches" from static typing. The reason they were developed is people want to express a concept more generally, while keeping the expression succinct. It seems to me it would be better to make type constraints optional, something that can be added in at will, once a design has been tested and accepted.

Further, most programmers I've seen don't even bother with objects that much. They use the APIs that come with the language, using some notion of objects, but they just write straight procedures for their own code, practically eschewing any notion of objects, except where they're convenient.

A point that was made earlier about programmers making patterns into a religion, rather than an interesting engineering approach to a problem, is a good one, though I wouldn't attribute this just to OOP. It's really an issue that technologists get fascinated with technology. Secondly, a lot of us dislike change. This gets expressed as a desire to make a system "fit" a standard design language (a set of canonical patterns). You see this in programming language choices, too, which is another version of the same thing. This way, programmers versed in the patterns can refer to "this is a 'that' pattern," and such, and everyone can nod and know what you're talking about. No one has to explain what's really going on, because just by referring to labels, everyone gets the idea quickly. The problem is our design language is not complete. So instead we make do with an incomplete language, because "everybody knows it."

It's not that OO is too complicated. I think OO is good for some situations, but not all. The real problem is that our notions of OO, and our tools for accessing that concept, not to mention our notions of design, are really poor.

I used to program in C, and found it difficult to keep program complexity manageable in a medium or larger application. Then I discovered C++ and realized that I was trying to force C to do a lot of things that C++ does naturally. Encapsulation, inheritance, polymorphism (virtual functions), interfaces, etc make life bearable and greatly help reduce complexity.

Patterns are a wonderful thing, because they allow you to not reinvent the wheel and allow you to do architectural design of code at a much high level. However, they don't have anything specific to do with OOP. You can use patterns with any language.

My concern with this topic is that it implies that by dumping these things you can write better code faster, and that is not true. You can write worse code faster, and spend much longer repairing bugs, so that in the long term you spend a lot longer producing an inferior product.

The only exception is with small programs, because a lot of infrastructure is not needed. If everything can be written in a few functions then a procedural design can work better.

or, as it has been said before, it's the management's fault if it is.

better question, is the object oriented approach the best one for this job?
probably 80% of the time, NOPE it is NOT the best way to go.

I judge a programming pattern by how easy it is to follow when you're the programmer responsible for taking over code that was built by someone else. Others have commented that there seems to be a growing number of patterns. That's not inherently bad (choice is good). The critical criteria is how intuitive is the pattern to follow if you're looking at one for the first time. Dependency injection has its place but sheesh, it can be difficult to trace the logical paths forward and backward through the code.

I've seen this everywhere, programmers claim they know OOP "very well" but at the end they still deliver poor quality procedural code with sub-routines having 3000 lines of code, bad logic decomposition and very poor naming convention.

Pick the method and write the code to best solve the problem.
Employers never pay you to write perfect OO code, they pay you to write working code as quickly as possible.

Yeah, I partially agree. The thing I had to bite the bullet on is that sometimes the business just does not have the dollars and hours to make something properly. They need to get to market and you don't even get design time.

However, in these circumstances the business often pushes it beyond the pale. "There's never time to do it right but there's always time to do it over", when they have to. That's what I always find myself battling against, is getting enough engagement from business drivers to properly balance the initial effort against the product lifetime. I don't think business will ever understand what it takes to program and what length of time is reasonable, but I wish they'd start to understand that they need to talk about it and trust their technicians to give good practical judgements. Depending on management engagement the software product can end up costly and unreliable, or a good balance of maintainability and function.

However, there are some programmer mistakes that don't get an excuse. Like naming consistency. Some practices don't take extra time to perform, they just require an alert and diligent attitude.

But this is now off-topic. OO is one of those things that most of the time shouldn't take extra time. Yes, you can get the encapsulation wrong and not have time to re-write, but it will still be OO. Everything should be encapsulated from the ground up. I don't really know how to program any other way.

What could be more complicated than a Big Ball of Mud? The basic concepts of OO are simple. Separation of concerns, abstract your data layer, keep your business logic outside of your view, etc. MVC is a very simple concept in practice: Keep your business logic, your model and you presentation separate.

Using OO design SIMPLIFIES your code! I wouldn't want to code without it.

Perhaps a definition of what the author means by "OOP" is needed. It seems commenters have particular programming languages and methods in mind when they refer to OOP.

this is way too complicated for the real world. ... who said so?
Have you ever created a real world application?
Where does this non-sense article stem from?
I give up...

More than 20 years ago I was working with objects which existed in an object library. The difference is I was not working in a GUI environment, although I was working on developing one.

OO has nothing to do with GUI. Otherwise I agree. OO is not new. OO support in languages is newER than OO paradigms and constructs. I used to program OO in C. But that's why I can't understand this topic. OO makes things SIMPLER not more complicated. That's why programmers were using it intuitively, that's why explicit discussion of the methodologies arose, and that's why it became popular, and that's why there's not really any non OO approaches any more. For instance, even functional approach is constructed in OO fashion.

I never said OOP is part/parcel of GUI, and if I implied it, my bad. I think though, from experience, that MEllenials seem to believe OOP is a new idea sprung from GUI.

I voted no because in concept it is not, but in practice... well we have horrible languages like C++ combined with non-agile diagrams like UML.

OO really dates back to the 1950s when some smart guy at Burroughs put code to interpret data together on a tape on the B220 system. Alan Kay picked up on this (and later coined the term object oriented).

The first real OO language was Simula by Dahl and Nygaard, being an extension of ALGOL (that immediately makes it far better than C++... ALGOL was done by many people including John Backus who developed FORTRAN. They carefully avoided the pitfalls of FORTRAN, gave .EQ. the neater mathematical '=', and assignment ':='. C forgot these lessons and put FORTRAN's junk back in, since programmers believed that "confusion of concept = efficient code", and anything with clean concepts must be "training wheels for idiots", an attitude which I think is finally dying).

Fundamental to OO is the concept of modularization based on a 1970 CACM paper by David Parnas. Parnas has since pointed out that modularization is important, but more so is the design of modules, that is the interfaces between them. Parnas coined the term 'information hiding', which many simplistically interpret as meaning get and set routines, but really I think Parnas meant 'implementation hiding' and hiding of certain assumptions to ensure loose coupling. Interfaces should be designed so modules go together like a tight-fitting jigsaw puzzle, but loosely coupled at the same time. The test is that a completely different module should be able to replace another module and the system still works.

http://sunnyday.mit.edu/16.355/parnas-criteria.html
http://www-sst.informatik.tu-cottbus.de/~db/doc/People/Broy/Software-Pioneers/Parnas_new.pdf

Parnas says OO has really been a disaster since many believe they are writing good code by just writing in an OO language.

Later the concept of Design by Contract (DbC) was developed and put in the Eiffel language by Bertrand Meyer. Along with Smalltalk, Eiffel is at the pinnacle of OO languages, but DbC is an important concept to specify clean module interfaces. Most class interfaces just express the static properties of a module, what routines exists and parameters and results are expected. DbC extends this to the dynamic properties of a class, what are the valid states and refine further the domains of parameters and results.

DbC is Test-Driven Development (TDD) on steroids. TDD results in rather random tests separate from a module from which a module is then developed. However, DbC says this is an essential part of a module's specification, and automatically provides testing. All you need is then a small test harness. Thus essential parts of a module specification are in the module itself, not in a separate test module as with TDD.

Some think that OO design is doing UML diagrams. UML is just too heavy and too light at the same time. It is too heavy for most development. It really is against agile development. But it is too light, it is not formal enough for serious and critical development (despite the fact it looks serious).

That is where DbC is just right. It is built into a programming language (Eiffel) and can be used (with a little or more effort) in other languages. DbC says that a program written in an executable language IS your specification document. That is really agile.

Using the jigsaw analogy, most static interface design is like having the pieces fit together, but there is no check that the resulting picture makes sense. DbC helps make sure the resultant picture also makes sense and this is a very important aspect that most development techniques ignore.

So DbC is light and agile.

However, DbC is also formal. It formally captures exactly what the interaction between modules should do. It is based on formal concepts like Z, and Hoare logic {P} S {R} (if precondition P is met, after code S is executed, result R will hold).

So if I consider technologies like C++ and UML I would vote yes OO is too complicated, but OO well done with better languages and DbC with the original thinking of David Parnas makes me vote no.

I really enjoyed reading your comment. So well argued!

Re. the "OO tape"

I've heard Alan Kay tell this story. He said he saw this while he was in the Air Force. Most tapes just had data on them, and each set of data came in a different format. Each tape would come with instructions for how to read it, and programmers would have to write a program to read the tape. This involved a lot of revision, as you can imagine. Kay said one enterprising enlisted man (he knew the programmer must've been enlisted, because officers did not program) came up with a scheme to do away with this. He put executable routines for reading from, and writing to the tape, at the very beginning of the tape. These were loaded into standard addresses in the computer's memory. Any programmer knowledgeable of the machine would know where these addresses were. The tape required no instructions for how to read the data format, because the routines would do that for the programmer. All the programmer had to do was use the routines. In fact they could write their program once and reuse it for subsequent tapes from this same individual, because his tapes always used the same scheme.

Kay said he didn't know who created these tapes, though. He didn't talk about it being made at Burroughs. Do you perhaps know more about this story?

The basic concept this programmer got was that code is a formalized executable specification. So rather than writing out the format spec., knowing that all anyone was ever going to do with the tape was read and write to it, just encode the spec. into the actions and be done with it! Yes, modularization was an important part of it. You make a good point re. DbC. However, another part that has been almost completely neglected in modern OO systems is the idea that the actions were serialized with the data! We have a rather bad analog to this with stored procedures in databases, but there are problems with it in terms of no encapsulation, no revision control (for code), and with some exceptions no debugging facility. It feels sad, because I feel like with RDBMSes we almost have the necessary ingredients for an implementation of Smalltalk, but hardly anybody sees that. The only ones who've realized it are Gemstone (now a part of SAP).

Yes, I glossed over the story a bit of the B220 tapes. The source for this is Kay's fascinating Early History of Smalltalk:

http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html

I don't think Kay himself knows exactly who came up with this. If you have heard a speech on it, you probably have it more first hand than I do.

USAF must have been different to the Navy since Grace Hopper was a programmer and an admiral! We are still stamping out this same notion of officers don't program with managers who think they don't have to program. But managers are a dying breed, a sad vestige of the industrial revolution, but that's another story!