3 ms·

> but I'm not writing an API - I'm working in a living structure where the map format and drawing format may change from day to day, and I don't want to make up

> but I'm not writing an API - I'm working in a living structure where the map format and drawing format may change from day to day, and I don't want to make updates in half a dozen files if the rules for aiming change. I find that I am always writing APIs, and it's not always clear which is going to be 'public' or 'private'. That is, I generally work bottom-up, and my lower-level classes present a sensible API that I can work with directly, e.g. in irb. This makes the design of higher-level classes easier, if I've done the low-level API correctly. > I want a single "aim" method that behaves differently based on type. Hm, you mean like _char.aim_? Where char may be a Monster, Soldier, or ?

xsmasher 17y ago
>I find that I am always writing APIs, and it's not always clear which is going to be 'public' or 'private'. I understand the sentiment, and I believe in SOLID principles. I just mean that I'm not building a library that other people will use. No one is ever going to subclass my "player" class, not even me. Unlike my sound or graphics or AI code it's unlikely to be reused even in another game. >Hm, you mean like _char.aim_? Where char may be a Monster, Soldier, or ? Yes. My "aim" method is 90% identical for all types, about 10% specific to the type - if(type==monster){do this}; if(type==soldier){do that} I've heard "if you're using if statements like this you're probably not using OOP correctly", but in my case I don't want six nearly identical methods spread out in six class files. That's repeating myself, which is the real sin I'd rather avoid; it comes back to haunt me if the map format or some other data structure changes.