IS A vrs Contains A
BlitzMax Forums/BlitzMax Beginners Area/IS A vrs Contains A
| ||
| Explanation of “IS A” rather than “contains A” (or "Has A") Im going to make type BOX Type Box Field Size:int EndTypeAnd a type present Type Present Field Cost:Long ‘Rich Parents EndTypeNow my birthday gift "is a" box "containing a" present. Type BirthDayGift extend Box Field APresent:Present EndTypeNow I go to the post office and I pass my BirthDayGift to their Box weighing machine. Function BoxWeighingMachine:int(ABOX:Box) .. Return Weight EndFunctionThe man doesn’t say “That’s not a BOX, because it “IS A” box. it’s a box that contains a present I go back the next day with a faulty good to return Type FaultyGoodReturn Extends Box Field FaultyGood:String EndTypeAnd again it is passed to the weighing machine, because Its still “A BOX” @CS_TBL, I posted it here as it wasnt really part of that thread |
| ||
| Isn't it really a matter of strong vs. weak associations? If something "is a" then that represents a composition. For instance a triangle is a composition of points. If the Triangle is destroyed, so are it's points. If something "contains a" that represents and aggregation. Were this the triangle from above, the points would still exist independantly if the triangle is destroyed because it is a stronger binding. |
| ||
| Yes but, the type cannot be 3 "Is A" things. If any function or list is expecting a point, than passing it a triangle (in this case) would, and should fail. Because a triangle isnt a point What the triangle is, "IS A" list of three points, so I could inherit from a type of "grouped" points, called shape for example. Then any function that requires a shape, could be passed a triangle directly, because a triangle, if inheretid from shape, "IS A" shape Its not important if they exist or not. It more of a "If I asked bob to pass me a XXXX, and he passed me YYYY, are they the same. If I (As a function) wanted some nuts, but was passed a nut revel. Is that a sweet that contains a nut. Or is it a nut with some chocolate? If I inheret Nut Revel from the base Nut, then I can passit directly to functions wanting nuts. Equaly if I wanted to inheret form type sweet, then I could pass the field of the nut to the nut functions, but not the whole revel (Flame I posted this on request to explain what I ment when I said "IS A" as apposed to "Contains A") Its my fun thing otm ;) |
| ||
| On your "Is A" explanation: it's typically the kind of explanation that hits the rocks here .. all c++ books I have (well, ok, 2 books :P) start talking about these realworld situations when they try to explain OO. To me this never worked, I prefer code-jargon, not talks about dishwashers and animals.. :P So, no matter how long I stare at your post office, it goes [-> o_O] and [O_o ->] :P (sorry :D) I was trying to come up with some example code which works fine without any OO (that's what took so long), was too lazy to finish it.. I've more hobbies than just blitz'ing :P meanwhile, this is an interesting read. http://www.geocities.com/tablizer/myths.htm and http://www.geocities.com/tablizer/oopbad.htm and http://www.softpanorama.org/SE/anti_oo.shtml I had a talk with a coder (system, libraries, applications, c64 stuff, hardware, audio, everything) and he could come up with 1/0 reasons why inheritence is bad.. maybe I should just post a bit o' irc-log.. :P Don't mind the language, he's a Czech, which means only half his words are bugfree, I think most ppl should be able to follow it.. with a little fantasy .. ^_^ ok, I have base class A it's "visual" object, usually having "x,y,color" then I will do B from A and 'B' will be image 'drawing' thing. so, it autoamtically have x,y & color. 1. what happends, when 'B' don't need ANY color ? or colro is fixed ? Why it have 'color' attribute then ? (waste memory, break clean object attribs) 2. I have my 'own' system, which do something. I have 'myClass' and 'myClass2'. I want myClass2 to support 'image' - how ? I can't derive from '2' basic classes ! (the only lang can do it is c++ and it brings nmany problems). Delphi (pascal), c#, java , ... none of this langs support derive from 2 ancestors (he can argue only by interfaces, which are *NOT* deriving - even C++ can implement interfaces on deriving layer - but jsut because yuou can have 2 paretnts - and as I say, no other lang is known to me :) 3. what happends, when I will add in MY object "rotation" - and later, in new version, author of original base class will also add "rotation" - to *ALL* objects -> it will conflict with my own declaration and program will stop work 4. what will happen, when multiple 'version' need to be used as DLL's ? This is not big problems for interpretting langauges, but for c/c++ like langs this is killer problem - all versions need to be EXACLY the same 5. if object needs 10 colors, you can't just use 'color cols[10]' because you need to fuck around with 'color' - many other part of system could reference 'color' -> another complication 6. with deriving, you have no control over usage of yourself - any1 can override methods, change things, ... -> in longer time terms (more ppl, bigger projects) -> problems [and some pubpic/private/... is *NOT* enough !) 7. sharing variables is very dumb - if you expect somethign to be nto change during 'some call' - you can't rely on that... and you have no control -> the bst way for deriving is to not share varaibles - but jsut methods (some programmers using derivating acknowledge this is to be the only good practive) -> you lost one of biggest advantages of deriving ------ ------ ------ ------ imagine you have 'file' class it ahve methods like read write you know, file is *SLOW*. so, I will do type cached_file Extends File; and now I will show you, how easily inheritance goes to ass. I defined some methods which 'enahce' file about 'cache' eg,. you called "read" it reads BLOCK from 'base' class and 'reads' from that 'cache' so, both objects have 'read' but cached_file read reads jsut 'aray' and if array is 'empty' then it calls 'read' of basic class (file) everything works fine. but there are 2 problems: (big one) let's say I will add NEW method to 'file' - eg. "search" it searchs file and set position to 'some' specified place. but I dodn't modify "cached_file" so what happends ? base class searchs & seek but 'cached_file' didn't update it's buffer. so, if you use 'cached_file.find' (which you have from base class !) your code no longer works. another problem is, if you use 'cached_stream' as "base" class. and do base.read which METHOD will be called ? cached_file.read _or_ file.read this is BIG problem./ this one can be solved - usually using 'virtual' methods (here you can see, it REQUIRE special implementaion frmo language !!!) and first problem ? can't be solved ! and this is the most pissed thing on deriving: if you setup 'base' classes - you can't change them too much anymore...... you never know, how ppl use you. so, if you are the only programmer, do not share anything, deriving could be acceptable options. in any other ways, deriving failures for MANY reasons. note that I can't really comment on inheritence, it's not my thing.. so these are his words, if someone reacts I'll redirect him to this thread and post the reply.. (can't BRL have something like inviting ppl, who don't need to buy a product to join here, for the sake of interesting'ness) |
| ||
| Some previous discussion here in my early Max days (not that I've learnt much since either). |
| ||
| I only used the real world example so that the code I posted would be smaller. As a real programming example here. I have a class TLED. Which is a single colour shape to be drawn on the screen OK so with this object I want to make a number display, now a number display "Contains" TLED. Its not an "Is A" realationship, at best its an "Are some" realationship so the TLEDs need to be Fields As you can see I need to provide a draw routine for the number, which fair enough just call the TLED draw What I also have is "Aliens","Mothership","PlayerUnit" etc Now each of these is also made of an TLED, which again I could just put as a field of the type. However I have said that the AlienLED for example, IS an LED. What Im am doing is defineing the most basic things LEDs need, and then inhereted these to make each of the subsequent types. As you can see I dont have to worry about all that changecolour or rotation crap, because the TLEDAlien already has them (from TLED), I could easyerly make it a field, and then either write draw calls that call the fields draw, or call the fields draw directly. BUT TLedAlien.draw and TLed.Draw, are the same routine, so no extra work there Your Points 1) If B doesnt need any colour, then you shouldnt try and inheret from a class that has colour. (This is a planing problem, not an inherent problem with Inhereting) 2) Type A Type b extens A Type c extends B 3) a) they are my base objects, so Iam the author, and I dont do that (well not very often) b) Unless the rotation method is really stupidly done, you can just override it 4) Dont know. I wouldnt know how to do that in any languge. But my understanding is that its the interface of the object that is important, and that has no relation to inheriting or not. Its surly, (If a problem at all), a problem about compilation 5) I have no idea what hes trying to say? If an object needed 10 colours, it needs 10 colours. (I think this was an argumnet used against useing types at all, rather than an argument against inheriting) 6) Errr and, thats not an arugument against you useing inhereting, is againt letting anyone else inhereting your stuff. 7) Is that about "Unions" cos it is totaly irrelivent to inhereting. Again I think that was an argument against types full stop. And that entire monologue. He just need to learn how to use super. The entire monolouge is infact againt overriding in inhereted classes, and not inhereting in of itself EDIT: In fact after reading you post again, and flash scanning the links, I think that your stance is against OOP, and not against inhereting. |
| ||
| his reply and his multiple typos ^_^ : >1) If B doesnt need any colour, then you shouldnt try and inheret from >a class that has colour. (This is a planing problem, not an inherent >problem with Inhereting) I am working and I was on various projects. From smaller to bigger ones (100K+lines - tenths MB's of source coud). I never saw system (design) where was possible to create 'clean' design, just because you fall down into huge tree structures. Deriving is always about form of compromise. You can't easily add 'fields per fields' and 'method per method' in tree of classes. >2) Type A >Type b extens A >Type c extends B Don't work - you need "Type XX extends B,my_own". As I say, the only lang (from mainstream) who support multiple ancestor I know is C++, where it btings many problem in imp[lementation (VTBL offest, moved 'this' accross method calls, multiple method bodies across classes, ...) >3) a) they are my base objects, so Iam the author, and I dont do that >(well not very option) >b) Unless the rotation method is really stupidly doen, you can just >override it Sure, I can override, but if someone extend MY class - it could count with ORIGINAL 'rotation'. This is really common problem, and if you know a bit C# versioning, you can check how deep this problemis in real projects. I don't know other lang than C# who solves this problem generally. And I agree - (a) is not a option. >4) Dont know. I wouldnt know how to do that in any languge. >But my understanding is that its the interface of the object that >is inportant, and that has no relation to inheriting or not. Its >surly, (If a problem at all), a problem about compilation There is a implementation layer problem. Generally only byte-code and interpreted langs could solve the problem. In C/C++/... and other 'compiled' languages you are strating having troubles with field aligemnt, method offsets, etc. (I mean 'real' ones). >5) I have no idea what hes trying to say? If an object needed 10 >colours, it needs 10 colours. (I think this was an argumnet used >against useing types at all, rather than an argument against >inheriting) I want to say, that any 'ancestor' or 'other' objects could assume I am working with field 'Color' - but I am not using it. I have 'Colors[10]' array. So, I have to use 'Color' and 'Color[9]' which complicates code a bit (note: this is from real projects, where because of deriving was ppl forced to create various 'stubs' just to make other classea around happy with presumtions). >6) Errr and, thats not an arugument against you useing inhereting, is againt >letting anyone else inhereting your stuff. That's a BIG argument. As author of some 'stuff' I need control usage of it. Many problems are caused by non-planned features/behaviours, which are not initially planned. If other starts using them as 'features' - you have to accept it or break the system. Deriving don't give you control about methods - that they will be called as YOU expect. Eg. if I will do method, which is allowed to derive, but you define, user have to call base one, you have *NO* control, it will work that way. So, it is not forcing ppl to use only for things you designed system for, but force them to use WAY yuo expected/design. >7) Is that about "Unions" cos it is totaly irrelivent to inhereting. >?Again >I think that was an argument against types full stop. This is. Inheriting typically says facts about speed, usability etc. It holds only if you share variables. As I say, many OOP programmer (generally) don't use sharing variables (for that reasons). It's again about control. You can assume, that some varaible is CONSTANT during some algorihm. If you call user event/callback somewhere inside, variable may be changed. our algo can goes to hell. Sure - you don't need to share variables and use 'methods' - where you HAVE control over own internal state, but then you loose one of most nicest thing on deriving - speed & simplicty. With sharing methods only, you are more near compoennt based programming. There are several way, which way one can write code. There are many articles about OOP, COP, procedural etc. I don't know any mainstream lang, which implements OOP (generally) way, I would like & use (and company here). In most cases, well written procedural programming could be faster, better & more ready for futre than typical OOP. With OOP you have no control over your own usage. If tenths various ppl uses your classes, you need to have control. Not about 'where' and 'for' they use you, but if they use you as YOU EXPECT. THat's why where are many things like COM, COM+, DCOM, CORBA and many many other system, which are mainly about deffinig COMUNICATION - rules. Not just giving your own internal state into hands of others. I saw too much projects in state, where no-one was really abble to change some of base classes. Because if you will do that - other will stop work. And yes, I am "typical OOP" sceptic and I don't like it :) As someone, who talk with CS_TBL about these things, I tried to explain him another ways how to work. I fyou are intereating, you could take a look at some other ppl with similar meanign like me. Personal note: he tries to do so since 1999 orso, I just mess around with code like Dory swims ... "just keep swimmin' just keep swimmin' just keep swimmin' swimmin' swimmin' what do we do we swim" Whatever I discovered have been my own discoveries, just by swimming and not listening to anyone ^_^ |
| ||
| There not typos. Typos are when you know what letter to type, but you hit the wrong one. What I have is a problem with knowing what letter to hit. ;) a) I dissagree here totaly. (Or rather I agree totaly). I dont think this is OOP or inheretence or the like problem, this is a "Thats the way it is" problem. But again, I feel Im defending inhereting, and your attacking deriving. b) I agree, we do need multiple inhereting c) Here is were we diverge as to what we are as programmers. Im a lone programmer. No one but me as access to my types. (You maybe right in a big organisation) d) Again, cannot see relevence to problem. e) Ahh, this is the same as the second codebox, simply dont inheret in this situation. This tho is not a problem with inhereting, just an indicator that you should derive f) Ok I see your point. But its a point for a stronger keyword "Final" than against inhereting g) Ahh, yes ok is see what you mean. But isnt that a problem in any language that allows me to pass a pointer to the variable? (Or to the type) If this was a disscussion about to use object or not, then I would hardly mention inhereting at all. It isnt about that. Its a, "If you are useing OOP", should you use inhereting Whislt your points might be hard to rebuke in the first argument, they are not relevent if you do concider that is a disscuion for "after" you have desided to oop. |
| ||
| I tried to explain him another ways how to work Could you elaborate on that? I would like to know how you generaly would "setup" a program. Using types with just fields, global functions and no global variables? I know one can use different aproaches to a programming-enviroment, and one is not necessarialy better than the other? Please give me your view on that. |
| ||
| his reply: >There not typos. Typos are when you know what letter to type, but you >hit the wrong one. What I have is a problem with knowing what letter to >hit. ;) I do both :) Sometimes I don't know exact spelling even @ my native lang, which is pretty "crazy"... >a) I dissagree here totaly. (Or rather I agree totaly). I dont think >this is OOP or inheretence or the like problem, this is a "Thats the >way it is" problem. But again, I feel Im defending inhereting, and your >attacking deriving. Basically yes. OOP is 'geneal' term, and it was used by me and CS in 'deriving' context. I think it is most used (or most seen meaning). Generally, OOP could be reprezsnted by: - procedural programming - asm - inheriting and tree of classes - components .... Many other things. Sure, orthodox "OOP" ppl will completely disagree here (talking about security/encasing of members, ...). But generally OOP could mean anything. Its' (at my opinion) way of coding, rather some concrete language/syntax/... I hate deriving. On the other side, I approve some other OOP ways. On the other side - I prefer procedural OOP rather pure deriving & tree of classes. >b) I agree, we do need multiple inhereting Never say this ahead of orthodox OOP ppl :) They could kill you for that. Multiple inheriting brings many many implementation problems. If you know a bit C++ compilers (generated code, how it works), you know, how complicated are 'virtual' members, virtual ancestor (versus non-virtual ones). You could check typical C++ streams - ios etc. Their implementation (from deriving POV) really SUX. And generated code is also much more complicated, than using 'standard' ancestor - these thigns need to use "virtual ancestor" (this is C++ terminology, but it means, there is "more" ways how to derive) >c) Here is were we diverge as to what we are as programmers. Im a lone >programmer. No one but me as access to my types. (You maybe right in a >big organisation) Sure. What is good for one, doesn't need to be good for others. But... I personally think, that even for one, another ways of doing "OOP" could save many lines of code -> time. >d) Again, cannot see relevence to problem. You will feel the problem, when your system will support 3D and you will have to do millions operations per seconds. Until you have just hundreds sprites on screen, you don't feel difference. When you will start doing transformations, ... in more complicated scene, you may start feel how things are implemented. I wanted to say, that at certain point you are starting feel with "compiler" (interpreter...). There are thing, which can't be processed simpler/easier. >e) Ahh, this is the same as the second codebox, simply dont inheret in >this situation. This tho is not a problem with inhereting, just an >indicator that you should derive If I will not inherit, I can't use other things. And it sux. While you inherit, you can't "select" what you wish to inherit, what to inherit but process by yourself (but let ancestor freely use), etc. And it is the point. You are pretty limited. You have no control/selection. That's why nearly every 'deriving' based system tracks many unneeded things. Or because you don't need 1 feature, you will not derive and lost 10 other ? >f) Ok I see your point. But its a point for a stronger keyword "Final" >than against inhereting Not really. Final doesnt' help. Try to think about few "use cases". And if you started using 'final' - you break inheriting principles. With inheriting - you could use final everywhere then :) No really, really few langs could solve this issue, even not using inheriting. With inheriting, this issue just raise 10x more. >g) Ahh, yes ok is see what you mean. But isnt that a problem in any >language that allows me to pass a pointer to the variable? (Or to the >type) You don't need pointer to raise that problem. But allowing 'remember' instance (store pointer) also raise this problem. Like previous - with inheritance this issue is 10x raised. Nevertheless, many of inheriting troubles could be found in other langs - even they don't have inheriting by itselfs. >If this was a disscussion about to use object or not, then I would >hardly mention inhereting at all. It isnt about that. Its a, "If you >are useing OOP", should you use inhereting As I explained, I used OOP in most used term - inheriting. When OOP was "discovered", one of most propagated advantages *IS* inheriting. Check any book for Java, C#, C++, ... any OOP-like lang (I used like, because none of these lang is *really* OOP in right word of meaning) promote inheriting. One of "most used" features. So, that's why me (and also many others) use OOP very often as synonym for inheriting. >Whislt your points might be hard to rebuke in the first argument, they >are not relevent if you do concider that is a disscuion for "after" you >have desided to oop. What I discussed with CS wan't "procedural OOP" but "component based programming" - which is pretty different in designing/thinking from inheriting-OOP. There is not much languages, which creates good enviroment for COP. There are few things, like COM/COM+/DCOM, which are hacked "C" basically. Few better (CORBA, ...) but none really COP. It's like saying C++ (or Blitz) to be real OOP. Both langs are far from being OOP. If so, you will end up in languages like LIST and >Could you elaborate on that? I would like to know how you generaly >would "setup" a program. >Using types with just fields, global functions and no global variables? >I know one can use different aproaches to a programming-enviroment, and >one is not necessarialy better than the other? >Please give me your view on that. As I explained, it wasn't really against OOP - but against deriving based OOP. Every language I know (even strict OOP) have 'global' variable. At least instance of process itselfs. It have to work that way, until OS will be completly OOP. And still you will end up in global/static instances, because you have just 1 CPU, etc. My personal view on OOP (deriving based) is very similar to ppl, which wrote articles I posted somewhere above. There are many common "lies" regarding OOP. I am personally into clean component worlds. Components is not component in view of class (eg. TComponent in Delphi and similar enviroments), but it defines something, what could internally contain anything (you don't care) and you communicate throw known interfaces. It it not just list of methods, like interface in most component OOP (COM, java, C#...). It much more. It setup of rules, when/what/who/how. Mapping of methods and objects is 'internal' thing of given component, and you have no way how to review that. You don't need to. Components allow mass code-reusing, without poke along history rock. You can easily implement caching/streams (somewhere above I posted small use-case). Many ppl call that aspect oriented programming (http://aosd.net) but this is just a small part of it. Also, I don't see objects as 'this' instance. I see objects as tree structure itself (you could have 3 'this'). There are many things I see different from many other ppl. It's another story, and if we want to seriously discuss that, it could be very long thread. To be open, there is not yet any language, which fit all me needs. That's one of reasons I wrote 'hack' for C++, which creates something like COM+, but pretty different way. But still it's far from ideal state. So, in the way, I started in free time doing own small project, which can prove or destroy what I am saying. Many ppl I have talekd about that goes with me, because these problem I am talking about are pretty common. So, there is really many things I see differently, nut just deriving. But deriving it 'top pissed feature' in OOP I think. I there will be some vote about "Worst OOP programming way", I will put my 10 cents for deriving, as it is implemented in most languages (delphi, blitz, c#, java....). |
| ||
| Yes but, the type cannot be 3 "Is A" things. Why not? If any function or list is expecting a point, than passing it a triangle (in this case) would, and should fail. No. That's what you have your composite pattern for. So that you don't have to care whether you component is a single object, or a collection of objects. If I inheret Nut Revel from the base Nut, then I can passit directly to functions wanting nuts. Equaly if I wanted to inheret form type sweet, then I could pass the field of the nut to the nut functions, but not the whole revel That sounds much too convoluted, and unmaintainable IMHO. No offense. meanwhile, this is an interesting read. Yeah. It's always interesting to read people trying to bash something they don't understand. Why it have 'color' attribute then ? How else would you know WHICH color it is? 2. I have my 'own' system, which do something. I have 'myClass' and 'myClass2'. I want myClass2 to support 'image' - how ? Interfaces and/or composite objects. How exactly is situation dependant. 3. what happends, when I will add in MY object "rotation" - and later, in new version, author of original base class will also add "rotation" - to *ALL* objects -> it will conflict with my own declaration and program will stop work Lack of functioning version control is not a problem specific to OOP. 4. what will happen, when multiple 'version' need to be used as DLL's ? DLL Hell. Oddly, this is actually a symptom of not using OOP. If you have a well defined Interface, than the program shouldn't care less how the underlying implementation. If it does, your implementation is not OO. 5. if object needs 10 colors, you can't just use 'color cols[10]' because you need to fuck around with 'color' - many other part of system could reference 'color' -> another complication That's just rediculous. What would an object need 10 arbitrary colors for? 6. with deriving, you have no control over usage of yourself - any1 can override methods, change things, ... -> in longer time terms (more ppl, bigger projects) -> problems [and some pubpic/private/... is *NOT* enough !) But Final is. Besides which, since your object is ofcourse encapsulated, it doesn't matter whether someone else extends it. you lost one of biggest advantages of deriving Because having the ability to cause spectacular random concurrent access violation crashes on multiple Core systems - is definatelky an advantage. Right? I mean end users really enjoy programs crashing for no real reason at all.While I'm sure your friend is quite the talented programmer, he obviously has not understood the purpose of Object Orientation. The purpose of OO is Abstraction and Encapsulation. Inheritance is a powerfull tool. I'd like to see someone write an easy to use composite pattern model without it. Ugh. |
| ||
| Yes but, the type cannot be 3 "Is A" things Why not?Dont be so enigmatic in your replies. If I say it cannot, and you think it can, then post it, so then I know it can as well "IS A" = extened "Contains A" = Has the fields I dont know how to have more than one extends. Type TType extends a,b,c maybe? If any function or list is expecting a point, than passing it a triangle (in this case) would, and should fail. No. That's what you have your composite pattern for. So that you don't have to care whether you component is a single object, or a collection of objects.Well your just wrong here. If you wanted to say. Yes, H&K thats right, but what you would do is use a composite pattern. So that you don't have to care whether you component is a single object, or a collection of objects. Then you would be right. But "If any function or list is expecting a point, than passing it a triangle (in this case) would, and should fail. is correct. Fair enough on the revel example. It really needs diagrams (I wasnt saying have both, I was saying pick one) |
| ||
| ..hmmm - more oo arguments - seems people are more obsessed with writing oo code that fits some pre-defined "perfect concept" - than actually using it as a tool.. Dont get me wrong, there are of course good and bad ways of going about doing things, but i think it needs to looked at within a specific context..not jst some generic this is good that is bad approach... ISa sorry..i know thats not really what your talking about.. but all im saying is that sometimes its good to mix and match oop with conventional procedural techniques to avoid a tonne of cumbersome wrapping... im not convinced having classes for everything is a good idea..a collection of points forming tris, might be better stored as an array of floats..not a collection of points.. heh, anyway - thats jst my pointless thinkings on this ;) |
| ||
| Yet another reply... let's keep 'em coming ^_^ >3. what happends, when I will add in MY object "rotation" - and later, >in new version, author of original base class will also add "rotation" >- to *ALL* objects -> it will conflict with my own declaration and >program will stop work >Lack of functioning version control is not a problem specific to OOP. In deriving based OOP this problem is much bigger than in anything else. >4. what will happen, when multiple 'version' need to be used as DLL's ? >DLL Hell. Oddly, this is actually a symptom of not using OOP. If you >have a well defined Interface, than the program shouldn't care less how >the underlying implementation. If it does, your implementation is not >OO. Same like [3] >5. if object needs 10 colors, you can't just use 'color cols[10]' >because you need to fuck around with 'color' - many other part of >system could reference 'color' -> another complication >That's just rediculous. What would an object need 10 arbitrary colors >for? Why you should expect anything, while base class ? In typical deriving base OOP you have to do that -> one of reasons, why system is bas all (meaning deriving). >6. with deriving, you have no control over usage of yourself - any1 can >override methods, change things, ... -> in longer time terms (more ppl, >bigger projects) -> problems [and some pubpic/private/... is *NOT* >enough !) >But Final is. Besides which, since your object is ofcourse >encapsulated, it doesn't matter whether someone else extends it. It's like [5]. If you started using finals, why someone should derive then ? Class with finals is more like interface -> ot';s mroe object assembly, than deriving. In more similar examples, you can see, how deriving failures - whole "idea" do that. You have to use final, to prevent troubles (or explicitly use "friend" class names), you have to ask "why someone need something" - because you designed system "some way" and any other is .... >you lost one of biggest advantages of deriving >Because having the ability to cause spectacular random concurrent >access violation crashes on multiple Core systems - is definatelky an >advantage. Right? I mean end users really enjoy programs crashing for >no real reason at all. > >While I'm sure your friend is quite the talented programmer, he >obviously has not understood the purpose of Object Orientation. The >purpose of OO is Abstraction and Encapsulation. Inheritance is a >powerfull tool. I'd like to see someone write an easy to use composite >pattern model without it. Ugh. Just note: as I allready explained, OOP was used mainly in menaing of deriving based OOP (most used way @ (at least this) world). I don't know if I am talented programmer, but regarding this topic, I already wrote few langs (including typical OOP-deriving based, from interpreted up to real compiled), wrote hacks to other compilers, etc. So, I think, I have some experience. I can't judge how big unfortunately :) Whole deriving based OOP tends into troubles, you named (as argument for d-OOP side) few of them. This is like alternate and allopath medicine (easter/western). If you have some problem, western medicine, in most cases, will cure tokens. On the other side, if you have pain in legs, why someone should cure liver ? (jsut example :) Small count (at least here) from allopath medicine tries to find illness origin. Similar with deriving OOP. There is many problems (I am not saying, other system don't have any), like we was talking about. Look at modern lags. Many ppl should learn form chinese-like thinking in medicine. If there is some pain, it's not (in most cases) best way to minimize it's show. Like - OOP tends to have history rock problems - like: 1. member names (adding later on childs/parents/...) 2. impossibility to change anything, coz you risc system failuring 3. redundant members, which are used in SOME 'childs' and ancestor CAN work this them ... So, instead of trying to minimize this problem (on lang/design layer), MS (and others) found solution: HUGE versioning system, which could solve all these illness. But it doesn't mean, you have better system. You just have way, how to cut down impact of that. Similar to other things. Sure, you can find similar problems in other OOP too, or non-OOP. But in deriving OOP, all problems, we were talking about are biggest ones. This thread have one small problem: if discussing ppl never meet deriving OOP based project, in size (at least) ~tenths of thousands lines with hundreds classes, they will probably never see these points. At certain point, I belive every1 will see. I guess you know refactoring. It's another 'nice' thing, how to make results "better" while keeping system bad :) Refactoring could also repair many things, but it just minimizes fallenness... It doesn't cure. Like CS. Until he wrote code (1 file) up to 5K lines, he was "lazy" to do many things, which you should expect to be in code. At certain point, he found, that it's not possible to remember everything. He wishes to reuse some portions of code... He found, simulating 'instances' throw array wasn't soo clever as it looks in the beginning :) That's why he stared this thread. But before ? He would never belive you or me :) Or me, when I was starting programming (asm @ C64 - nice machine :) I was same like he was. It was long time ago.. At certain point I changed my mind. And srated writing code to be 'readable' - I found my brain is to weak to remember all in ASM files, which had 20.000 lines... Same happends later with deriving based OOP. I love it :) Really. Until first big project grows, grows, more and more ppl have to work, ... Even I was 'more open' at that time already, as far as we reach point of no return, I have preferred deriving based OOP. It becomes slowly.... It happens -8 years ago if I remember well. So, that's why these kind of threads are long and both sides need to have mind open to "different" things - if not, we will cycle around few points, like happen here. ------------------- ------------------- Note: the instances in an array is long ago, pre-Blitzplus even. The problem I have is that I'm usually the user of my own tools, so because of creative reasons I tend to rush things in order to be able to use it yesterday. And since those tools are unique in some way, I can't use alternatives. Since B+ I hid my stuff privately in banks, and since BMax I hide them in types. |
| ||
| Question: So no matter how well I think Ive programed, and no matter how well namedspaced everything is, I will reach a point were I will wish that I hadnt Derived any classes at all? Retoric: Whats the alternitive? No classes, well thats just stupid, and I am not going to believe that ever. One seperate class for each variable structure I want? This would be more work, and to be honest I again wont do it. If a want a variable structue with one more variable than a structure I already have, then I am definatly either extending the first structure or "field"ing it. One Giant calss with redundent variables, capible of being all my variable structures? Well thats spectrum basic, in reality no types at all. I apprechiate all your strong opinions about the problems of oop, and extending in particular, but I think you are simply highlighting pitfalls that can then be avoided, as apposed to showing an unpassable chasim in the road. I also think that there are alternative solutions to programing that dont require oop, but to say that because oop isnt perfect you shoudnt use it, is illadvised. On the westen/easten medicine thing, the west has always tried to fix the body, whilst the east has always tried to keep the body from needing fixing. In the end a best system would include them both? (Bear in mind I have not been saying you "should" inheret all the time, yet you have been saying you should never, and you see that the analogy supports my stance) Have a go at the retoric if you want, but the question is what needs anwsering. (I got a bit carried away, and the question seemed to take second place, but it isnt) |
   |