February 16th, 2016, 3:09 pm
QuoteOriginally posted by: outrunQuoteOriginally posted by: Traden4AlphaBTW:1. Circles have well defined states and behaviors for radius and diameter, Ellipses do not.2. Ellipses are not flattened circles when it comes to approximating the object with a set of OpenGL line segments or triangles.Perhaps one of the biggest problems with the OOP approach is that it's easy to think X IS-A Y during the initial phases of design only to discover later that X IS-NOT-A Y due to some more subtle property, corner case, or secondary requirement. Maybe OOP should be avoided until version 2.0 when the domain is sufficiently well understood for creating a valid class hierarchy.Yes, it's taught that way, every educational OO book starts with some real-world object (like a DVD player) and then start modelling it with objects. OO is however not about real-world objects, it's a set of programming language tools, just like the tools in your regular toolbox (quantum correlator, geiger counter, superconducting magnetic plasma stabelizer etc) . I won't go and try to capture the real world relations and proxy those in code because that's most of the times that's not what the task is. You much better of decomposing a problem into algorithms and datastructures (the core business of computers: compute and proccess data) that are centered around objectives and requirements. A circle would probably better be named (or even better tagged) a "rotationInvariantObject" because that directly maps in a relevant way to operations that need to be performed on it.Exactly! It's a tool that may be good/bad, cost efficient/inefficient, orfragile/robust depending of the top-level requirements and context.One issue is that very large systems inevitably end up turning into a set of parallel development projects which then seems to require decomposition of the system into things and encapsulation of the data and code for each of those things. That, by itself, doesn't make OOP the right approach.But then comes the realization that sometimes two or more things have similar data structures and similar algorithms although perhaps the numbers of things and complexity of those things is too large for one person or team to write all the code for all the things. Those numerous and complex things might be physical objects (e.g., the data and code needed to work with each of a large number of different models of webcam) or logical things (e.g., the data and code needed to work with a different statistical distributions). Moreover, in the context of development, it's nice to create some baseline generic code that provides some functionality for some of the things for early alpha versions of the system with some efficient way of extending/specializing the data and code to cover more of the things (i.e., inheritance).One issue with the circle-ellipse example is that it is too simple to benefit from full blown OOP. It seems like more hassle than it's worth.(BTW a circle is not rotationally invariant in 3 or more dimensions.)