I prefer OOP over top-down or state programing. I just think in OOP. What problems are you having? It just takes learning how to think the right way and it is pretty easy.
theTroll
theTroll
I find that it is generally easier to write very small simple programs without OOP, but for anything that's beyond just a small test or practice, OOP becomes a major help at keeping things organized and easier to manage, even as the project becomes pretty large.
But it's still easy to make atrocious OOP designs that break at every turn and are nightmares to manage. It takes practice and experience to design a good program that scales well, OOP or no OOP. <personal_opinion>Though I still think OOP helps out more than a procedural style (usually what OOP is contrasted with) when designing large projects.</personal_opinion>
But it's still easy to make atrocious OOP designs that break at every turn and are nightmares to manage. It takes practice and experience to design a good program that scales well, OOP or no OOP. <personal_opinion>Though I still think OOP helps out more than a procedural style (usually what OOP is contrasted with) when designing large projects.</personal_opinion>
Quote:Original post by AgonyAgony is right.
But it's still easy to make atrocious OOP designs that break at every turn and are nightmares to manage. It takes practice and experience to design a good program that scales well, OOP or no OOP.
I don't think OOP is any more or less easy than any other high-level programming style. It's well-suited to certain problems, adequate for others, and in some cases is a bit rubbish.
As ever, it's simply a case of practicing, and of learning how best to use the tools which are available. OOP is certainly a very widespread paradigm, so you probably ought to get used to it.
Quote:Original post by Zaku
is non OOP generally easier then OOP, cause in java, OOP is giving me a headache :(.
Java is Object Obsessed Programming. This is counter-productive.
Object Oriented Programming -- using objects where they make sense -- is a useful timesaver if you've got a good grasp of the concept, and it's pros and cons.
Proponents of OOP agree that it is very useful. Detractors of OOP agree that no one can really agree on what OOP is.
Quote:Original post by MaulingMonkey
Java is Object Obsessed Programming. This is counter-productive.
Object Oriented Programming -- using objects where they make sense -- is a useful timesaver if you've got a good grasp of the concept, and it's pros and cons.
Very well said. OO should not be used all the time, not everything can be objectified.
Degra
Quote:Original post by Zaku
is non OOP generally easier then OOP, cause in java, OOP is giving me a headache :(.
Define easy. Time to write? Time to manage? Ability to understand? Ability to explain to others? Modularity? Resusability? Features?
Quote:Original post by MaulingMonkey
Java is Object Obsessed Programming. This is counter-productive.
Object Oriented Programming -- using objects where they make sense -- is a useful timesaver if you've got a good grasp of the concept, and it's pros and cons.
That's just plain bad advice. You're implying that OOP should be used only when its useful, and functional procedural programming elsewhere? You should strive for code consistency, and mixing paradigms is possibly the worst thing you could do in that area. Just because C++ and other high-level languages ALLOW you to mix programming paradigms does NOT mean it's a good idea.
[Edited by - skittleo on March 4, 2007 6:08:23 PM]
Quote:
That's just plain bad advice. You're implying that OOP should be used only when its useful, and functional procedural programming elsewhere?
No, that's very good advice. Why, you're implying that OOP(or any other paradigm) should be used everywhere, even when it's not useful?
Meh... People have so mixed ideas about what OO is, that personally I don't care any more. Most think that the difference between OO and procedural is the difference between foo.proc() and proc(foo). I won't even try to argue that,in many cases, proc(foo) enhances encapsulation(Scott Meyers). I just try(as much as I can) to keep some important design principles. Whether I do it with classes or non-member functions or templates or anything, I don't really care... Even SC++L mixes different paradigms, like OO(say,std::list),"procedural"(say,std::sort) or functional(say,std::for_each).
Quote:Original post by mikemanQuote:
That's just plain bad advice. You're implying that OOP should be used only when its useful, and functional procedural programming elsewhere?
No, that's very good advice. Why, you're implying that OOP(or any other paradigm) should be used everywhere, even when it's not useful?
Again, code consistency. I'm only arguing the case of OOP and Procedural programming, and obviously everywhere is probably an ideal, but nevertheless it is still extremely important. If this needs explaining, let me quote Enterprise Application Development with Visual C++ 2005:
Quote:The importance of a coding standard is often downplayed by developers and incorrectly regarded as an unnecessary complexity. This is fundamentally wrong. Quite the contrary, following a rigid coding standard is a necessary prerequisite for developing quality code because coding standards enforce consistency, which is an essential component of making comprehension of logic represented by the source code easy and transparent.
You can tell a lot about a developer by looking at his code. If the code is inconsistent and messy, the developer is undisciplined and disorganized regardless of how brilliant he may be. In the course of my IT career, I have met many software developers who were sharp and quick thinking but produced terrible-looking code. Even though they produced code that worked, it was incredibly hard to comprehend by anybody else but the original author. On top of that, such code frequently contains internal inconsistencies and hidden interdependencies, which usually result in unexpected errors arising from subsequent code modification conducted even by the original author himself. What's worse, since it is virtually impossible for another developer to comprehend such code, the lack of coding standard creates dangerous dependence of the project on the original code authors, which may or may not be available for further software development or maintenance tasks. Therefore, rigid adherence to a coding standard is essential for success of a software development project especially when a team of developers is involved. Consequently, an average but disciplined developer is ultimately more valuable than a brilliant yet undisciplined one. In the end, it is the simplicity and clarity of code and its underlying logic that ensures the project's success.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
