Timeline for Convert procedural code to object oriented
Current License: CC BY-SA 3.0
12 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 24, 2014 at 22:41 | vote | accept | Lorenz Meyer | ||
| Nov 20, 2014 at 13:11 | comment | added | Doc Brown | @LorenzMeyer: nethertheless I think you are seeing things too "black-and-white". I wrote OO style programs for data processing in Perl several years ago. From that experience I can tell you, though there is a little bit additional overhead, you can still get a lot of benefits from the dynamic nature of that language and implement some parts very generically. | |
| Nov 20, 2014 at 13:03 | comment | added | Doc Brown | @LorenzMeyer: you are correct - when your primary goal is to write some small tools for dynamic data processing, the "classic OO approach" is often less efficient than a generic, dynamic approach. That's why dynamic languages like Perl, Python, Javascript or (ugh) PHP are so popular. However, if you are writing bigger programs, where the individual business logic of each object is more important, incorporating "classic OO" starts to pay off. | |
| Nov 19, 2014 at 18:45 | vote | accept | Lorenz Meyer | ||
| Nov 20, 2014 at 6:28 | |||||
| Nov 19, 2014 at 16:47 | comment | added | Lorenz Meyer | 3. Often I only need id, name and customer number. Sometimes I need the complete address, and sometimes even more detailed data. How can a data object account for this ? On the other hand, the SQL-associative array programming model handles all these cases easily. | |
| Nov 19, 2014 at 16:46 | comment | added | Lorenz Meyer | I see at least 3 points where dealing with data objects is more difficult than its array counterpart : 1. The customer's properties are already defined in the database. I have to define them again as class members. 2. I need a factory that can create the objects in batch mode ( one SQL query for many entities ), and one for single object instantiation. | |
| Nov 19, 2014 at 7:41 | history | edited | Doc Brown | CC BY-SA 3.0 |
clarified answer after comment
|
| Nov 19, 2014 at 7:10 | comment | added | Doc Brown | @LorenzMeyer: a "search" function is probably not well suited inside the customer object - that was exactly the point in my posting, not "a contradiction", please read my answer again. A "CustomerFactory" maybe a better place, indeed. An "associative array, bound together with a collection of methods for the business rules" is exactly how object orientation is implemented in some languages - to implement this again "manually" when the programming language has in-built OO support is typically more overhead than to use the OO features of the language directly. | |
| Nov 19, 2014 at 7:03 | comment | added | Lorenz Meyer | This rises another question : why is it better to have a customer data object rather than an associative array and a collection of methods that enforces its consistency with business rules ? Clearly, while everybody favors object oriented programming, it looks just like a huge overhead to me. | |
| Nov 19, 2014 at 6:53 | comment | added | Lorenz Meyer | There is a contradiction : since the search could yield several customers, it should return a collection of customer objects. As such search cannot be a method of the customer object. This means that there should coexist a customer object representing the row in the database and the real life person, and a CustomerController that allows to do stuff with a group of customers. | |
| Nov 18, 2014 at 21:54 | history | edited | Doc Brown | CC BY-SA 3.0 |
added 8 characters in body
|
| Nov 18, 2014 at 21:49 | history | answered | Doc Brown | CC BY-SA 3.0 |