4 ms·

OOP philosophy is to turn concepts from your problem space into custom data types. The article suggests that this is not always the simplest and most practical

by Jare 14y ago

OOP philosophy is to turn concepts from your problem space into custom data types. The article suggests that this is not always the simplest and most practical way to architect every piece of your solution. That's all. The underlying reason is that data types must address (in some way) a number of requirements: copyability, management of owned resources, conversions, limits, etc. You need to take care of all that for every single custom data type you create, or your code will be a minefield of half-baked data types. This large base cost for data types in turn makes the classic 'divide and conquer' strategy for software development more costly, which triggers further practical problems with overgrown and over-engineered types.

mercurial 14y ago
> OOP philosophy is to turn concepts from your problem space into custom data types. I don't agree with this statement. Surely the use of structs in C, or records in Haskell, are not enough to turn them into object-oriented languages. And whatever language you end up using, you are going to end up with custom datatypes when attempting to solve non-trivial problems. Sure, simple data types are useful enough on their own. In languages supporting even basic pattern matching, I use tuples whenever I need to return more than one value for a function, and I'm not interested in reusing together elsewhere. But this does not scale to complex program and complex data types. And your custom data structures will need to support a number of operations (eg, comparison, etc...). I don't really see what this has to do with OOP per se.
- ajuc 14y ago
  Do we really need to reinvent these complex datatypes each time, thought? How many classes there exists in Java or C++ just to keep x,y and z coordinates of a point in 3d space? With custom types we gain the ability to distinguish color (r, g, b) from position (x, y, z), but is it worth the cost? How often do you catch errors like assigning point coordinates to a color? If you want to use library A that has Vector3d type defined with library B that uses library C that has Point3f class, and with graphic library that use its own Vertex class - isn't it stupid that we need to convert the data all the time? I've seen application in C++ that uses 4 types of string: QString, std::string, char* and custom type to pass data to database. 3 of them just because of used libraries. I think OOP mindest makes people whip their own datatypes too easily, and it hurts when you need to integrate libraries developed independently. Most of the time tuples, lists and hashmaps suffice, and in better languages you get many operations on you composite datatypes for free - for example serialization, deep copying and deep equality checking.
  - mercurial 14y ago
    Haskell has String, ByteString and Text :) Data type proliferation is not confined to object-oriented languages (actually, since datatypes are much easier and cheaper to build in functional languages, they're even more likely to occur within FP).
    - chousuke 14y ago
      The nice thing about Haskell is that you can have a million data types with different names, and as long as they're capable of implementing the type classes you are using, you can pretty much freely switch between the different underlying types. And if a library author doesn't provide an instance of a type class for the data type, you are still able to write one. In most OOP languages, you'd be forced to either monkey-patch the classes, or writing cumbersome wrappers.

by Jare 14y ago

mercurial 14y ago

> OOP philosophy is to turn concepts from your problem space into custom data types. I don't agree with this statement. Surely the use of structs in C, or records in Haskell, are not enough to turn them into object-oriented languages. And whatever language you end up using, you are going to end up with custom datatypes when attempting to solve non-trivial problems. Sure, simple data types are useful enough on their own. In languages supporting even basic pattern matching, I use tuples whenever I need to return more than one value for a function, and I'm not interested in reusing together elsewhere. But this does not scale to complex program and complex data types. And your custom data structures will need to support a number of operations (eg, comparison, etc...). I don't really see what this has to do with OOP per se.

ajuc 14y ago
Do we really need to reinvent these complex datatypes each time, thought? How many classes there exists in Java or C++ just to keep x,y and z coordinates of a point in 3d space? With custom types we gain the ability to distinguish color (r, g, b) from position (x, y, z), but is it worth the cost? How often do you catch errors like assigning point coordinates to a color? If you want to use library A that has Vector3d type defined with library B that uses library C that has Point3f class, and with graphic library that use its own Vertex class - isn't it stupid that we need to convert the data all the time? I've seen application in C++ that uses 4 types of string: QString, std::string, char* and custom type to pass data to database. 3 of them just because of used libraries. I think OOP mindest makes people whip their own datatypes too easily, and it hurts when you need to integrate libraries developed independently. Most of the time tuples, lists and hashmaps suffice, and in better languages you get many operations on you composite datatypes for free - for example serialization, deep copying and deep equality checking.
- mercurial 14y ago
  Haskell has String, ByteString and Text :) Data type proliferation is not confined to object-oriented languages (actually, since datatypes are much easier and cheaper to build in functional languages, they're even more likely to occur within FP).
  - chousuke 14y ago
    The nice thing about Haskell is that you can have a million data types with different names, and as long as they're capable of implementing the type classes you are using, you can pretty much freely switch between the different underlying types. And if a library author doesn't provide an instance of a type class for the data type, you are still able to write one. In most OOP languages, you'd be forced to either monkey-patch the classes, or writing cumbersome wrappers.