26 Mar, 2010, flumpy wrote in the 102nd comment:
Tyche said:
I think it's a safe bet that the World is an Object regardless of whether it manages spells.
flumpy said:
Basiy what it boils down to is is-a over has-a again. If you put the spell logic and data into world you are saying that World is-a spell manager.
I think it's a safe bet that the World is an Object regardless of whether it manages spells.
Well I guess that truism is, er, true enough.. Is this alluding to Shas's "it's not OO" comment?
26 Mar, 2010, Deimos wrote in the 103rd comment:
flumpy said:
Basiy what it boils down to is is-a over has-a again. If you put the spell logic and data into world you are saying that World is-a spell manager.
I agree, and that's exactly what I'm saying. I don't see any reason why it shouldn't be the spell manager. If you pull this out into a SpellManager class, but you have multiple spell classifications, should you then also have SpellManager composition InvocationManager, CurseManager, and ProjectileManager? And from there should you have InvocationManager composition FireInvocationManager, WaterInvocationManager, etc.? Where does the arbitrary abstraction end?
flumpy said:
Normalisation groups data together logically (account data in one table and address data in another) joined by keys. There is no other reason for doing this at 3rd normal form other than the logical grouping of information: if you go further than 3rd or 4th normal form you could end up partitioning vertically, but I do not understand why this is wrong, only applicable under different circumstances.
Vertically partitioning a table would drop you below 3rd normal form. That's why it's called de-normalization. It is "wrong" only if you do it for no functional reason. Most of the time tables are partitioned like this to separate static and dynamic data to increase query performance (because normalization is inefficient for large data sets - see: Google's BigTable). You're sacrificing normalization for performance, which is an acceptable trade-off. In our case, making the separation between World and things like SpellManager comes with no functional benefit.
flumpy said:
Yes, you "should" (in quotes, because "it depends"). It is far harder to re-factor code and can become much more difficult to understand what the object is actually doing if you are mixing functionality together like this in a single class. IMHO it is more ridiculous for a World object to deal with spells than a SpellManager delegate, because logically the methods and data have nothing to do with pure World functions.
How is it mixing functionality? For it to be mixing functionality, you would have to actually answer the question I asked - what are you proposing that World actually do? If you're suggesting that everything be pulled out into its own _____Manager class, then I wasn't too far off with my ManagerManager joke.
flumpy said:
But that's not to say it isn't a hard and fast rule, you should use composition when you feel like your objects are becoming too multifaceted or when you require object reuse. I often build objects that initially perform most tasks themselves, and when I hit a scenario where I have to reuse the code only then move the methods and data into a second.
Well, now I'm confused. Are you saying that you would incorporate this functionality into World until you had a functional reason to pull it out? If so, that's what I've been suggesting all along…
26 Mar, 2010, David Haley wrote in the 104th comment:
Incidentally, singleton objects that don't store state might as well be just namespaces: there isn't any reason to use objects per se in these cases. Grouping functionality isn't exactly an OO-exclusive concept. If the spell management stuff becomes large, and the movement management stuff becomes large, it would make sense anyhow to treat these separately, whether or not you do it with objects.
26 Mar, 2010, flumpy wrote in the 105th comment:
Deimos said:
Well, now I'm confused. Are you saying that you would incorporate this functionality into World until you had a functional reason to pull it out? If so, that's what I've been suggesting all along…
Yes.
It is not wrong, unless it becomes wrong.
Generally it's "Good Practice" to think ahead about when you might reuse this code, especially if you are building a framework or library or something that will be used by others, as I was saying earlier. It's not as wrong to do what you're doing as Shas seems to think it is, but I never said myself that it was.
A practical example of something where a "spellmanager" type object would be needed to be reused is if you want a mob to use spells and not be a mage class. You can emulate mage like behaviour perhaps without the need for the mob to actually be a mage, and separating the object out prematurely meets the need for that future requirement. I am assuming here that the world object is checking the spells that the mob would have, and then invoking the spell casting logic. If you separate the two out, leaving the checks in the World object and the spell functionality in the SpellManager, you can pre-emptively allow this sort of behaviour.
Either way, as I say, it depends.
26 Mar, 2010, David Haley wrote in the 106th comment:
flumpy said:
A practical example of something where a "spellmanager" type object would be needed to be reused is if you want a mob to use spells and not be a mage class. You can emulate mage like behaviour perhaps without the need for the mob to actually be a mage, and separating the object out prematurely meets the need for that future requirement. I am assuming here that the world object is checking the spells that the mob would have, and then invoking the spell casting logic. If you separate the two out, leaving the checks in the World object and the spell functionality in the SpellManager, you can pre-emptively allow this sort of behaviour.
Honestly I don't understand how this example demonstrates that not separating the logic prevents NPCs from casting spells without being mages. I mean, you kind of assumed a contrived problem in order to demonstrate that you should separate the logic. There's no reason for the world to not internally separate checking and executing a spell as well. Or, you might as well assume that the spell manager also occasionally checks that people have enough mana, spells memorized, or whatever.
26 Mar, 2010, flumpy wrote in the 107th comment:
Deimos said:
How is it mixing functionality? For it to be mixing functionality, you would have to actually answer the question I asked - what are you proposing that World actually do? If you're suggesting that everything be pulled out into its own _____Manager class, then I wasn't too far off with my ManagerManager joke.
Conceptually, the data and functionality of the two objects do not belong together in any way any more than "account" and "address" would in the same database table.
In another way, the world isn't actually magical, it has magic. It also has players, it has items, and so on. In a similar vain a weapon is not an item, an item has attributes of a weapon. Read the composition thread, I've already hinted at it.
However you want to do it, it's your system. You have a better understanding of what "World" means in your terms than anyone else does, so only you can actually make that decision…
26 Mar, 2010, flumpy wrote in the 108th comment:
David Haley said:
Honestly I don't understand how this example demonstrates that not separating the logic prevents NPCs from casting spells without being mages. I mean, you kind of assumed a contrived problem in order to demonstrate that you should separate the logic. There's no reason for the world to not internally separate checking and executing a spell as well. Or, you might as well assume that the spell manager also occasionally checks that people have enough mana, spells memorized, or whatever.
flumpy said:
A practical example of something where a "spellmanager" type object would be needed to be reused is if you want a mob to use spells and not be a mage class. You can emulate mage like behaviour perhaps without the need for the mob to actually be a mage, and separating the object out prematurely meets the need for that future requirement. I am assuming here that the world object is checking the spells that the mob would have, and then invoking the spell casting logic. If you separate the two out, leaving the checks in the World object and the spell functionality in the SpellManager, you can pre-emptively allow this sort of behaviour.
Honestly I don't understand how this example demonstrates that not separating the logic prevents NPCs from casting spells without being mages. I mean, you kind of assumed a contrived problem in order to demonstrate that you should separate the logic. There's no reason for the world to not internally separate checking and executing a spell as well. Or, you might as well assume that the spell manager also occasionally checks that people have enough mana, spells memorized, or whatever.
It was an example, sure. Whatever, if you were the one asking for advise I'd spend my time answering you, but, you're not. So, whatever DH.
As I have said 1000 times now, it is a concept, a useful concept, and you can surely understand that. Stop being picky.
26 Mar, 2010, flumpy wrote in the 109th comment:
Deimos said:
I agree, and that's exactly what I'm saying. I don't see any reason why it shouldn't be the spell manager. If you pull this out into a SpellManager class, but you have multiple spell classifications, should you then also have SpellManager composition InvocationManager, CurseManager, and ProjectileManager? And from there should you have InvocationManager composition FireInvocationManager, WaterInvocationManager, etc.? Where does the arbitrary abstraction end?
flumpy said:
Basiy what it boils down to is is-a over has-a again. If you put the spell logic and data into world you are saying that World is-a spell manager.
I agree, and that's exactly what I'm saying. I don't see any reason why it shouldn't be the spell manager. If you pull this out into a SpellManager class, but you have multiple spell classifications, should you then also have SpellManager composition InvocationManager, CurseManager, and ProjectileManager? And from there should you have InvocationManager composition FireInvocationManager, WaterInvocationManager, etc.? Where does the arbitrary abstraction end?
To answer this part of your question to me, I would guess there'd be other better ways of doing this than abstracting to individual delegates. Like anything it's not a hammer that fits all nails.
My initial thoughts, off the top of my head, would be to chain some spellhandlers together (each that do different checks for the spells or mana operations) together that execute in order so the spell can be cast. However, I'm not designing this system, and I am unaware of your particular context.
26 Mar, 2010, David Haley wrote in the 110th comment:
flumpy said:
It was an example, sure. Whatever, if you were the one asking for advise I'd spend my time answering you, but, you're not. So, whatever DH.
As I have said 1000 times now, it is a concept, a useful concept, and you can surely understand that. Stop being picky.
David Haley said:
Honestly I don't understand how this example demonstrates that not separating the logic prevents NPCs from casting spells without being mages. I mean, you kind of assumed a contrived problem in order to demonstrate that you should separate the logic. There's no reason for the world to not internally separate checking and executing a spell as well. Or, you might as well assume that the spell manager also occasionally checks that people have enough mana, spells memorized, or whatever.
It was an example, sure. Whatever, if you were the one asking for advise I'd spend my time answering you, but, you're not. So, whatever DH.
As I have said 1000 times now, it is a concept, a useful concept, and you can surely understand that. Stop being picky.
Touchy, are we? I'm asking you the same questions Deimos is. It is a useful concept in general, but honestly your explanation here doesn't make at all clear why it's a useful concept. I remain wholly unconvinced by your arguments that it's important here. If you're trying to make a general statement that encapsulation is useful, we all already agree on that. But that's not all that you're trying to say. You've been arguing that it's likely that Deimos is incorrect to not want all these Managers floating around because it makes things "better". But when pressed for reasons on why this is better, you give answers not related to OOP per se but merely clean separation of functionality: something that can happen whether or not you have all these manager objects.
BTW, why are you answering his same post three times?
26 Mar, 2010, quixadhal wrote in the 111th comment:
One good rule of thumb is to abstract whenever something involves multiple things.
For example, if the only things in your game that move are characters (be they NPC's or Players), then movement logic can nicely sit within the Character object. However, if other things can move (vehicles, rooms, whatever), now that "Movement Manager" starts looking like a good thing, since you really don't want to have seperate code to handle the exact same tasks in half a dozen places. If you want that, go use a DikuMUD. *grin*
I think you asked a very good question. What *DOES* World do? Think about that. What things in your game really are worthy of being at that high a level? The first thing that comes to mind is weather or day/night cycles… yet if your world is large enough, those might vary by zone/region, and thus might be handled by the zone objects themselves (which may talk to their neighbors for consistency, or may talk to the "world" object and offset values from there). Clearly, the World can act as a ZoneManager, since it should contain all your zones. What else *should* it do?
For example, if the only things in your game that move are characters (be they NPC's or Players), then movement logic can nicely sit within the Character object. However, if other things can move (vehicles, rooms, whatever), now that "Movement Manager" starts looking like a good thing, since you really don't want to have seperate code to handle the exact same tasks in half a dozen places. If you want that, go use a DikuMUD. *grin*
I think you asked a very good question. What *DOES* World do? Think about that. What things in your game really are worthy of being at that high a level? The first thing that comes to mind is weather or day/night cycles… yet if your world is large enough, those might vary by zone/region, and thus might be handled by the zone objects themselves (which may talk to their neighbors for consistency, or may talk to the "world" object and offset values from there). Clearly, the World can act as a ZoneManager, since it should contain all your zones. What else *should* it do?
26 Mar, 2010, flumpy wrote in the 112th comment:
David Haley said:
Touchy, are we? I'm asking you the same questions Deimos is. It is a useful concept in general, but honestly your explanation here doesn't make at all clear why it's a useful concept. I remain wholly unconvinced by your arguments that it's important here. If you're trying to make a general statement that encapsulation is useful, we all already agree on that. But that's not all that you're trying to say. You've been arguing that it's likely that Deimos is incorrect to not want all these Managers floating around because it makes things "better". But when pressed for reasons on why this is better, you give answers not related to OOP per se but merely clean separation of functionality: something that can happen whether or not you have all these manager objects.
BTW, why are you answering his same post three times?
flumpy said:
It was an example, sure. Whatever, if you were the one asking for advise I'd spend my time answering you, but, you're not. So, whatever DH.
As I have said 1000 times now, it is a concept, a useful concept, and you can surely understand that. Stop being picky.
David Haley said:
Honestly I don't understand how this example demonstrates that not separating the logic prevents NPCs from casting spells without being mages. I mean, you kind of assumed a contrived problem in order to demonstrate that you should separate the logic. There's no reason for the world to not internally separate checking and executing a spell as well. Or, you might as well assume that the spell manager also occasionally checks that people have enough mana, spells memorized, or whatever.
It was an example, sure. Whatever, if you were the one asking for advise I'd spend my time answering you, but, you're not. So, whatever DH.
As I have said 1000 times now, it is a concept, a useful concept, and you can surely understand that. Stop being picky.
Touchy, are we? I'm asking you the same questions Deimos is. It is a useful concept in general, but honestly your explanation here doesn't make at all clear why it's a useful concept. I remain wholly unconvinced by your arguments that it's important here. If you're trying to make a general statement that encapsulation is useful, we all already agree on that. But that's not all that you're trying to say. You've been arguing that it's likely that Deimos is incorrect to not want all these Managers floating around because it makes things "better". But when pressed for reasons on why this is better, you give answers not related to OOP per se but merely clean separation of functionality: something that can happen whether or not you have all these manager objects.
BTW, why are you answering his same post three times?
Because he asked many different questions.
And if you would have actually read my reply properly, you would have seen me mention that it's not inherently bad, just good practice.
I think we're done here.
26 Mar, 2010, David Haley wrote in the 113th comment:
Saying that you shouldn't do something because it's better practice to do something else isn't too terribly different from saying that the other thing is in fact better. All I want from you is an explanation of why this must be done with objects and not standard, plain old decomposition. If you're going to preach about good practice, you should at least have an answer to why your solution is better practice than existing solutions. What aspect of using objects here is superior to using decomposition? This is not just about you and me, by the way: the forum involves many people, after all. :wink:
26 Mar, 2010, flumpy wrote in the 114th comment:
David Haley said:
Saying that you shouldn't do something because it's better practice to do something else isn't too terribly different from saying that the other thing is in fact better. All I want from you is an explanation of why this must be done with objects and not standard, plain old decomposition. If you're going to preach about good practice, you should at least have an answer to why your solution is better practice than existing solutions. What aspect of using objects here is superior to using decomposition? This is not just about you and me, by the way: the forum involves many people, after all. :wink:
I never said he shouldn't do it his way. I said:
flumpy said:
My own personal feeling is that 6 should be done by the SpellManager object rather than the World object, even if SpellManager is a delegate of World.
… as for the other stuff, I explained why it was good practice (not, as you misquote, better practice):
flumpy said:
A main tenet of OO is high cohesion, which this sort of operation if perfformed(sic) by a World object, could in effect lower. You are in effect mixing conceptually different data and behaviour together.
And..
flumpy said:
That aside, it's also easier to confuse others about the purpose of your object, which can lead to programming errors (like misunderstanding the meaning of a method name, for example) - I understand in this context it is an unlikely error, but as a general rule the principal of high cohesion is a good one because of the above and I'm sure a few other reasons too that have not come to mind.
Also, he seemed to be asking an OO design question, in which, in my opinion, he is questioning OO principles, and has never mentioned decomposition. If I were talking procedural programming techniques I might have mentioned decomposition, but we have not. So actually, I think decomposition is a red herring here. Neither is wrong, or superior, and I have never said it was in any way.
26 Mar, 2010, Deimos wrote in the 115th comment:
quixadhal said:
I think you asked a very good question. What *DOES* World do? Think about that. What things in your game really are worthy of being at that high a level? The first thing that comes to mind is weather or day/night cycles… yet if your world is large enough, those might vary by zone/region, and thus might be handled by the zone objects themselves (which may talk to their neighbors for consistency, or may talk to the "world" object and offset values from there). Clearly, the World can act as a ZoneManager, since it should contain all your zones. What else *should* it do?
What, no WeatherManager? :tongue:
Really, though, what's the difference in allowing World to act as a ZoneManager versus allowing it to act as a SpellManager?
flumpy said:
Also, he seemed to be asking an OO design question, in which, in my opinion, he is questioning OO principles, and has never mentioned decomposition.
Conceptual design and OO design are linked, but very different. There is no "one hammer for all nails", as you put it. My question is more of a "where do these things belong conceptually?" Is a spell part of the world? Is movement part of the world? This is not questioning OO principles in even the loosest sense of the term.
26 Mar, 2010, flumpy wrote in the 116th comment:
Deimos said:
Conceptual design and OO design are linked, but very different. There is no "one hammer for all nails", as you put it. My question is more of a "where do these things belong conceptually?" Is a spell part of the world? Is movement part of the world? This is not questioning OO principles in even the loosest sense of the term.
As you also point out, there are different ways to conceptually design something. If you want guidance, that is what we are giving; we each have different ways of doing things and I don't think there is any one "better" way. If you are looking for a "best" way, then, :shrug:, you're out of luck since "it depends".
26 Mar, 2010, David Haley wrote in the 117th comment:
flumpy said:
… as for the other stuff, I explained why it was good practice (not, as you misquote, better practice):
Heh, well, look. If somebody says something, and you say "Hey, why not do it this way instead", it's really all but explicit that you're saying your suggestion is a better way of doing it. If you're just saying random things as random good things to do without trying to say they're better, well, that's fine then.
flumpy said:
If you want guidance, that is what we are giving; we each have different ways of doing things and I don't think there is any one "better" way. If you are looking for a "best" way, then, :shrug:, you're out of luck since "it depends".
And that's precisely why it's useful to explain one's positions, instead of getting huffy when somebody asks for clarification because an example doesn't seem to actually address a point. :thinking:
26 Mar, 2010, flumpy wrote in the 118th comment:
David Haley said:
Heh, well, look. If somebody says something, and you say "Hey, why not do it this way instead"
.. again with the misquotes. I never said "Hey, why not do it this way". I actually said "I (from my own experience) would think about it this way because…". I also did not say "things at random", they were explaining the reasoning behind why I do things that way. If it were random, I'd be spouting off about functional decomposition or quantum physics. The subject had turned to specifically OO oriented concepts, and (although he now says otherwise) I thought he was looking for some guidance on how to think in an OO way. Honestly DH, you should take your own advice sometimes, this place is for others to learn too, and nothing I have said was off-topic wrt to organising a mud engine or library.
David Haley said:
And that's precisely why it's useful to explain one's positions, instead of getting huffy when somebody asks for clarification because an example doesn't seem to actually address a point. :thinking:
We've been here before, clarifying the obvious is not useful. Taking something out of context and saying "you are being unclear here" when actually it's not unclear at all in context is just being picky. I got huffy because you took what I said, changed it slightly enough to misquote my point, and then accused me of being unclear. I believe you genuinely believe that I was being unclear, but expect huffiness. Most of the time others can read between the lines of a post and fit it into general context, which is something you don't do well TBH.
Enough. We agree, decomposition AND composition can both solve the same problem in different ways. Well done us.
26 Mar, 2010, David Haley wrote in the 119th comment:
flumpy said:
I actually said "I (from my own experience) would think about it this way because…".
For the record, that is not what you actually said, unless you 'actually' said it using different words. If you're going to wave around misquoting, accusing me of changing your words, etc., then please use 'actual' quotations.
flumpy said:
I also did not say "things at random", they were explaining the reasoning behind why I do things that way.
And yet I asked you a fairly specific question, and you got fairly huffy and refused to explain your reasoning… forgive me if I'm a little confused here.
flumpy said:
and nothing I have said was off-topic wrt to organising a mud engine or library.
Agreed – nothing was off-topic. (Who said anything was?) All I'm asking for is more explanation… is that so terrible?
flumpy said:
Taking something out of context and saying "you are being unclear here" when actually it's not unclear at all is just being picky.
Well, if you insist by repeating that I'm being "picky" on "obvious" things, if anything is "not unclear at all" to me it's that you said something that makes little sense and seems rather wrong at worst and misleading at best. I'm sorry, but I don't view that as being picky.
Allow me to remind you that you started the post in question by saying that it's not wrong unless it becomes wrong. I am mystified as to why you think you weren't trying to introduce even the slightest bit of a suggestion as to a way to make things "right".
26 Mar, 2010, flumpy wrote in the 120th comment:
David Haley said:
Well, if you insist by repeating that I'm being "picky" on "obvious" things, if anything is "not unclear at all" to me it's that you said something that makes little sense and seems rather wrong at worst and misleading at best. I'm sorry, but I don't view that as being picky.
Allow me to remind you that you started the post in question by saying that it's not wrong unless it becomes wrong. I am mystified as to why you think you weren't trying to introduce even the slightest bit of a suggestion as to a way to make things "right".
flumpy said:
Taking something out of context and saying "you are being unclear here" when actually it's not unclear at all is just being picky.
Well, if you insist by repeating that I'm being "picky" on "obvious" things, if anything is "not unclear at all" to me it's that you said something that makes little sense and seems rather wrong at worst and misleading at best. I'm sorry, but I don't view that as being picky.
Allow me to remind you that you started the post in question by saying that it's not wrong unless it becomes wrong. I am mystified as to why you think you weren't trying to introduce even the slightest bit of a suggestion as to a way to make things "right".
Ok.. if you want clarification on that point (I thought I was perfectly clear about it, in numeral posts, but anyway) then here:
It is not wrong until it becomes wrong is a way to say that is is OK up until the point where you find yourself becoming hindered by your own code.
At that point, perhaps it is time to think about composition, amongst other patterns, to help you conceptually organise things. You can usually avoid all those situations where this could potentially happen by forward thinking these design patterns into your system design, thus avoiding painful situations of decoupling code.
It is equally NOT CORRECT to apply any of this in situations where this would make no difference. If you plan never to reuse the code you write anywhere else, there is no point in either decomposing it nor using composition on it. If you find yourself re-writing code you have implemented in another object, then perhaps think again, but until then…
I think it's a safe bet that the World is an Object regardless of whether it manages spells.