I'm not sure you've really got this whole Object-Oriented thing down quite right(davidchess.com)
davidchess.com
I'm not sure you've really got this whole Object-Oriented thing down quite right
http://www.davidchess.com/words/log.20100827.html#20100902
2 comments
It is specific to the "enterprisy" java libraries. You can easily use java without this kind of garbage, just keep away from JavaBeans, SOAP, xml config files, etc and code directly to a simple java server sitting behind a reverse proxy such as Nginx, Lighttpd, etc.
Would this work?
SOAPEnvelope soapEnvelope = MessageFactory.newInstance().createMessage().getSOAPPart().getEnvelope();
SOAPBody soapBody = soapEnvelope.getBody();
Name name = soapEnvelope.createName("HelloWorld", "hw", "");
soapBody.addChildElement(name);.addTextNode( "hello text message" );Did the library design get any less bloated that way?
I don't think the last line would work...
I don't think the last line would work...
Yes and yes.
If you always repeat the same steps, why can't you abstract them into a single method that takes name and text as arguments. You shouldn't ever have to repeat the same set of steps in multiple locations.
Well, of course, and I ended up doing that. But that's not the point, is it? The guy in the blog post could also abstract all those lines in some method and it wouldn't make that OO design with factories and contexts any less bloated.
That speaks of a bad library and API design, not the language. Plus XML is a verbose technology in general.
It's funny because it's true. How does a manager evaluate the work of his subordinate programmers (especially when the manager is a so-so programmer himself)?
1. Count the lines of code.
2. Randomly inspect code sections.
The verbose Bureaucratese sampled in the article responds to both requirements.
1. Count the lines of code.
2. Randomly inspect code sections.
The verbose Bureaucratese sampled in the article responds to both requirements.
Instead of code inspection, maybe the manager should impose short and easy to validate requirements (sub requirements of the general requirements imposed by the client) and ask the programmer to show the software passing them.
Even if TDD is not being used, the programmer can write a simple test for it and then show the manager the test succeed.
This semester I had a class of Software Engineering when we did a project using Scrum and weekly we had to show our teacher that we had accomplished our tasks. The teacher was playing the role of someone who didn't know any code, but we still had to show stuff working. So we would write simple tests to show for instance that SOAP Messages were being sent by one entity and in fact received by the other.
Even if TDD is not being used, the programmer can write a simple test for it and then show the manager the test succeed.
This semester I had a class of Software Engineering when we did a project using Scrum and weekly we had to show our teacher that we had accomplished our tasks. The teacher was playing the role of someone who didn't know any code, but we still had to show stuff working. So we would write simple tests to show for instance that SOAP Messages were being sent by one entity and in fact received by the other.
Oh, it's a bad thing and there are much better ways to evaluate code. But it's done nevertheless.
How about cutting the first one, and only going with the second. Knuth used to read a few random pages in depth to grade student papers.
Are there any other languages' libraries with complicated designs like that one or is this a problem specific to Java?
Just to give an example, this is a snippet of code I had to write dozens of times in a college project using the javax.xml.soap library to create a simple soap message with a tag on it:
It's not exactly the same issue has in the example on the blog post, but I think it also represents something that could be a lot simpler/shorter.