ArtsAutosBooksBusinessEducationEntertainmentFamilyFashionFoodGamesGenderHealthHolidaysHomeHubPagesPersonal FinancePetsPoliticsReligionSportsTechnologyTravel
  • »
  • Technology»
  • Computers & Software

Object Oriented Programming (OOP) - Enemies of Object Orientation

Updated on July 3, 2013
Who Are the Enemies???
Who Are the Enemies???

Article Understanding Prerequisite - Understanding of Programming and basic understanding of OOP

Object Orientation - Even after so many years of being introduced and being used extensively since, many times you'll find code which does use classes, objects, inheritance etc. but is not actually object oriented. Is it that the object oriented paradigm is tough or there exist certain enemies of object orientation?

Stress on Language Constructs

The learning material which is easily available, including most of the reference books too, stresses on language constructs instead of object orientation. Sometimes it is understandable too that in the beginning when only one step at a time is being taken, certain illustrative examples are not focusing on Object Orientation, but will only discuss the syntax etc. But later on also, when the reader has sufficient understanding, no attempt is made to undo the prior incomplete understanding.

A classic example of this is the illustrative example of Runtime Polymorphism (can be found in many C++ and Java Books and tutorials) - where in a for loop different shape objects are assigned to a base class pointer/reference, and the area function of each is invoked. What's the point of assigning the objects to reference when the object itself is available? It's only to illustrative what can be achieved, but in what situation will it be effective, powerful is left to imagination of learner. As a result, most people are unable to appreciate the true power of polymorphism for a long time.

Available good text too Advanced?

Do you think that the authentic guides on Object Orientation are meant for advanced users, or they are difficult to follow for beginners?

See results

More enemies feature in Part II

I'm planning to add more enemies of OO in the next part of this article. If you have faced/can think of some other enemies of Object Orientation, and/or how to fight these enemies, please share in the comments section.

Fighting the enemies

Pointing out the problems is one thing, working on solutions is another. Among the incremental steps towards the goal of fighting the enemies of Object Orientation is, easy to understand technical articles which focus on OO along with other concepts. Here is a link to one of such series, C++ Programming Concepts.

Online Articles which are Object Disorienting

Seriously now, most of the new programmers (for that matter even pros) simply turn to Google when they are stuck. What do they find out? A lot of articles written by people who themselves don't understand the core concepts of object orientation.

On many article writing websites, to get hold of some easy money, sadly, many people write the complete source code of programs which are supposed to be standard assignments. While this hampers the learning of the students, the incorrectly written programs set the wrong concepts firmly in place.

As an example, I once saw a program for swapping two numbers in C++. The writer used two different classes to hold two numbers, created one object each of the classes and swapped the numbers, which were public data members, directly from the main function. That was major.

Unfortunately, the code would work fine, and thus most of the beginners won't be able to ask these questions from themselves after reading the code.

* Why create two identical integer classes with different same names, when one class with two objects would suffice?

* If you're accessing the numbers directly in main program (making them public), without any getters/setters, why encapsulate them in a class? Why not use the integers directly?

Such code can however be great case study if you're trying to tell your students/trainees/colleagues how not to write code which is not object oriented despite of the use of classes and objects. The questions like above can set the thinking pattern which will help to drive towards object orientation.


    0 of 8192 characters used
    Post Comment

    • anusha15 profile image

      Anusha Jain 6 years ago from Delhi, India

      @ Gorav: Thanks so much, I'm really honored. :)

      @ Alesh: Thanks for a detailed and thoughtful comment Alesh, you bring up some really interesting points.

      @ Naveen: I second your thoughts, like so many other times. I'll definitely include some design examples to illustrate. Thanks for your generous comments. True designing is as much art as it's science, and there are definitely very few people who appreciate it. That's another enemy of technology in general, and also of OOP. Thanks again for stopping by and commenting.

    • profile image

      Naveen 6 years ago

      Well, I can expect this series from someone whose first love is C++. Only if the designer is looking for elusive beauty in design, shall he/she discover true power of OO.

      It would be good if you can share some beautiful and ugly designs to make reader appreciate difference and apply OO properly.

      Hope that your knack for defining beauty in poetic language make people understand true designing is as much as art as it is science.

    • profile image

      Alesh Kotia 6 years ago

      Indeed you have focused on very important fact, which can be noticed in source codes. Further if try and dig the samples of code, articles and examples then what common pattern can be observed with respect to Object Orientation are seldom use, superfluous at times and even incorrect.

      The reasons for not using OOPs correctly or not using it might be a long list and you mentioned some of them as well. But I think the biggest enemy of OOPs is the gap between OOPs and the understanding of OOPs itself. The one which is theoretical definitions only and the one which should be practically used at the right place and on right time, there is a huge difference or it is not wrong to mention that the lack of later one. Most of the developer who write code in different languages are aware of OOPs but lack in why OOPs ? and why not procedural way of programming ?

      Only declaring a class and creating their object to access it is not OOPs. If a design should be simple then what is reason behind making it simple. Why do I need to hide my data ? Defining a clear and discrete responsibility for a class, why I can't have a single class to address all my needs.

      These are few instances which made we think that the enemy of OOPs is the fundamental practical knowledge to use the principles of it.

      For OOPs I would say that If drill down to it and observe then I feel all principles of OOPs are nothing but common sense

      but often the common sense is not so common!!

    • anusha15 profile image

      Anusha Jain 6 years ago from Delhi, India

      Hey Giselle, I didn't expect your comment on this hub, so it was a pleasant surprise, even I didn't know you used to program long back :)

      Impressive Array of Talents :) hmmm, thanks so much. Programming has been bread and butter since 2005. I recently quit my job (was working as Technical Lead) for pursuing my dream, but I don't think I would be able to quit coding/technology - it's like cycling for me now :)

      You're right, good code and bad code - and with OOP the multiplicity of choices increase and so the scale of grey between good and bad widens. I'm planning to start some stuff like "layman programming" - and your suggestions are welcome.

      By the way, Thanks so much for answering the ecards question. You won't realize how important that answer was for me. You gave me a new perspective - very different from mine, intriguing and very very useful. Just one answer to that question, and it was worth 100s :D I'm glad we get acquainted here at HP.

    • profile image

      Giselle Maine 6 years ago

      Wow Anusha, I had no idea that among your already impressive array of talents that you program in an OOP language! I was very impressed.

      I don't program in OOP (or at all now for that matter - I hung up my 'programming hat' years ago back in the days of Pascal, Ada and Lisp). Now it's all a mystery to me. I definitely enjoyed reading your article even though my current lack programming expertise meant that I was unable to appreciate many of the distinctions you brought up.

      But back when I was programming, I did notice that it was possible to write either 'good' or 'poor' code to do the same identical job.