sco08y wrote:
But object-oriented ideas are a bit loopy.
Take inheritance as an example. Or look at the way C++ and languages that borrow from C++ readily convolve physical representation with logical meaning, largely due to the fact that C++ inherited C's style of programming just above assembler.
I don't see this a a problem with OOP per se, as much as a problem with the way most programming languages have implemented Inheritance as inheritance by extension.
Under Java (for example) if you define class Circle as inheriting from class Ellipse, you are effectively stating, "<i>A Circle has all the attributes of an Ellipse, plus zero or more new new attributes</i>". On the other hand, it is also possible to define Inheritance as inheritance by restriction, which allows you to say "<i>A Circle has all the attributes of an Ellipse, subject to these constraints</i>". XML Schema is a good example of restriction-type inheritance.
Mapping between the two systems can be difficult and is certainly not one-to-one. This is one reason why SOAP is moving from a RPC model to a Document exchange model. It's rather easier to develop a loosely coupled document processing service than it is to try an map your entire public API to XML in a platform-independent fashion.
Quote:
Tamayo wrote:
Use the tool appropriate to the job. C++ is a tool, and for certain tasks, it is appropriate. It could be a better tool, yes; but it works. For tasks outside its purview, though, other tools are far better.
I think the biggest issue we face is when OOP concepts popularized by C++ are being used in enterprise systems.
The issue is that enterprise systems need to define their business logic, that is, define the structure of information and the dynamics of information and the ways in which huamsn are to interact with the system.
Again, how is this an OOP problem? If programmers habitually ignore Model-View-Controller separation, is that really a fault of the language?
As far as enterprise systems go, I'm currently working on a J2EE* framework. Everything falls out into separate pieces rather nicely. Business logic and transaction entry points in one place (Session beans), Event handler in another, Persistent Data in a third (Entity Beans) and an ephemeral data model shared with the client for easy communication.
I don't see how this is a problem unless you want to try and tie everything into one giant object model or something.
--------------
*I do, in fact, like the majority of the J2EE architecture. The implementation of certain pieces is kind of crappy (HAY GUYS LETS USE XML DESCRIPTORS TO AVOID STATIC CODE CHECKING) and some pieces probably should not be built using Java/XML, but the majority of the framework is insanely useful for building server-type systems.