17 replies to this topic

[student_oop]

Can any one knows what are the different Object oriented Techniques? I need a just list of them.

Secondly what is difference between the object oriented techniques and object oriented methodologies.

But question no 1 is more important and if you can name 6 to 7 object oriented techniques then it will be helpful for me.

[WingedPanther]

Your question is very vague. Are you talking about things like inheritance, or things like MVC models and singletons?

[student_oop]

This is the question because I am confused that what are the object oriented techniques are it like inheritance and polymorphism or any thing else. if any one has the answer then plz reply here.

[NatalieM]

I recommend you read "Object Thinking" by David West. OOP isn't so much a set of techniques as it is a way of approaching and decomposing a problem. Techniques are of no use if you don't understand the principles behind, and David West explains them very clearly and in plain english in his book.

[agnl666]

i don't beleive object oriented programming is how you program (it is but), its how you deal with the problem. I'm going to look the book up.

[outsid3r]

I'm starting to think that OOP is not what it seems to look at the beginning. Sure it has it's advantages, but it's totally overused. Many languages provides a lot of OOP abstraction mechanisms, like inheritance, polymorphism, encapsulation, multiple-inheritance, etc. The extensive use of it's abstraction mechanisms can lead to bloat and confusing code, but in the beginning everyone was using it extensively. Nowadays OOP specialists say that inheritance can be evil, and it should be substituted by class composition whatever possible. Java creator, James Gosling, said in an interview that the only thing that he regrets in Java is inheritance, and it should have been substituted by interfaces and composition. Class composition leads to a very relational approach seen in procedural languages. In the end everyone sees that OOP adds a lot of "unnecessarily" complexity, and they try to stick more with procedural approaches to avoid that. In procedural languages you can write real clean code with clean interfaces and implementations, and that's more beauty than lots of classes and abstractions everywhere. Making the code "pure" it's the best way in my opinion.

[marwex89]

outsid3r said:

I'm starting to think that OOP is not what it seems to look at the beginning. Sure it has it's advantages, but it's totally overused. Many languages provides a lot of OOP abstraction mechanisms, like inheritance, polymorphism, encapsulation, multiple-inheritance, etc. The extensive use of it's abstraction mechanisms can lead to bloat and confusing code, but in the beginning everyone was using it extensively. Nowadays OOP specialists say that inheritance can be evil, and it should be substituted by class composition whatever possible. Java creator, James Gosling, said in an interview that the only thing that he regrets in Java is inheritance, and it should have been substituted by interfaces and composition. Class composition leads to a very relational approach seen in procedural languages. In the end everyone sees that OOP adds a lot of "unnecessarily" complexity, and they try to stick more with procedural approaches to avoid that. In procedural languages you can write real clean code with clean interfaces and implementations, and that's more beauty than lots of classes and abstractions everywhere. Making the code "pure" it's the best way in my opinion.

OOP is a programming tool. It's like every other tool; it doesn't fit every task. Don't use a screwdriver to chop wood. On the other hand, a screwdriver can come in very handy at times.

[outsid3r]

OOP can be great then used effectively, the problem is, it's hard to really use it effectively, because of complexity added to it, and in large applications it can be disastrous. Imagine the following situation: You're building a large application in an OOP language, naturally you build lots of classes. In some classes you may think that maybe it's better to use inheritance, or maybe interfacing, or composition. You have lots of choices but you must inevitably take one of them. Maybe in the beginning it looks the most suitable option, but latter you can realize that it was the worst. Now imagine that situation applied to some classes. You start to fix things, and to fix one thing you have to fix another like snowball effect. In the end what you have is a bloated and bad designed code. This surely happens in many software companies, but who cares? the product is sold to people that don't know anything about programming... but that same program can be patched or extended later, and it leads to more bloatness. In the end what you have is a total remake of the same software, and the old one is thrown to trash.
In the other hand, you have procedural languages, that have functions, structures, modules and not much more. You start to design something with that kind of languages and you think directly in a clean interface of functions, there is no need to worry about real models and big abstraction mechanisms that leads to a variety of options, you just make the things simpler and clean. In my opinion, to enforce good OOP programming, the programmer must really know well procedural languages to do not jump blindly to OOP languages.

[marwex89]

outsid3r said:

OOP can be great then used effectively, the problem is, it's hard to really use it effectively, because of complexity added to it, and in large applications it can be disastrous. Imagine the following situation: You're building a large application in an OOP language, naturally you build lots of classes. In some classes you may think that maybe it's better to use inheritance, or maybe interfacing, or composition. You have lots of choices but you must inevitably take one of them. Maybe in the beginning it looks the most suitable option, but latter you can realize that it was the worst. Now imagine that situation applied to some classes. You start to fix things, and to fix one thing you have to fix another like snowball effect. In the end what you have is a bloated and bad designed code. This surely happens in many software companies, but who cares? the product is sold to people that don't know anything about programming... but that same program can be patched or extended later, and it leads to more bloatness. In the end what you have is a total remake of the same software, and the old one is thrown to trash.
In the other hand, you have procedural languages, that have functions, structures, modules and not much more. You start to design something with that kind of languages and you think directly in a clean interface of functions, there is no need to worry about real models and big abstraction mechanisms that leads to a variety of options, you just make the things simpler and clean. In my opinion, to enforce good OOP programming, the programmer must really know well procedural languages to do not jump blindly to OOP languages.

What you outline here is a common result of badly planned OOP code. Coding using a procedural paradigm might be easier, but with experience and careful planning, OOP can be a very useful tool. I feel that OOP helps combine similar concepts into logical structures easier than procedural code, which leads to cleaner code which is again easier to understand and maintain. It requires more planning and design from the programmer, but that might not be such a bad thing. Coding without thinking likely leads to disaster anyway.. :)

[outsid3r]

I agree with you, but then you say "procedural paradigm might be easier", i would rather say, it's more clean, hence, leads to cleaner code naturally. Yes, OOP it's very powerful then carefully planned, i totally agree. OOP has implicitly some big wins over procedural, like generic and meta programming. You can design really nice generic containers and other kinds of objects that are naturally related to generics. OOP it's just "dangerous" then used by cheap programmers, and some others like to abstract everywhere, and make heavy usage of abstraction mechanisms... that's when everything fails or bloats. My advise to any OOP programmer is to do not exaggerate on sub-classing and specially on inheritance. Then we abstract and divide less, code cleanness comes naturally. I like to download sources to check how big applications are structured, and i have seen both really nice OOP programming, and really monstrous code.

[marwex89]

I agree with you, but I'm not sure if we define "code cleanness" equally. Procedural programming leads to fewer concepts that have to be digested, but that does not necessarily mean the resulting code will be cleaner. That would depend on the situation.

Downloading sources is a good idea, though the quality certainly varies! lol

[outsid3r]

In procedural programming everything leads to structures and a set of functions to operate with that structure, and in the end you get a module, something that models an object cleanly... it really goes straight to the point. Some people say that procedural can be bad for large applications, i totally disagree, we can check lots of very large libraries and applications beautifully written in C. The thing is, with procedural, we don't have to worry about large abstractions, and we automatically focus on real important things beneath all abstraction, in OOP, we focus on abstraction and sometimes we forget the real important things.