Opinions on object oriented programming
BlitzMax Forums/BlitzMax Programming/Opinions on object oriented programming
| ||
| What's your opinion about object oriented programming? Here's an interesting article I just read offering one viewpoint... http://www.devx.com/DevX/Article/26776 |
| ||
| Good article. I'm finding the OOP stuff in BMax fascinating - a real learning experience. But I must admit, i'm the 'don't quite get it yet' category. |
| ||
| from personal experience, once you really understand OOP there's nothing like it. now, the problem is *REALLY* understanding it....i mean, not just grasping the concepts, but once you get to the point that you actually *think* objects, then OOP really shines. Now, i do understand those who are sill confused...but don't feel bad, everybody has a hard time with OOP at the beginning. In reality i think it's a double edged sword....you can make the bests code and the worst with OOP (nothing like spaguetti OOP code, ARGH!) =) just one piece of advice: don't give up on OOP that easy.....you won't regret it. |
| ||
| That's what he says in the article. People go on about *really* understanding it etc. I find those sort of statements a bit hard to take as you aren't explaining anything. |
| ||
| I love it. I typically hate unorganized code with extraneous calls to different datastructures. OOP brings it all together in a nicely organized and elegant fasion. |
| ||
| I would guess that he doesn't realise that when he says some companies are still trying to get it after 10 years, that they missed one fatal thing....They were hackers/old school procedural programmers who knew nothing about OOP and probably didn't get trained. Like any programming. You can get a compiler and start hacking away. After a few years you'll find you've re-invented all manner of things that have been around for years....OR you go get some proper training and come out 10 years ahead of the rest. It's not a problem with OO, it's a problem with people just going ahead and using it without really knowing how to use it well. Without getting some really good training on how to make good OO programs. I was from the hacker mentallity. Self taught, learned what I needed. And guess what. I've been doing C++ for about 7 years now and I don't consider myself a great OO designer. I just got the job done how I knew and I was not (Am still not) interested in being an OO design guru - that doesn't mean learning isn't a good thing of you want to be great at what you do. I'm just happy to not be great at it (Programming theory is too boring) He also states that you can do stuff in procedural programming that you don't need to in OOP. I AGREE, but guess what? I almost bet my house that any large program, done totally procedurally will actually be an OO program in the end just without using the tools of the language to help You'll be passing in objects to work on to your Update() function rather than object.Update(). You'll be checking a type and calling a different Move() function (Hmm, virtual functions anyone?) Aaron |
| ||
| I only have a basic understanding of OOP, but I'm finding it very logical thinking of things as 'objects' and slotting in several objects to produce a program. Programming seems so much easier and programs should be less bug free as OOP forces you to think how things are created, updated and drawn before you add each object. I do think that OOP can be adhered to too strictly though. Using an OOP feature even though it makes the code more complicated is not a good idea I feel. |
| ||
| OOP is great because in a number of ways it is more natural for english speakers, anyone who does math, and in some ways to any human: 1. Method and field calling matches english and math Subject/Verb/Object: Subject Verb Object(s) Bank PokeInt Index, Value <OOP Mark Add Overriding, Private Members, and Properties <English 2 + 2 It's not a problem with OO, it's a problem with people just going ahead and using it without really knowing how to use it well. Without getting some really good training on how to make good OO programs. I was from the hacker mentallity. Self taught, learned what I needed. And guess what. I've been doing C++ for about 7 years now and I don't consider myself a great OO designer. I just got the job done how I knew and I was not (Am still not) interested in being an OO design guru - that doesn't mean learning isn't a good thing of you want to be great at what you do. I'm just happy to not be great at it (Programming theory is too boring) True, there are all those desing patterns, etc, and rampant misuse of OO.one oribkem is programmers rooted in a procedurall style will ask why they should use OOP. There is no concrete reason as far as functionality/speed goes that makes oop better. OOP can be implemented as a preprocessor on nearly any procedural language. C++ is a preprocessor for C.IMHO, OOP is best applied to creation of libraries, and mark should have left out the procedural methods and done most of the mods with just OO (yes, i know the procedural commands are ofte just wrappers for methods/fields). I know alot of the procedural people would hate this though, so mark has no choice. OO does apply well to SOME elements of a game/app. for instance, players, enemies, etc. However, you should use it restrictivly. For level data for instance, a type for each tile is crazy in most cases. just use an array. Also, dont make Types for things you only use once per loop. Persanally, atm bmax's oop support isnt that great. No overloads, no private elements, no properties, no templates. (order of my opinion of need) |
| ||
| @John Pickford: i know, i used to have the same problem when i started with OOP. in college, when we stsarted OOP i felt like charly brown in class, it was all just "WAH WAH WAH OOP WAH WAH Classes WAH WAH Objects" and then one day it clicked. it's kinda hard to explain. I don't know if you ever studied logic from a CS point of view. I remember many people in class just staring at the board completely numb and then one day they would brighten up and understand the whole thing at once. OOP is more or less like that......it's just very confusing and too much information, and then one day it hits you like a thousand bricks, you go "OH! I *FINALLY* GET IT!" just work a little with it, don't worry if you don't *really* get it, because eventually it will be all clear to you. that is, if it's not clear already. but it will :) |
| ||
| OOP is good, in moderation. I've found that many programmers, especially those that have only used languages without formal module systems, tend to see OOP as the only way to modularize their code, keeping data hidden and encapsulated. Many times pro-OOP arguments tend to be solely about modularization, which is of course something you can do without OOP just fine (it's just verb-noun instead of noun-verb) The greatest downside to OOP I've seen is that some people get way too into it, succumbing to a kind of mania. They feel the need to make everything be an object, even at the expense of simplicity. The result is "ravoli programming," where everything involves long inheritance chains, and it is difficult to see exactly what the code does because it's scattered across many files. Even Stroustrup (creator of C++) cautions against using inheritance and more than lightweight classes outside of fundamental libraries. OOP shines when you think of it as sending arbitrary messages to things without having to worry about what those things are. In a game, you can call the "rotate" method of an object without worrying about whether it's a bullet, a tree, or a rocket. Similarly you can call the "give me your current position" method. Very nice. At the same time, you need to be careful here. "Rotate" may make sense for some objects but not for others. You don't want to make dissimilar things look functionally the same if they are too different. |
| ||
| For level data for instance, a type for each tile is crazy in most cases. Surely that depends on the complexity of the tile? If it's just an image, sure - if it has an associated sound with it's surface, and physics properties for an object crossing it, then surely using an object would be a most excellent solution? They feel the need to make everything be an object, even at the expense of simplicity. These would be the people who do not understand OOP. and it is difficult to see exactly what the code does because it's scattered across many files. Again, someone without the faintest idea of the fundamental OO design principles of low coupling, high coherency. "Rotate" may make sense for some objects but not for others. Yes. More specifically they would make sense for any object that implements whatever interface your rotate method is defined in. And the compiler will give you an error (as opposed to happilly compiling and then subsequently randomly crashing). |
| ||
| I think object oriented programming has its merits and thinking in terms of object is all very well. But for me, defining things as an `object` is too rigid a definition for aspects of the world or of problems and there needs to be a looser system *which I'm developing* :-) |
| ||
| Object Oriented Programing only has problems when you over-abstract. But the Black Boxing of OOP is nessicary if you are working on a big project. |
| ||
| lol. can't quite imagine an elegant looser system, but whatever. |
| ||
| Um. Well my system is based on metaphysics, I think it's a lot more accurate way to represent reality. :-) |
| ||
| lol. |
| ||
| These would be the people who do not understand OOP. ... Again, someone without the faintest idea of the fundamental OO design principles of low coupling, high coherency. It is worth arguing that OO is difficult to do correctly, and that difficulty is one of OO's greatest weaknesses. It's so simple to get a basic understanding of OO, and yet in practice it takes a number of projects to work through the typical "OO over-engineering" phase. I'd say the majority of OO programmers never get out of that phase, and that makes it difficult to work with them on a large project. That said, the most common use of OO in Blitz Max is undoubtedly going to be to represent high-level game entities--aliens, cars, whatever--which is a simple and clean use. |
| ||
| I like that BlitzMax gives you plenty of option to NOT use OO as well, makes for a nice balance. |
| ||
| That said, the most common use of OO in Blitz Max is undoubtedly going to be to represent high-level game entities--aliens, cars, whatever--which is a simple and clean use. Totally agree. |
| ||
| I've been reading up about many kinds of object oriented implementations, not just BlitzMax's implementation or C++, also looking at Self and Smalltalk and the concepts in general. This: http://www.objectfaq.com/oofaq2/ is a good site for explaining things although some terminology is a little unnecessarily heady. *click on the `Basics` button* There seems to be a number of often subtle differences between how each language implements object orientation and what features are provided. I liked the sound of `1-dimensional` object-orientation where any object can be a parent to any other object, and you have delegates to choose different parents, rather than having `classes`. So the inheritance is more dynamic. This is closer to what I think of as a highly flexible paradigm. I was also reading up about multiple inheritance and multiple polymorphism. Strange solutions to preconception-induced problems. I do have some issues with how all this works and its limits. I don't like the imposition of a hierarchical structure as being the only way for objects to become associated through inheritance. All objects should be completely freely associating with any other. Also those relationships shouldn't be described in terms of superiority or inferiority - all are equal. There may be contracts or associations but none of this super/parent/child stuff. I also feel that while it's all very well defining parts of problems or parts of the world in terms of `objects`, where an object is basically any aspect of a problem that is tangible enough to be described, this limits communication to only occuring across boundaries rather than the presence of `direct` understanding. Such communication is interpretation, not `knowing`. Objects should be able to metamorphose fully or in part with other objects to effectively share data and functionality and to temporarily extend any object's repertoir. I think it's wrong to think of things in terms of objects and more powerful to think of them in terms of `mediums` - mediums are always open and are never fixed. Mediums allow objects to transcend themselves and their limitations. Also I don't think I believe in encapsulation where you hide stuff behind a stubborn controlling interface. In this model you have to more or less `ask` an object to do something. This is all very polite and socially acceptable but to socialize means `social-lies`. Two people in love do not usually have to ask each other at every turn whether something is okay. There is an openness and trust. I think encapsulation is a closed-minded model. There is no intimacy in having to access objects through interfaces. Interfaces get in the way. That's like having to write a note to your partner asking if it's okay to kiss them. Objects should be able to resonate with one another to an absolute degree, optionally of course, so that they effectively become `one` and then one object can operate the other or operate `through` the other or together. Also one object can then be like a merged pool of objects, able to operate on all it is aligned with directly and immediately without any need for message passing. To me, extra message passing indicates poor design. I also think there is still too much of the roots of procedural programming still left in object-oriented programming. It's one step up but not all the way up. It's kind of like procedural programming chopped up into smaller pieces and extra infrastructure to manage the pieces. I think the best paradigm would be where each part is a reflection of the whole - where the whole is an instance of the part - ie `made in the image of` - holographic. In this system any single object can be the whole system or part of a system. Also any single object needs to be sophisticated enough to interact with all others and not just in predetermined ways. In fact, the ideal system needs to support subjectivity. So those are a few of the areas that I have issues with and am seeking to address with a new kind of programming paradigm. |
| ||
| been smokin the wacky weed? |
| ||
| *smile* no. Your supply is safe. |
| ||
| Resonate to an absolute degree?, Metamorphose?, 'Social Lies'? What a lot of claptrap. I'd like to encapsulate that lot in a round filing cabinet. |
| ||
| Objects making love to one another? Objects at one with the universe? Intimate cross-class relationships? I think you've lost the plot somewhere. |
| ||
| Since your viewpoint of object-orientation is clearly superior maybe you'd like to enlighten us instead of treading on us? |
| ||
| Just to clarify, When I said that objects should be able to `resonate to an absolute degree` I am simply saying that I would like two objects to essentially be thought of as the same object, ie with no relative differences, while maintaining some very small degree of detachment allowing the union to be divided later if desired. Think of it as two or more pointers pointing to the same variable, or an instance of a type with more than one handle. But at the same time, each handle has its own local `self` which may become involved in the union to varying degrees. Maybe a better word for metamorphose is `shapeshift`, ie one object changes its properties and so on to match those of another, like a mirror. The social lies part is valid. Everybody puts on a social persona that covers their inner self. There are tremendous dishonesties involved in most social expression since the persona is involved. I am merely making use of metaphors and analogies by using this to relate to software issues. |
| ||
| > The social lies part is valid. Everybody puts on a social persona that covers their inner self. Ah, but which is the lie, the social persona or the inner self? (sorry, couldn't resist) |
| ||
| > The social lies part is valid. Everybody puts on a social persona that covers their inner self. Ah, but which is the lie, the social persona or the inner self? (sorry, couldn't resist) But could it not also be argued that the persona displayed in a social situation is an expression of a single facet derived from a multi-faceted personality and thusly that the persona perceived by others is a portion of the whole truth rather than a manufactured lie? ;) |
| ||
| Umm, sure. But that's taking it way off-topic - it's just a loose analogy. |
| ||
| I don't see where 'belief systems' come into it. We're talking about programming languages and you post a load of air-fairy gibberish. What sort of response do you expect? 'no relative differences' what does that mean? 'while maintaining some very small degree of detachment allowing the union to be divided later if desired' Eh? 'Maybe a better word for metamorphose is `shapeshift`, ie one object changes its properties and so on to match those of another, like a mirror' What does that mean? Why does the object change? How? What does a mirror have to do with it? If you *REALLY* have a sensible point why not post in plain English cos I really can't tell what you are on about. And I suspect you don't know yourself. |
| ||
| How does this analogy relate to software exactly? Can you explain what this might mean, for example, to a programmer working on a 3D platformer or a FPS. |
| ||
| I gotta admit, it is like Dilbert speak. Today's calendar entry has M.T. Suit say "I enhance core competencies by leveraging platforms". |
| ||
| Since your viewpoint of object-orientation is clearly superior maybe you'd like to enlighten us instead of treading on us? Here. Also see if you can't find an article on Simula instead of SmallTalk. Simula is clearly the more user-oriented (as opposed to programmer oriented) language. When I said that objects should be able to `resonate to an absolute degree` I am simply saying that I would like two objects to essentially be thought of as the same object, ie with no relative differences, while maintaining some very small degree of detachment allowing the union to be divided later if desired. Ironically this is where object inheritance comes in.It seems to me you just don't understand the point of object orientation. Yet. Read "Thinking in Java", after the first couple of chapters, you'll understand. |
| ||
| Belief systems come into it as follows... When you create some software you *probably* try to do the `best job` you can, put your heart and soul into it, make it be the best quality or highest vision that you can muster. So I asked myself, what would be the highest vision or philosophy that I could come up with that could be the inspiration for software that I create? The answer for you might be `other games you like` or `cool ideas` or maybe you draw particular inspiration from chaos theory or see a lot of sense in open systems or object orientation - whatever. For me, my personal sense of spirituality and my grasp of metaphysics (albeit incomplete) is the highest most refined aspect of my world and something that I felt could be applied to software engineering. I will usually base everyday actions on those beliefs and understandings, so I figured why not base software creation on such things also. Since a highly refined philosophical outlook probably makes the most sense, why not apply such philosophies to software? Wouldn't you seek to express yourself from your highest vision and clearest awareness? And if you are, for example, religious, wouldn't you try to bring God or Jesus or some such beliefs into your work? Just because I happen to favor metaphysics means that I like to try and use those concepts in my work. So when you are attacking my work you are attacking my beliefs. For me it is not just about talking about programming in isolation, it is talking about ethics and sense of reality and the source of my inspiration that I respect. Maybe if you personally don't take things that far and focus instead perhaps on pure computer science or pulling together favorite game genre's to create something new, or whatever your method is, that's fine too. I just happen to use other kinds of resources and guidelines in my work. So when I bring something close to my heart into my work, such as spiritual concepts or metaphysics or my sense of God or whatever, yes it does mix `business with pleasure` and puts my beleifs right out there on the programming plate. So please have some respect for that instead of trying to score points with aggressive impatience. Just because my ways are different and you might not prefer them doesn't mean you should persecute them or me. I apologize if my way of writing seems esoteric or alludes to but doesn't convey concepts with enough clarity for you, or doesn't speak your language or match your way of thinking. I am used to thinking and writing this way because of the familiarity I have with certain things, and it's also the way I think laterally or create new perspectives. I am trying to convert these ideas into your `plain english`. It doesn't come down to what response I expect, Robert, but such a response is ALL I can apparently expect from you. I'm sorry but you've offended me. "No relative differences": The human bodily senses can only sense changes. Something needs to move for the eye to detect it - look at the exact same spot for a while and you become temporarily `blind`. You need a `relative` change, something which is in contrast to how things currently are, in order to sense it. There must be a difference and that difference must be in relation to the current state. So what's wrong with referring to such a thing as "relative difference"? The absence of relative difference would essentially mean that separation disappears and things seem to all blend together indistinguishably. Two objects with no relative difference simply means they appear to be one object. "While maintaining some very small degree of detachment allowing the union to be divided later if desired": I'm using the word detachment to refer to having some kind of a handle on an object that doesn't get involved in the merging or unification of the content of two objects. The handle is detached and allows you to keep control of the fact that the objects are unique, even though they may be acting identically. You couldn't have absolute unity otherwise you'd completely lose track of there being two objects and their original separate state would be irrecoverable. In order for one object not to lose itself in another when they unite, there must be at least a small degree of detatchment from each other. "what does a mirror have to do with it": Copying the content of one object to the content of another could be described as mirroring could it not? Or perhaps causing the content of one object to temporarily mirror that of another, to later revert to its original state? "And I suspect you don't know yourself": Did that make you feel better cus that doesn't add anything to the conversation. Robert, it is a different way of thinking about what objects are and how they relate to each other. Thinking of object boundaries as tangible differences between parts of the world, is to me a little short of how the world models itself. If I say okay, I have this object, let's call it a tree and lets move it around independently and place it on the landscape, that's all very well. But because that tree is now confined to the definition of what a tree is, you can't think of that tree as anything else. You can maybe compose it of branches or leaves or whatever, but this is still thinking of trees. If for example you ask a Buddhist they might ask you, what is a tree? They might tell you actually the qualities of what makes it a tree are fleeting. It is not the bark because the bark changes. It is not the branches because they move and grow and eventually die. It is no that it is separate of the ground because it came from the ground and eventually returns to it. There is nothing inherantly permanently real about any object. But object-oriented programming treats objects as though they have a permanent fixed reality. That really stems from the fact that computers have an extreme sense of state - on or off, black and white, exists or doesn't. To me that is shortsighted and filters out some otherwise interesting possibilities of what you might otherwise do with that `object`. I also see it as the legacy of every software design principle having been in some way a dirivative of a `binary reality`, since that is the computer's native condition. You'd be surprised just how huge an influence 2^n is on all aspects of software creation. It is more accurate, metaphysically, to say that the tree is a field of energy held in a given configuration and that it never really achieves a permanent fixed state - it is approximately a tree. It just moves `through` stages of tree life in constant transformation. So I am figuring it would be more expressive to model a world not based on `objects` that have to exactly match given specifications, but based on mediums, whereby a medium can contain a given form but that form is never fixed in a permanent condition. There is always openness and accessibility and mediums are transcendent of what they might contain. I am thinking this is going to be a better way to model the world. It would give more flexibility, efficiency and is an even more natural and accurate representation of reality - for me anyway. I'm sure there are benefits to it that I haven't realized yet because I am still refining it and designing an implementation of it. I would hope that in a given game project, for example, it will make things much easier to model, to organize, and to interrelate. It should make sharing between objects much more intuitive and direct. It allows a system to be completely decentralized with the option of centralization at the same time. It frees objects from being in a hierarchy and allows any kind of dynamic structure between them. It ultimately gives the user more freedom and should be easier to create with. Does that help? |
| ||
| Nope. |
| ||
| Never mind then. |
| ||
| @AngelDaniel Perhaps if you could provide some implementation details (code samples and practical game examples) that might clarify things. Your above post is too vague to make much sense. The handle is detached and allows you to keep control of the fact that the objects are unique, even though they may be acting identically. But you can do that quite happily in OO code anyway. Just create two intances of a class, and another object to represent any shared data. Each instance has a member variable which points to the shared data object. Use a bitmask to specify which properties of each object are shared, and which are specific to that instance, and store any specific information in another member variable in that object. In BlitzMAX, since every type extends Object, you can cast any type to any other type. |
| ||
| If you don't like OOP, don't put any methods in your classes ;) |
| ||
| Um, yes, you can implement some of the same functionality using a language like BlitzMax, but it is more longwinded and in my opinion less elegant to do that. I don't have any code to show you but there will be some in future. |
| ||
| In BlitzMAX, since every type extends Object, you can cast any type to any other type. Err, No. That is quite wrong. If I have two types: Type bob Field x : Int End Type Type Tim Field y : String End TypeA variable of one of these types should not be able to be cast to the other type - the types are not the same. How would a user of a 'tim' know what to do with the string inside a 'bob'? They might inherit from a common class, but that does not mean they are the same. What it means is that it can be passed to something that expect to get an argument of type Object, but it does not mean that this thing automatically knows what to do with a 'tim' if it expects a 'bob'. |
| ||
| Since a highly refined philosophical outlook probably makes the most sense, why not apply such philosophies to software? Because most people (aka programmers) don't subscribe to a single philsophical view. Not so with objects. Most people when they see a bee, they'll recocknize it as a bee (or insect). And if you are, for example, religious, wouldn't you try to bring God or Jesus or some such beliefs into your work? Actually I believe the most common answer to this question is "No" since most religions subscribe to the idea that god is the only perfect being, and mankind is imperfect. Thus trying to bring god into a human process would be considered blasphemous. For me it is not just about talking about programming in isolation, it is talking about ethics and sense of reality and the source of my inspiration that I respect. Ethics and sense of reality isn't really much of an issue with regards to computer programming. The handle is detached and allows you to keep control of the fact that the objects are unique, even though they may be acting identically. This is already the case in OO methodlogies. All objects by definition have Identity, State and Behavior. But because that tree is now confined to the definition of what a tree is, you can't think of that tree as anything else. You can maybe compose it of branches or leaves or whatever, but this is still thinking of trees. And how is that "short of how the world models itself"? But object-oriented programming treats objects as though they have a permanent fixed reality. No it doesn't. That really stems from the fact that computers have an extreme sense of state - on or off, black and white, exists or doesn't. Except object oriented methodology takes place in domain space - not computer space. Sure, a computer is a finite state machine, but even metaphysically speaking, everything has a finite ammount of states. It's just a matter of determining which are relevant to your object model. I am thinking this is going to be a better way to model the world. It would give more flexibility, efficiency and is an even more natural and accurate representation of reality - for me anyway. What you're thinking about is the Composite Method Pattern. |
| ||
| Err, No. That is quite wrong. If I have two types: I didn't say that it was a good idea, I just said that as far as I know, the compiler will let you do it. EDIT: If you go round the houses that is - ie. cast the type to an object, and then back to a different type. |
| ||
| Mikkel: "Ethics and sense of reality isn't really much of an issue with regards to computer programming." -- For me it is, so it's a matter of personal preference. ("The handle is detached and allows you to keep control of the fact that the objects are unique, even though they may be acting identically.") "This is already the case in OO methodlogies. All objects by definition have Identity, State and Behavior. " -- Then that requires at least two objects or a class and an object. My system requires only one `object`. "And how is that "short of how the world models itself"? " -- A tree is not just a tree. That's a human interpretation of it. There is more to it. Whether that `more` is important is the issue here. It's important to me. Maybe it doesn't matter for others. ("But object-oriented programming treats objects as though they have a permanent fixed reality.") "No it doesn't." -- To a degree it does. "What you're thinking about is the Composite Method Pattern." -- No, because I don't know what that is. Care to explain? I am guessing it is not an accurate comparison. |
| ||
| I started programming with BASIC. My programming skills evolved into OOP as my programs became larger. First I started to use a Labeling Rule to group constructs together by label. This made it easier to organize and recognize the purpose of construct in the code. Second, I began to separate the groups into individual files. "Bot Stuff" goes into the "Bot" File, "RayGun Stuff" goes into the "RayGun" File. Then I found Types. Types solved a lot of problems and used the Labeling Rule by default. Types only handled variables and arrays, I still employed the labeling rule for functions. Before I realized it, I was coding BASIC in a Object-based manner. Once I was made aware this, I picked up a book on C++ and OOP. At first, Abstraction, Encapsulation, Inheritence, and Polymorphism were a tad too tough to grasp. But, as I continued program using my home-made Object-Based techniques, the concepts began to take shape for me. I've have worked around OOP for so long, that I have adopted the use of many other programming techniques: Object-based,Relational Key-based, and Prototype-based. In some cases these other techniques are more efficient then OOP. Object-based programming becomes a logical means organizing code into objects. Relational Key based Programming becomes a logical means of linking the objects together by ID Keys. Protoytype-based programming becomes a logical means of creating new objects from a template. I still use my Labeling Rules to keep code readible. |
| ||
| -- For me it is, so it's a matter of personal preference. Very well then. Perhaps you could give an example of an unethical programming problem. A problem we, as programmers, should not attempt to solve, because doing so is unethical? -- Then that requires at least two objects or a class and an object. My system requires only one `object`. Please elaborate. -- A tree is not just a tree. That's a human interpretation of it. There is more to it. Whether that `more` is important is the issue here. It's important to me. Maybe it doesn't matter for others. Ofcourse a tree is a tree. Human interprentation has nothing to do with it, as human interprentation is dependant of the human that does the interprentation. If that more is more important to you, you simply include it in your object model. Whether you chose to bloat your objects with redundant or superfluous states or behaviors is entirely up to you. I would reckomend against it, but each to his own I guess. -- To a degree it does. Elaborate please. -- No, because I don't know what that is. Care to explain? I am guessing it is not an accurate comparison. Sure. The composite pattern is one of the original "Gang of Four" structural patterns and is described in great detail in the book "Design Patterns: Elements of Reusable Object-Oriented Software" by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides (aka. the Gang of four, or just GoF for short). It allows you to create structures of infinite (limited by computer hardware, naturally) complexity, and address them as one. It is your "one object" if you will. It's made up of three distinct type of objects: A component - which can be either a Leaf or a Composite, a Leaf which is the actual object in question, and a Composite which works as a container for components.By far the most common use for the composite pattern is when designing graphical user interfaces. Again I can only strongly suggest looking at SIMULA, not SmallTalk for ideas on how Object Oriented disciplines can help you design your software. Additionally I would suggest reading up on agile methodologies that employ Object Oriented principles religiously, like Extreme Programming for example. |
| ||
| Thanks Mikkel for the feedback. |
| ||
| What about my feedback? Talk about ungrateful. |
| ||
| Thanks John ;-) |
| ||
| I've gone back to Blitz3D. It pains me to say but I really don't get OO in Blitzmax and nor do I like the way types work. It's a lot for me to fiddle with and remember. I know, not an excuse, but there's something quite unsatisfying about Blitzmax right now and although I'm trying my best, the OO stuff just doesn't seem to make anything BETTER than what I can do now anyway. In fact I'm finding myself having to do more typing in order to achieve the same results. With Blitz3D, you have insert before, after, and really easy types management. Blitzmax requires you to mantain seperate lists and doesn't have commands to easily access types. I'm sure many will argue, but BM just doesn't click like Blitz3D did. |
| ||
| Blitzmax requires you to mantain seperate lists It does not require you to maintain seperate lists, it merely doesn't force you to use a list if some other datastructure is more suitable. Incidently classic Blitz auto-lists can be implemented using 5 lines of code. and doesn't have commands to easily access types. What do you mean? How has type access changed? |
| ||
| What do you mean? How has type access changed? With Blitz3D, you have insert before, after, and really easy types management. |
| ||
| With Blitz3D, you have insert before, after, and really easy types management. First of all, this has nothing to do with type access, and second of all, I don't see how Blitz3D is any easyier than BlitzMAX. |
| ||
| > First of all, this has nothing to do with type access Well it is how you can insert items into a type list in B3D wherever you want - so it isn't exactly not related :) > With Blitz3D, you have insert before, after, and really easy types management. In Blitzmax you can get the same effect easier by setting the comparison properties of a type list - then blitzmax would keep it sorted for you automatically. (If I am right in assuming that keeping things in a certain order is what you were after) |
| ||
| I totally understand where the flying willy is coming from. I think using the Type Keyword in the manner BMAX does is somewhat confusing, if you're familar with previous BlitzBasic Languages. IMHO, the Class Keyword would have been totally appropiate. BMAX has some significant syntax changes which make it more similar to C++. It is almost a completely different animal then its predecessors. The introduction to Classes could 'fit' here very well. To be honest, all the tutorials on OOP don't explain it in easy-to-understand terms. There is only a small vague definition of what object is and the books/tutorials jump into explaining inheritence, ecapsulation, yada, yada. No one goes in depth on how to identify an physical or virtual object in the first place. I've adopted many different programming methods, disciplines, and paradigms all which use a Procedural Language like Basic. After writting a compiler and virtual machine for my BlitzScript3D Engine I realized you simply cannot beat Assembly. Not much OOP involved with it either. |
| ||
| OO programming is the best way to create games. All the logical structures used in the development of an algorithm are objects. When ussing languages such as Blitz3D, wich is not OO, you have to 'create' objects (such as a rocket, a bullet, etc), but this objects don't have any existence in the code. they are just a mixture of variables, arrays, etc. OO programing is the best way to organize things, and it helps applications to grow and grow in a good way. |
| ||
| you have to 'create' objects (such as a rocket, a bullet, etc), but this objects don't have any existence in the code. they are just a mixture of variables, arrays, etc. Ziggy you confuse me with this statement. If you create a type structure and write it in the code, does the object or record not exist in the code? C++ Classes evolved from C's Type Structs. For all intense purposes, aren't all objects are just a mixture of variables, arrays, methods etc under one identifier at least from a compiler perspective. |
| ||
| First of all, this has nothing to do with type access, and second of all, I don't see how Blitz3D is any easyier than BlitzMAX. It has to do with how objects in a link list are accessed. If you don't see how being able to go: a.Alien = First Alien g = After a Isn't easier than the way we have to do it in Max, then you need your head checked. |
| ||
| Michael Would you be so kind as to provide an example of how you do it in BMax. There are many ways to access data from types in Blitz3D. You have Object/Handle Functions; You can use an Array of Types; and you have your Sequential Access commands like Before, After, etc. |
| ||
| IMHO, the Class Keyword would have been totally appropiate. Traditionally Class and Type are interchangeable. One is from Simula, the other from SmallTalk. Which one you use tends to generally depend on how you got introduced to the object oriented paradigm (or whether you're European or American). C++ Classes evolved from C's Type Structs. No they didn't. C++ classes evolved from classes in object oriented languages like Simula (1968) and SmallTalk (1971). Structs evolved from the need to group some variables together (something which was not possible in it's predecessor B). Isn't easier than the way we have to do it in Max, then you need your head checked. I'm sorry. I was not aware there was a way MAX forced you to do it, although I must admit it's been a while since I tried to itterate through a list manually, as I tend to just use EachIn, which is a big step up from For..Each, IMHO.Thanks for the personal insult, very becomming of you to belittle my person because I have a different oppinion than yours. |
| ||
| I'm struggling to follow this but, I think, I'm in the same boat as Frank. How could you manage, for example, the same function as Object/Handle in BlitzMax. I'm sure there was another thread which discussed this at even more length but I can't remember the outcome. |
| ||
| I'm a little lost as to why it is hard or confusing, of course I've been doing OOP for awhile now. For the object handle I myself don't find it any harder to create a bunch of images and refer to them in blitzmax then it is to handle images in blitz. For lists it does take an extra step to get them created but after that it is just as easy - different but just as easy. |
| ||
| How could you manage, for example, the same function as Object/Handle in BlitzMax. It depends on what you're using Object/Handle for. In 99% of all cases you would acheive this more elegantly using polymorphism, and function/method overloading.For instance a typical example would have you defining what Java refers to as an Interface, but which isn't actually formalized in BlitzMAX. However you can fake it well enough making a class that's entirely Abstract (having no functionality at all). What's the point of making a Type with no functionality? It's hard to imagine, think of it as a skeleton of the functionality you can have. The point is that you now have a type that your other types can extend from. No matter what functionality they have, you can access this functionality in a uniform manner. So if you have for example 4 types, car, bus, train and airplane -- all which have different states and behaviours, that are implemented differently you can pass them all to the same function, by using the Interface as a reference to which functionality they have. No need for Object/Handle! Additionally you don't need a field that identifies which type of object it is, as the compiler knows this, and will automatically execute the correct code for a given object, without the need to construct complex nested if ... else or Select ... case structures. Additionally you can later add a fifth type, motorcycle, and all you have to do, is write the new implementation, and all of your old code will still work perfectly! There's no need to work out special cases for different objects, because the compiler can tell the difference, so you don't have to! |
| ||
| I personally dont use Object/Handle commands. But, from what I've seen in others code, they use them as means to randomly access types vs accessing them sequentially with a For...Each loop. But as I stated eariler, I dont have a problem with OOP. I just feel that many books/tutorials hop into concepts of encapsulation, inheritence, yada, yada before really explaining how to identify and create an 'object' in the first place. |
| ||
| I'm sorry. I was not aware there was a way MAX forced you to do it, although I must admit it's been a while since I tried to itterate through a list manually, as I tend to just use EachIn, which is a big step up from For..Each, IMHO. EachIn has nothing to do with it. We are talking manual iteration through a linked list, that is, being able to grab the previous or next item. There isn't any way Max forces you to do it of course, but there are no simple, out of the box methods you can use. When we're talking simplicity, simplicity only after you've implemented a new feature in the linked list stuff just doesn't cut it. Thanks for the personal insult, very becomming of you to belittle my person because I have a different oppinion than yours. I really don't know what to say to that, but I don't see how you can go and take the moral high ground after consistantly treating people like idiots and forever arguing your points (even when you're wrong) to death. |
| ||
| I totally understand where the flying willy is coming from. Do you have any idea what you're typing? 0_o This one's goin' in the vault. |
| ||
| lol |
| ||
| I hate OO advocates. In the end, everything is proccedural(sp?) anyway. The only reason I use Blitz instead of C++ is because it reduces the amount of typing and such that I have to do. The only reason I would use c++ instead of ASM is for this same reason. Alot of the time I find myself typing tons more OO code to do what I could do in ASM in a few lines! wtf? I hate the amount of overhead introduced by the famous "GetValue", "SetValue" mehtods. I hate hiding code alot of the time... If they want to break it, let them. I use OOP when I need a dynamic amount of instances of something. This is the place where I like OOP. I don't make everything into a class. Anyway, whatever. I like where Blitz is now. BMax is great. And, for the record, I have used more OOP in BMax than Proc so far... Ohh and Inheritence is very usefull. |
| ||
| In the end, everything is proccedural(sp?) anyway. What do you mean by "everything"? Program execution is not everything. By extending the same arguement you could say that you hate human readable languages (like Basic and C) because "everything" is executed in opcodes anyway, so we should all go back to using punch cards and magnetic tape.The object oriented paradigm is meant to make programming more accessable to non-scientist types. The theorem goes that an ordinary person, particularly a computer user, will be more accustomed to understanding things in terms of objects (because that's how we percieve the real world) than arbitrary computer code. Additionally object orientation in a programming language works as an abstraction from procedural languages, in much the same way BASIC for example is an abstraction from Machine Language Assembly. It allows you to, as you put it, "type less". (Although the traditional phrase is solve problems of a higher complexity in a shorter relative ammount of time.) |
| ||
| I agree, it is a more natural system, however, that actually makes it harder for procedural programmers, at least until they start using it regularly. Same with say, switching to a functional language, except much more dramatic since functional languages are bizarre to a procedural/oop programmer, however not as hard for a non-programmer type. |
| ||
| I think it's good, allthough all the extends this one, and this extends that one - confuse me. Also what is the difference between a Method and a Function, as they appear to do exactly the same purpose? |
| ||
| I hate OO advocates Such strong words. I don't hate them, but, I don't understand the fanaticism. Afterall, its only Programming Paradigm, not a religion. As my Procedural programs increased in size and complexity I found myself adopting Object-Based programming techniques to better organized them. But, I also adopted other techniques, paradigms, methodologies or what ever you want to call them, to make my life as a programmer easier. The concepts of OOP are really not that complicated if one breaks down those fancy words: Abstraction, Polymorphism, Encapsulation, Inheritance, Interfaces, blah, blah. But, those words in themselves suggest complexity. Some would have to admit the C++ syntax is not the most user-friendly, heck, C isnt for that matter. I think BlitzMax attempts to give OOP a friendly face. IMHO its easier to transition into OOP from a procedural programming if you start with Object-Based techniques. |
| ||
| But, those words in themselves suggest complexity. How do you figure that?How can words suggest complexity? |
| ||
| I've little experience of OOP so I'm struggling slightly. However, my major gripe with OOP in BlitzMax is it's turning me into a programmer when I only want to be a games creator. It probably stems from my hopes for BMX. I would have been happy with B2D+(realtime) alpha, rotation, scaling, lighting as it was the only stuff missing for me. I was just getting the hang of the alpha stuff limitations and considering B3D+nsprite pro when BlitzMax beta was announced. I can't say I'm overly impressed at the moment. In fact, I was happier with 1.02 than 1.03. The IDE hasn't advanced much (time for a 3rd party) and the debugger is poor. The suggestion the doc isn't to be updated (except through the Wiki) is a big disappointment. I think what I'm saying is I can't get the impetus to worry about OOP when, at the moment, I'm not sure how useful the final product will be for me. As for OOP itself, it's one of the last bastions of complexity which keep the plebs out of programming. |
| ||
| However, my major gripe with OOP in BlitzMax is it's turning me into a programmer when I only want to be a games creator. How do you reckon that? BlitzMAX is a higher abstracted language than Blitz/3D/Plus. Thus using it requires you to be less of a programmer (that is less capable of understanding how a computer works) than you would have with earlier versions of Blitz. As for OOP itself, it's one of the last bastions of complexity which keep the plebs out of programming. Could you send me an e-mail please? I'd like to ask you something in private. |
| ||
| Hmmm. I thought I had responded on this but let's try again. How do you reckon that? BlitzMAX is a higher abstracted language than Blitz/3D/Plus. Thus using it requires you to be less of a programmer (that is less capable of understanding how a computer works) than you would have with earlier versions of Blitz. I'm sure you're right. However, Blitzmax is making me become a programmer rather than a Games Creator. I'm confident with the Blitz command set and modular/procedural programming so I was hoping BlitzMax would be a maximised version of Blitzbasic rather than a different approach. To learn OOP procedure and, possibly, OpenGL while fighting with the doc and waiting for 3rd party 'add-ons' isn't really what I had in mind when I bought (the beta of) BlitzMax. Due to other commitments I don't really have the computer time to put that much effort into it whereas BlitzBasic was a 'go' from day1. I've emailed you as well. |
| ||
| I am personally one of the people who really like oop and like the ways in which it makes the programming process more logical. I would also like to point out one thing about the Object/Handle commands in bb3D and how you can imitate them in blitzMax. in BB3D you used to do this,
a = CreateFoo()
DoSomethingToFoo(a)
function CreateFoo()
f.foo = new foo
f\a = 0
return Handle(f)
end function
function DoSomethingToFoo(handle)
f.foo = Object.foo(handle)
f\a = f\a +1
end function
in blitz max you can do the following (i think because everything is derived from a base object class but i'm not sure) Type foo Field a:Int End Type a:Int = MakeFoo() DoSomethingToFoo(a) Function MakeFoo:foo() f:foo = New foo f.a = 0 Return f End Function Function DoSomethingToFoo(f:foo) f.a :+ 1 End Function now i could be wrong but how does that not give you the same functionality as bb3d's object handle commands.. you're casting the f:foo into a reference integer which is exactly what object handle does |
| ||
| Opinions on object oriented programming - LOL! I almost fell over when I read that title OOP is a very cult like world. Its alot like the fanaticism seen with the consoles, or cars, or favourite OS's. Languages are tools, use them as you would a tool, and dont worry about what other people think - its there to do a job, just do the job :-) |
| ||
| Apparently some of us are subjective ;-) |
| ||
| Pedantic would be more appropriate. :-) http://dictionary.reference.com/search?q=pedantic - its pretty appropriate I think (imho of course). You think in 20 years time it will matter what langauge you use to make an application on a 100 Tera flop machine :-) I guarantee using C++/OOP will be like people refer to asm now.. takes too long. Its a tool.. not a way of life. |
| ||
| Most people , also here in blitz3d forum, think that openGL architecture is much more straightforward than direct x. Why ? OpenGL is a simple library of functions and and variables , while direct x is oop An other example I have tested several game engines. The learning curves for the oop ones is quite steep while I got familiar with non oop engines in a couple of hours. But if you ask , do you like oop? most of people answers, yes In conclusion in my opinion oop is a sort of "fashion" Obviously I do not mean that it is of no use, I am not so competent, for big projects probably it is a must, but for an hobbyest or shareware programmer it is of little use, except at a very basic level. I like classes but they are a simple extensions of c structers. Beyond that it only a mess. |
| ||
| You think in 20 years time it will matter what langauge you use to make an application on a 100 Tera flop machine Even today, it doesn't matter. That's why PL/1 programmers can ask (and get!) whatever salary they want. OpenGL is a simple library of functions and and variables , while direct x is oop Actually it's the other way around. (Except "Managed DirectX" which is now also OO). Obviously I do not mean that it is of no use, I am not so competent, for big projects probably it is a must, but for an hobbyest or shareware programmer it is of little use, except at a very basic level. That's a very 'elitist' (for lack of a better word) thing to say. Many OO methodologies, such as XP (extreme programming) and UP (unified process), include quality assurance and quality control techniques (such as unit testing), making it easier to create programs to a high standard. If that's not your intention, I can see how OO and it's associated methodologies might not be your cup of tea.Additionally the OO paradigm allows for easier maintenance, making it easier to add new functionality, expand on old functionality or port to newer platforms (as you can keep platform independant code modularized). I like classes but they are a simple extensions of c structers. Again it's the other way around. Structs in C are a cheap imitation of classes in SIMULA and SmallTalk, since B and BCPL did not have any advanced datatype support at all. |
| ||
| Jeez this is getting to be a long thread ;-) |
| ||
| Id really like to know how OGL suddenly became oo? Since SGI made it 20 odd years ago, its been about as C as you can get. And DX (esp from 5 onwards) has a well defined OO background - especially being derived from COM (OO!). Also, OO doesnt define unit testing (otherwise we would have had troubles at uni when I went. :-)). Unit testing is simply a methodology (like black box, white box testing and so on). This is regardless of the language - you can unit test Forth, but I doubt too many would call Forth oo, same goes with ASM, or pretty much any langauge. Alberto is fair in judging classes in C++ as extensions from C structs - the simple understanding is that C is a subset of C++, which is the case (otherwise C++ compiler wouldnt be able to compile C). Other lanugages implemented different notations and design ideas - C++ was an extension of an already heavily used language (having its roots back in the early days of programming). .. Its not long.. its just started .. :-) |
| ||
| Not sure why OOP is a paradigm when its modeled after the realworld. Heck, most man-made creations are modeled after the real-world. Anyhows, any thoughts on OOPM? Object-Oriented Project Managment? |
| ||
| Id really like to know how OGL suddenly became oo? You're right. It didn't. My bad. Since SGI made it 20 odd years ago, its been about as C as you can get. SGI did not make it 20 years ago (they made it in 1992). And DX (esp from 5 onwards) has a well defined OO background - especially being derived from COM (OO!). What do you mean by "well defined OO background" and "derived from COM"? Please elaborate. I was under the impression that COM was a technology, and it did not nessecarilly require object orientation (you can for instance program COM+ applications in C). Also, OO doesnt define unit testing AFAIK Unit test is an activity in Extreme Programming, an OO methodology. By all means tho' point me in the direction of a unit test framework that doesn't work with classes. I'm not sure what they taught you at Uni. you can unit test Forth, but I doubt too many would call Forth oo, same goes with ASM, or pretty much any langauge. Perhaps you care to provide an example of this? Alberto is fair in judging classes in C++ as extensions from C structs No he isn't, because they aren't. Classes where invented 5 years before C was even written. Simula from 1967 uses classes, as does SmallTalk from 1971. Early versions of C where written in 1972 (and at the time was probably only available to Dennis Ritchie and Ken Thompson). C++ was an extension of an already heavily used language (having its roots back in the early days of programming). Except according to Bjarne Stroustup (the "inventor" of C with Classes, later C++) C++ was designed as a mix between the usability and flexibility of Simula67, and the raw speed and power of C - because Simula67 was, not fast enough for what Mr. Stroustrup wanted to use it for. So no, classes where not "the natural evolution of structs". They where invented half a decade earlier, and by the time Stroustrup had finished on preliminary verions of C++ (1980), object oriented programming languages had exsisted for more than 20 years. The only reason C became more popular was because a compiler for it was distributed with Unix (System I-V) and BSD. Not sure why OOP is a paradigm when its modeled after the realworld. Huh? What definition of paradigm are you going by? Object-Oriented Project Managment? Dunno, never tried it. Got linkage? |
| ||
| Unit testing is an idea that predates Extreme Programming, but has been adopted by it. The idea is simply to write code or a script that can be used with a given code component that exercises it and verifies that it works according to spec. This is perfectly possible to do in any programming language and has nothing to do with (pro or con) OO programming. http://en.wikipedia.org/wiki/Unit_test Object-Oriented languages, in general, range from "Procedural Languages with Classes and Inheritance" through to "Everything, absolutely everything, is an object, including the runtime-environment and the debugger" languages such as Smalltalk. At the left side of the scale (and C++ is a bloated example of this) you essentially get identical (run-time) performance to procedural languages (since you're still using a procedural language) with the option of using inheritance and polymorphism to simplify your code. At the right end of the scale you tend to see dramatic benefits on the programmer productivity side and dramatic declines on the raw performance side. (Smalltalk is damn slow.) So to address the original topic: Opinions on object oriented programming -- I think that the OO approach taken with BlitzMax is a no-lose situation. You're not giving anything up (don't like objects? don't use them). We can debate the merits of moving further to the right on the scale (since most of what we do with BlitzMax is being done by libraries of compiled code or graphics hardware, the raw performance of the language itself is possibly not that important), but the OO implementation in Max is costing us nothing. |
| ||
| I'm still trying to get the hang of OOP, but so far so good. I must say that the tutorials helped me a lot in creating something to start with. At first when looking at the code on some small OOP applications it seemed clear to me, but after trying to start from scratch to see if I can use objects in a new project I was confused about how the variables worked and it took me a long time before the application would start without giving me some kind of error message... But after a while I finally got the hang of it and I must say that it saves a lot of time creating a game with lots of the same type of units when used correctly. Just enter the rules on what that unit needs to do when created... :-) The only thing I am still trying to find out is how I can speed up the game I'm creating. I know it has something to do with checking all possible collisions... But I will first read some more tutorials on that first before asking any stupid questions. :-P |
| ||
| I'm really not sure that oop is the ideal way of doing things. In some ways procedural was lacking but in some ways oop is lacking too. It's really a change in mindset (or paradigm) in thinking about things and structuring their relationships. It is pretty nice to modularize things and keep related things in the same place, but to do it strictly breaks down a number of more efficient ways of doing things. I don't want all my `objects` to be so separate that they barely talk to each other and have to do all kinds of formalities just to relay information back and forth. I am trying to design a game engine and make it sort of oop-ish to have objects and flexibility with them, so that it looks like each item is a separate entity, but separation is not a good foundation. The reality of the world is founded on separation ideas so maybe a separation-based paradigm is a good reflection of `life situations`, but at the same time I do not think this necessarily means that this solves problems in the most elegant or efficient way. The universe is just a big dream and who would want to use that for their inspiration when you have a clean and beautiful alternative? I prefer to look upon these paradigms and decide where i want to use oop and where i want to use procedural and where i want to put boundaries and when i want to follow rules and when i don't. That is more encompassing and inclusive and efficient to me. |
| ||
| At some point in the (hopefully near) future I intend to learn Lisp. From my brief introduction to functional programming, it seems like the most powerful programming paradigm available - especially in a language like Lisp where the line between code and data is so thin. I'd suggest looking into Lisp Daniel, or even Lua. I'm trying my hand at learning Lua (to use as a scripting language for my MUD server) and finding it to be extremely powerful. In fact, it's hard to imagine how to utilize some of it's features when you come from a statically typed background like I do. Despite the fact that Lua itself doesn't offer a wealth of libraries, the language design should inspire you or at the least, give you some ideas for your own language implementation. |
| ||
| This is kind of a silly thread. With that said, a healthy amount of OOP is a better way to program than straight procedural. Anyone who says otherwise does not fully understand OOP. |
| ||
| functional programming is really powerfull but for programmers of "regular" languages its hell to learn and get used to it and many many hairs will have to suffer until you are able to program anywhere even near as easy and fast as with procedural or OO ... (I had my fun with prolog and haskell ...) |
| ||
| Hello. Ultimately, non-procedural and non-oop languages are going to be faster. They're just not as maintainable/future proof or as easy to code, and will generally have a larger footprint. Of course, as more development time is spent on refining the compilers, and offering better optimisations, for a particular paradigm then the differences in speed should reduce. Abstraction of coding techniques is not, in the first instance, about making executables run faster it's about providing a more understandable paradigm within which to develop. Different strokes for different folks, I guess. Also, a lot of the time it's going to be dependant upon what you're trying to acheive. List manipulation is preferable using something like LISP because it's an abstraction compatible with the problem domain. Goodbye. |
| ||
| With that said, a healthy amount of OOP is a better way to program than straight procedural. It is absurd to suggest that one programming paradigm is "better" than another. Better at what? |
| ||
| It's clear what OOP is. it's cyngus worst nightmare. Flameduck, it's clearly better...anyone who thinks otherwise is living in the past and probably thinks kirk is a better captain than picard. I laugh at them, and I laugh at you. Hah! |
| ||
| OOP makes sense the way I have seen it used in BlitzMax. However, I think a lot of C/C++ programmers go overboard with it. Considering that it takes a team of C/C++ programmers to do what one BlitzMax programmer can do, I think there's something to that. |
| ||
| I think it is a little bit stupid to make a war, asking if it is better to program OO or proceduraly. If the way you build your logical structures in your mind is OO, then you should program OO. If your logical constructions are, like in a lot of cases, sequental algorithms, you should program using procedures. the best choice is always the choice that fits your needs best. There's also a third way of programing, what I would call mixed OO programming, lots of programers use it. they build a huge procedure that deals with little classes, and they get very interesting results. For my personal way of coding, I preffer OO programing, it helps me a lot on maintenance and bugfixing, and development is faster; but you know, that's my personal choice. |
| ||
| It is absurd to suggest that one programming paradigm is "better" than another. Better at what? Better at organizing code, easier function manipulation...etc I programmed for years proceduraly before I finally got OOP. Do you guys know of some crazy procedural techniques that I never knew about? Because from my point of view, it's messy, illogical and innefficient by comparison. You are right though, Ziggy and Flameduck, it doesn't matter what you want to program with. BUT this thread was created for the sole purpose of discussing this. So, here and now, it's fine to debate it. If the way you build your logical structures in your mind is OO, then you should program OO. If your logical constructions are, like in a lot of cases, sequental algorithms... You sound like you're saying OOP code has no procedural elements to it at all! What do you mean by that quote? What kind of crazy OOP have you seen that has no procedural elements to it? |
| ||
| Well we have languages like C and Java where you don't get a choice of how you program, but luckily for us, in BlitzMax, you have the choice to program however you want. Some tasks are better suited for one type than the other, but BlitzMax was made to allow each individual programmer to decide for themselves the way they want to program. That's why BlitzMax is such a great language. |
| ||
| I agree with Leadwerks, that C++ is definitely "over the top" especially as too much freedom is granted to the user. Not because freedom is bad, but because freedom means more hacks as well and less clear and enforced common structure. For that reason, my top OO language is Eiffel (its definitely the best. The only language I know which has export and access settings for any method *ie you can fully specify which class is able to access this query, method or function. All and none are possible as well* if you need it. And full redefine, undefine, rename machnism with fully featured inheritance which means you can inherit from any type of class *abstract or implementation, just not final*. something no other language even offers). After Eiffel, I rate C# and Java the best. Mainly C# before Java, because Java isn't that suited for games due to its structure. But beside that its surely a nice language as well. C++ might have been nice years ago, but it somehow missed the point where stability and safeness became the most important part of a software, not pure hack and optimation possibilities ... but after all, thats the Linux paradigma, so it isn't its own fault. It just never had a reason to evolve. MS and Apple have their own safe OO C derivates so unless you are a Linux user, forget about pure C++ if you are just starting. Use Managed C++, perhaps better C# or on Apple objective C |
| ||
| it's clearly better...anyone who thinks otherwise is living in the past and probably thinks kirk is a better captain than picard. That's a postulate, not an arguement. Because from my point of view, it's messy, illogical and innefficient by comparison. So it's really just better from your point of view. Which was my point to start with. Saying paradigm x is better than paradigm y is absurd, because it's subjective. You're argumentation should be more objective, along the lines of "using the OO paradigm lets you develop software on a higher abstraction level, which means you can solve more complex problems in a shorter time". |
| ||
| > Saying paradigm x is better than paradigm y is absurd With the exception of Spaghetti code vs just about anything else of course. On the serious side I use a mix of procedural and OO styles. Some things lend themselves to a procedural approach and some to OO. |
| ||
| I think oop is pretty nice for organizing thoughts and related things and keeping things tidy and modular, which is all to do with spacial organization really, but I think it falls short sometimes in terms of organizing time. It almost seems like saying "ok, organize everything based on spacial relations, and never mind how long it takes to process". Or maybe I don't `get it` yet. It's definitely easier to structure a larger app with some types version the old procedural method which is too `locked in`. Oop at least lets you put the boundaries where you want them. |
| ||
| a third way of programing, what I would call mixed OO programming, lots of programers use it. they build a huge procedure that deals with little classes, and they get very interesting results. In the software world we usually call "interesting results" incorrect, unpredictable, or buggy. I've heard it said that if you have a procedure longer than about 10 lines you need to rethink it: it's probably better if you refactor it out to several procedures that are easier to modify independent of the whole. Okay, so take that a tiny bit further and attach the global data to each piece of code that deals with it. What have you got now? That's right. An object. So that "huge procedure" that is undoubtedly unmanageable by anyone other than the guy who wrote it, has become smaller more manageable objects. Anyone can come in and work on one of those objects / pieces of code and adjust it. As long as the interface to the object remains the same, it will not affect the rest of the system. |
| ||
| Oops! (pun intended) I have a procedure that's at least a few thousand lines long. :-D |
| ||
| I tend to think off OOP as a way to simulate or model something, as long as I keep it simple and don't get too drawn into using loads of design-patterns where they aren't needed then OOP allows me to build up quickly a model of a system or game! When you start adding lots of layers of indirection and generalise things down to their common denominators it can get either too complex or more elegant. For me it usually ends up too complex! |
| ||
| The way I like to think about OOP is to break it down into 3 categories. 1. Encapsulation- This is my favorite. Type Declarations bundle up an abstract concept neatly and keep it tidy fromthe rest of my code. Done Right, it's reusable and clean. 2. Composition- I like to build my types out of other types 3. Polymorphism- I try to program to a supertype whenever it makes sense. |
| ||
| OOP in BlitzMax is very much simpler and easy to understand than traditional languages even tough it's same. I am one day old BlitzMax licensed user :) nice to meet you all. Tin |
| ||
| You're welcome! |
| ||
| OOP is the only way for many things, BUT when people start talking about supertypes and serializing/deserializing objects, you know they are full of sh*t. My most complex hierarchy is like this: TEntity TLight Extends TEntity TPointLight Extends TLight TSpotLight Extends TLight TDirectionalLight Extends TLight Any programmer who gets more complicated than that is just masturbating on company time. |
| ||
| OOP is the only way for many things, BUT when people start talking about supertypes and serializing/deserializing objects, you know they are full of sh*t. Anyone who writes their objects out to disk and loads them back in again is full of it? Or only if they use one word where six would do? |
| ||
| The simplest way to grasp OO btw is to start with it on realworld abstraction. Lets take a simple DVD player with a power button, a forward, backward, stop, pause and play and a tray button, as well as a tray and a display. If you think about that in realworld, its an object. Within software it is as well. And anything I mentioned above would be an object as well, that is stored within the DVD player. So you would have 7 additional fields of class "Button" within your DVD Player class and one field of class "DigitalDisplay" and one of class "DVDTray". As they are all distinct objects, you can easily program the different behaviors within the different classes. The interaction would be handled normally through the listener / subscriber pattern on the DVDPlayer class. I hope this makes sense but if you start to dissect realworld objects like that instead of thinking within your game code etc, you will get the basics and feel for it so much faster, given you have the needed talent for abstract thinking (otherwise drop the idea of OO, its hard to impossible for you to get it, abstraction is the most important thing you must have for it) for those interested, have a look if you can find the script "touch of class" from betrand meyer for the computer science course "Einführung in die Programmierung" at www.ethz.ch He has some very simple but out of my sight very ice breaking examples to see how the OO abstraction works basically etc |
| ||
| No, I know a lot of people who automatically serialize stuff, so they don't actually have a defined file format...it just changes every time they change the code. I remember a story about the Torque engine, where a butterfly model was flying around and landed on a gun, and then picked it up and started hauling it around. This was not by design, it was due to higher-up behaviors in the object hierarchy. That is a good example of OOP gone mad. |
| ||
| The issue I have with both procedural and object-oriented is that really they are two sides of the same coin. Making stuff object oriented tends to separate everything out into exclusive objects which while possibly mapping well to most of the physical world (avoiding the world `real` here), it does not necessarily represent unification well, and neither does procedural. I don't exactly know what a better way would be but I can see that separating everything into objects doesn't always solve all problems. |
| ||
| No, I know a lot of people who automatically serialize stuff, so they don't actually have a defined file format...it just changes every time they change the code. I do that. What's wrong with it? It means I can go back and change things at a really low level without having to change any code in my load and save functions. I'd hate to have to go and manually change the format every time I realized I needed to have some new data. |
| ||
| ImaginaryHuman: Well, with reflection you can actually get around some of this "enforced seperation" by dynamically merging data etc. It surely is a complex thing and very error prone from the professional point of view (where the separation is desired as it is the only way to have at least the slightest chance to guarantee correct behavior) |
| ||
| Any programmer who gets more complicated than that is just... Well, that's just bollocks, really, and typical of something spoken by those who don't know any better. I guess Abstraction is some other perverse thing that should be avoided? Right. Obviously, in a lot of cases you will only want one or two levels of generalisation. But sometimes you need more... Object EventHandler Window Control ControlWithItems ComboBox Why? Because each class looks after its own specific functionality, which is inherited by its children. And this is the mind-blowing thing to grasp.... it does away with code-duplication. I know, isn't it amazing? Rather than have the same code copied all over the place doing essentially the same thing in different types, you can actually localise those bits of code and share them. Next we'll be hearing that database normalization is for crazy people.... |
| ||
| I don't see how this classes relate to a dependency chain. EventHandler is no Gadget, its a "delegate". And the controlWithItems would be useless as well, a control should, if it is a contrainer, have a child list. I agree that 2 levels is to little, but actually there are definitely users that totally overdue it as well as too much extension does not help, often decoration is much more powerfull and flexible. BM has some very interesting internal classes that show how to use this mechanism usefully like the streamwrapper class which is extended by others. And an article like that can only come from someone with no pure indepth OO knowledge like a C++ programmer. I know quite some of them due to study and for some reason they always fall back to procedural the moment they face a problem that needs some real indepth OO knowledge ( -> patterns ) to solve intead of hacking. the "Contradiction Leads to Confusion" is the largest joke I've heard since a long time. Even 1 semester students in computational science know WHY it must be like that if you want error free code. And some of them don't even know how to write a hello world where you can input your name! But for those that don't know it: The idea is that you rely on fixed functionality which is clear specified on its functionality and interface. You can rely on this and that it does what it is meant to. But you must not know (-> use ) its inner working, there is no reason to, as you wanted to use the functionality, not its implementation. Reason is that the implementation can change and by only using the functionality you ensure that other code is unaffected by it in the meaning of "you don't need to alter other code as well" the moment you behave like that "great writer", you are doomed on the long sight as it will be impossible to work like that on a larger scale software codebase. without OO, todays largescale software systems would be impossible, no mather how cleanly you would program. Clean and stable multithreading would be even less possible, as the most powerfull mechanisms (monitor and the like) rely on objects, not on variable locks which are to easy to break. the best one was that: A frequent argument for OOP is it helps with code reusability, but one can reuse code without OOP—often by simply copying and pasting. Welcome to the world of a real noob |
| ||
| Can we punish that tin fellow for resurrecting this dead thread? |
| ||
| I remember a story about the Torque engine, where a butterfly model was flying around and landed on a gun, and then picked it up and started hauling it around. This was not by design, it was due to higher-up behaviors in the object hierarchy. That is a good example of OOP gone mad. That's just funny. I wouldn't say it's gone mad though, simply a case where the butterfly shouldn't be able to weild a weapon. It should be lower on the chain.
Creature
- WeaponWielder
- Player
- Enemy
- Animal
- Butterfly
Anyway I vote for a stay of the punishment since this was a funny little anecdote. |
| ||
| It's really handy but some people get obsessed, overuse (or misuse) it and make a nightmare for themselves. I have read books on OO that sound almost like religious texts. For myself I just fell into using it with BlitMax and thought yeah this isn't bad. |
| ||
| The thing that I don't like about OOP is that you have to hard code types of things. Tutorials are like, have a ship type that extends into a fighter type, and crusier type etc. Or I talk about a game and people are like have goblins inheret from blah blahh. Well what if I don't want to have "fighters" and "goblins" in my code. |
| ||
| ... then you don't create them. Not sure what your point is. |
| ||
| The reason people get so worked up about OOP is the same reason people get so worked up about Linux: It's time-consuming, tedious, and inefficient. That means job security. |
| ||
| Linux? liez. |
| ||
| I just wanted to rant. |
| ||
| I'm curious as to how procedural programmers typically do things. Do you not use types/structs/classes and objects at all? What do you do, make a bunch of different arrays to store different values for your entities and such? For me, OOP is only valuable so long as it improves my efficiency, and as such I don't typically use its more advanced features in most situations. But the basic idea of having objects of a defined type is invaluable to me. Couldn't live without it. |
| ||
| You can't do without OOP, but it's just that a lot pf programmers make it way too abstract and complicated. |
   |