Wanted: The perfect OOP application
Author
So, those of you who know me well know that I'm a fairly good programmer, and have more than a passing familiarity with OOP. But in all the medium-to-large software projects I design, I tend to employ an amalgam of OOP and procedural programming. This will undoubtedly get me torn to bits by OOP zealots one day, but it works for me so I continue doing it. Obviously, though, others take a more hardline and pure approach, and it seems to work well for them; so it's something I should at least try. The problem is, I just don't have the time or the willpower to design and implement an entire medium-sized software project in pure or mostly-pure OOP just to satisfy my curiosity. Ideally, I'd spend time looking over the code of someone else's application, but I have no idea where to look for an application that embodies the best of the pure OOP paradigm.
So I'll throw it out to you guys: where can I find an application whose source code is really well-designed OOP, without concessions or compromises? Preferably a game, but anything'll do as long as it isn't TOO boring.
Oh, and this isn't an April Fool's joke. It seems to be obligatory to add that to every freakin' message I post today.
I am no expert, and probably wouldn't know a perfect OOP app if it bit me in the ass.
That said, my first thoughts go towards something written in Java, as that tends to harbor programmers with strict OOP tendancies.
Narya is a public game framework used in the commercial MMORPG Puzzle Pirates. I cannot speak to it's OOPness, or anything else really; just that it exists, and is likely to fit your requirements.
That said, my first thoughts go towards something written in Java, as that tends to harbor programmers with strict OOP tendancies.
Narya is a public game framework used in the commercial MMORPG Puzzle Pirates. I cannot speak to it's OOPness, or anything else really; just that it exists, and is likely to fit your requirements.
Author
I'm a little leery about looking to frameworks or libraries. Good OOP frameworks and libraries abound; I've written a few of them myself. But I'd like to see something with client code as well, to get the whole picture.
OGRE
(Object oriented Graphics Rendering Engine? Something like that.. )
Personally I found pouring through its code quite informative. It's got good documentation as well.
(Object oriented Graphics Rendering Engine? Something like that.. )
Personally I found pouring through its code quite informative. It's got good documentation as well.
I'll recommend that you not beat yourself up for understanding that there is more than one way to write code. Pick up a copy of "Multi-Paradigm Design for C++" by James Coplien. If you are attacked by OO zealots or functional zealots or any other form of purists, slap them across the face with the book until they withdraw.
With that said, practicing multi-paradigm design requires a mastery of multiple techniques instead of just one. Quoting the Functional Programming Koans:
'The Koan of Side Effects
A student of FP came to Daniel de Rauglaudre and asked how to achieve FP Nature. Daniel replied, "to achieve FP Nature, you must learn to program without side effects and other imperative features". So the student went away to learn how to program in this style. He studied very hard so he could rid his programs of references and for-loops. He struggled to only use let bindings and let rec loops. One day, in order to find inspiration, he was studying the code of the Masters, and in reading the source of Camlp4, he saw a number of uses of references and for-loops! He rushed back to Daniel de Rauglaudre and exclaimed, "How can you tell me not to use imperative features when you use them yourself!" Daniel measured the student carefully in his gaze and replied, "But I already know how to program without side-effects." At that moment the student was enlightened.'
With that said, practicing multi-paradigm design requires a mastery of multiple techniques instead of just one. Quoting the Functional Programming Koans:
'The Koan of Side Effects
A student of FP came to Daniel de Rauglaudre and asked how to achieve FP Nature. Daniel replied, "to achieve FP Nature, you must learn to program without side effects and other imperative features". So the student went away to learn how to program in this style. He studied very hard so he could rid his programs of references and for-loops. He struggled to only use let bindings and let rec loops. One day, in order to find inspiration, he was studying the code of the Masters, and in reading the source of Camlp4, he saw a number of uses of references and for-loops! He rushed back to Daniel de Rauglaudre and exclaimed, "How can you tell me not to use imperative features when you use them yourself!" Daniel measured the student carefully in his gaze and replied, "But I already know how to program without side-effects." At that moment the student was enlightened.'
To help understanding, I'll also quote the answer to the Koan of Side Effects:
'The Koan of Side Effects
The enlightenment that Daniel helped the student achieve was this: If you do not learn to program without side-effects, you will not learn when to program with side-effects. Some functional languages, like Haskell are functionally pure, and do not offer any imperative features. However, OCaml (and ML) provides a mixed paradigm where you can program in both declarative and imperative styles, because sometimes it is convenient to do so. Once you have achieved mastery, you will know when it is appropriate to take advantage of that convenience.
If you are coming to FP from an imperative background you should remember that now you need to learn to think and do things a little differently than before. Until you feel comfortable doing so, it's best to avoid your old habits altogether, if possible.'
The enlightenment of the koan applies equally well to the OO vs Procedural debate. If you do not master OO, you will not know when it is genuinely appropriate to use procedural techniques.
'The Koan of Side Effects
The enlightenment that Daniel helped the student achieve was this: If you do not learn to program without side-effects, you will not learn when to program with side-effects. Some functional languages, like Haskell are functionally pure, and do not offer any imperative features. However, OCaml (and ML) provides a mixed paradigm where you can program in both declarative and imperative styles, because sometimes it is convenient to do so. Once you have achieved mastery, you will know when it is appropriate to take advantage of that convenience.
If you are coming to FP from an imperative background you should remember that now you need to learn to think and do things a little differently than before. Until you feel comfortable doing so, it's best to avoid your old habits altogether, if possible.'
The enlightenment of the koan applies equally well to the OO vs Procedural debate. If you do not master OO, you will not know when it is genuinely appropriate to use procedural techniques.
Your code is basically about objects talking to each other thru public interfaces while doing detailed stuff internally. Then you have objects that deal with polymorphic objects ie. who needs to know what and to what extent. Then you have whole/part objects where one object tells the whole what to do and it does it thru the use of its parts. There are two levels of algos. The one done thru public interfaces by objects talking to each other and thus solving a problem that way and the other algos which are internal to the objects. Think of the "talking" part as the highest level procedural function that has several lower level functions that describe the algo.
DoSomeAlgo()
{
DoFirst();
DoSecond();
DoThird();
}
Actor is an object that initiates DoSomeAlgo() then objA sends message go objB saying DoFirst(), then objB sends message to objC saying DoSecond() then objA sends message to objC saying DoThird().
That's why it's important to have collaboration diagram done first so that you can define your algo with objects and it's also why this is only the first part since at this time you might not know the internals of DoFirst() and the others. Once you figure out the internals they might change your public interface of existing objects. Simply because you have now more details to work with than before. Use cases are tied to the collaboration diagrams ofcourse. I wouldn't count on use case to define the objects from the use case description. I think sequence or collaboration diagram is more useful because you're describing the algo which is what you're after in the first place.
DoSomeAlgo()
{
DoFirst();
DoSecond();
DoThird();
}
Actor is an object that initiates DoSomeAlgo() then objA sends message go objB saying DoFirst(), then objB sends message to objC saying DoSecond() then objA sends message to objC saying DoThird().
That's why it's important to have collaboration diagram done first so that you can define your algo with objects and it's also why this is only the first part since at this time you might not know the internals of DoFirst() and the others. Once you figure out the internals they might change your public interface of existing objects. Simply because you have now more details to work with than before. Use cases are tied to the collaboration diagrams ofcourse. I wouldn't count on use case to define the objects from the use case description. I think sequence or collaboration diagram is more useful because you're describing the algo which is what you're after in the first place.
Author
Quote:Original post by JD
Your code is basically about objects talking to each other thru public interfaces while doing detailed stuff internally.
Oh, I fully understand the basis of object-oriented design. I'm just interested in seeing real-life examples of it as it is applied to a pure-OOP development strategy.
If the code involves win32 API, then it can't be made really OO :)
OO is not the only programming paradigm, sometimes generic programming using template yields better productivity.
OO is not the only programming paradigm, sometimes generic programming using template yields better productivity.
Quote:Original post by Void
If the code involves win32 API, then it can't be made really OO :)
That's one big pile of horse manure mister.
You must be confusing the notation of calling member functions with '.' or '->' and the idea of OOP. Much of win32 really is based around an object notation
only that the calling conventions looks like:
DoStuff(Object, params);instead of the more convinent:
Object.DoStuff( params);but essentially they're the same you can do OOP in C or assembler you just lose
some notational convinence.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
