Moderator: General Moderators
requinix wrote:OOP or not, someone will either write good code or write bad code. Applies to coding in different languages too.
As for black boxes, it sounds to me like that someone doesn't quite realize how classes can be converted to and from sets of functions.
greyhoundcode wrote:What interests me here is working with existing code and stems from some amount of despair about how un-reusable many chunks of code are; really I was interested in discussing the human dimension of this and if OOP somehow engenders unnecessary complexity in the code of many programmers.
Benjamin wrote:I don't think the argument is or should be Procedural VS OOP. I think the issue is making best use of decomposition.
greyhoundcode wrote:I was reading an interesting interview with the creator of Erlang and something that was suggested was that OOP can lead to code being less rather than more re-usable, by virtue of the creation of highly specific "black boxes" which people are reluctant to tamper with.
Benjamin wrote:The problem with developers who seek perfection of re-useability and extendability is that they end up with codebases that are so complex and large that they are no longer practical.
I'm going to take a huge stab in the dark here and make a guess that you've never worked on a team of developers that actively collaborate with each other and with the client. By actively collaborate, I do mean they - the client - are involved in the development process as often as is humanly possible, not "here's the spec doc, see you in 6 months with the finished product."Benjamin wrote:greyhoundcode wrote:I was reading an interesting interview with the creator of Erlang and something that was suggested was that OOP can lead to code being less rather than more re-usable, by virtue of the creation of highly specific "black boxes" which people are reluctant to tamper with.
Ok, there are a lot of subjective things in that statement.
He hypothesized that OOP can lead to code being less re-usable. Less reusable than what other programming methodologies? How did he gauge how reusable the code was? How did he gauge how much of the code was reusable and how big was/were the codebase(s)? What language was he referring to?
He is comparing classes to "black boxes" and stated that people (assuming programmers) are "reluctant to tamper" with them.
... wow lots of chaos in that statement, let's go through it ...
- By "Black Box" one could assume he is referring to the entire class. I would say the class cannot be compared to a black box because it's very easy to read the code for a particular class. Whether the code is readable or not is another story, but that's not the point.
- He could have meant that the methods were black boxes which once again isn't accurate because it's easy to read the code.
- If he meant that the methods are black boxes because you don't know where else they are used in the codebase, one could easily use grep to find out.
- If he meant that the methods are black boxes because you don't know if they are used outside of the class itself, that's what public, private and protected are for.
- He stated that people are reluctant to tamper with the black boxes, but if the black boxes were reuseable, then why would one need to modify them in the first place?
- Further, when a method is written to perform a function, it should not matter to any outside caller how that function is accomplished, therefore why would it not be acceptable to make modifications (tamper)?
With all that said, what's the best way to reuse code?
My opinion is that when you are working on a codebase adding code, if you find something that has already been done, utilize decomposition by refactoring the code that can be reused. In other words if there is a method of some class that does something, and you create another class that needs to do the same thing, then the code should be moved from the first class to a location where it can be used from both classes. I think where developers get in trouble is when they want *everything* to be reusable and try to write the codebase with that mindset. That flat out doesn't work. It doesn't work because even if you did get it to work, you just doubled or tripled development costs. Then add in TDD. What you bid $10k I can do for $2k. You know damn well if there are any bugs the client will be the first to find them anyway, no matter how much testing you do. You can only minimize them.
The problem with developers who seek perfection of re-useability and extendability is that they end up with codebases that are so complex and large that they are no longer practical. Sure, from a technical perspective it all looks good on paper. The reality is that *cough magento* they are so slow you need a combination of a dedicated server and extreme caching measures to get decent speed out of them, debugging becomes a nightmare, and it ends up costing the client money in the form of lost revenue and increased development costs because all things being equal pages loading slower (measured in milliseconds) can translate into a good percentage of lost sales, and it takes longer to build in the first place.
I can tell you from experience that it's certainly possible to create simple codebases that perform complex tasks very efficiently. Take JSON vs SOAP vs XML. What's easier, faster, less resource intensive, faster to build and easier to debug? An array? Or a glob of files, folders and wsdl crap? Sure, that's one component, but when you create entire systems out of simple components you get raw speed and raw power. Is it reusable? Of course it is. But even if it wasn't, the code is so simple you can modify it quickly without tracing code through dozens of classes. And then my friend, you no longer have to worry about "black boxes".
Users browsing this forum: wqpio1hgfr and 4 guests