Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

tl;dr - OO design, modeling, hierarchy ... all dependent on your situation. OO: Learn it, love it, add it to your toolset, but don't assume all problems are the nails to its hammer.

First thought: don't provide scaling methods - that's an operation best left to non-method functions or procedures. We scale lots of shapes in lots of ways that can make their original names less applicable.

After that, I started considering the models and their respective inheritance. If we expect the programming organizational structure to match the geometric organizational structure (e.g. circles are ellipses with the same axial lengths), then we might be thinking about the problem the wrong way. Do we model the hierarchy on the Real World or in a way that makes more sense in our library? I suppose it depends entirely on our purposes.

Sure, a circle's requirements for state are less than an ellipse, but it won't hurt to just draw a circle based on that additional state. Even the circumference and area formulas work out fine. So why, if I'm not coding for an resource-limited environment, am I creating a circle class anyway? They're all elipses anyway.



Alternative moral of the story: Mutation complicates things.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: