IoC/Dependency Injection

Ah right so IoC and DI is basically something we’ve all been doing anyway for years without even thinking about it (being programmers it’s just a natural way to do things) and now it’s got its own buzzword/TLA/acronym. Woopee.

I’ve been turned off by AOP because of the increasingly nasty syntax (on top of generics, it’s all beginning to look like C++ to me) and because it effectively obscures the meaning of code as written. I like to see what something is going to do written in front of me. I’d rather type more code than something unexpected happen due to some other bit of code written elsewhere by someone else.

Cas :slight_smile:

Essentially, cept there are frameworks to make us all do it the same way now.

Halt naysayer! :slight_smile:

Kev

Seeing as I don’t have any problems AOP will solve I’ll manage without for the time being, until my contracts depend on it, which they never will, because I’ll be old and jaded before a language with built-in AOP becomes mainstream :wink:

Cas :slight_smile:

So which language is already here?, seeing as the other criteria are already met :slight_smile:

[quote]Ah right so IoC and DI is basically something we’ve all been doing anyway for years without even thinking about it (being programmers it’s just a natural way to do things) and now it’s got its own buzzword/TLA/acronym. Woopee.
[/quote]
yes, but IoC and DI makes you sound cooler 8) 8) 8)

AOP is a kind of “goto”. You can’t tell what is going to happen just by looking at the code. Now that OOP is mainstream they need to come up with other cool sounding acronyms that end with " - Oriented Programming". Blaaargh.

Thiago

I will try enumerate some reasons:

  • Separation between code and data: XML is only necessary because Java is not Lisp. In Lisp the structures for such “readable” things would the code itself, because in Lisp the code is data and you would have much more flexibility to work with it;

  • Excess of code to handle the XML: choose your API, it will always suck. The data from the XML need to be read into some object. So that gives you the following manual work: create the schema, write the XML, read the XML into some object, use the object. Have we become assembly line workers? Have we become manual laborers? This mindless kind of work shouldn’t be performed by humans. My time would be better spent by creating actual products;

  • Dependence on version 0.0.1 pre-alpha plug-ins: This is the only way to make your life tolerable;

  • XML abuse, or, XML because XML sounds cool: for example, in web applications the XML have absolutely no utility whatsoever. Won’t you need to recreate the EAR and redeploy the app in the application server whenever you change anything anyway?

I have always wondered, why instead of using XML people just don’t store that information in Java code? XML would only make sense for exchanging data between different systems, i.e., regardless of the platform the data would still be readable. XML is an exchange format and just that. Configuring anything with XML is just nonsense.

xml is lie sql handling of it shouldn’t be all across your codebase

I’m gonna limit myself to spring a bit. and with reguard to that I can’t say I’ve written a single line to handle actual xml.

not sure how “Dependence on version 0.0.1 pre-alpha plug-ins” factors in this discussion point on a very remotely related note I can see where that came from but thats hardly the case anymore.

theres no need to overuse xml but thats hardly xml’s fault.

As far as why configure a spring app in xml because the xml was tailored to configuring beans it’s much more powerfull then using plain java to do the same job. I gues most arguments for scripting langues can be insert.
With a few simplistic ‘tricks’ xml lines can be cut back alot. When I was still developing webapps and alike when comparing to the competitions setup I could easely cut it down to a 1/10 of what they had.

also systems administrators generally don’t know how to compile program X, editing a few text files littered with tags is less of a problem. Why not use plain text over xml well xml can be validated outside the ap by using a schema.

Anyways Spring is a big wood; easy to get lost in, because of the hype most ppl ran in without a guide.

Math.pow(above,10) for hibernate :wink:

I read half this thread seeing “LoC” instead of “IoC”.

LoC is what Java has above most other languages- I can guarantee pretty much any Java app I write will end up with at least twice as many LoC as it’s equivalent in another language, maybe four or five times relative to Ruby (and yes, Ruby is the easiest language to develop with- not my fault, I’m only a user ) - but in it’s favour it’s genuinely cross platform ( I’ve run into problems between Ruby runtimes between windows and Linux and don’t even get me started on CPAN ) and this place is the best of it’s kind - and of course, if I’m writing games I want a complied language, which java is, and I want one that means I don’t have to do my own memory management, which java is.

I hate all this XML-powered nonsense though. It makes it look like as Java programmers we’re going “Oh, we have a language that takes 10 lines to accomplish what most others can do in one, but that’s just not verbose enough” so we have to put everything we can into an even more verbose and complicated format. The more I use things that aren’t XML ( YAML, anyone? ) the less I see a need for it.

I mean, I’m sure it’s great for the Enterprise. But then Enterprise got canned after a couple of seasons. I think we can all learn from that.

;p

Someone’s obviously not been programming in C or C++ recently then. ;D

I have of late, wherefor I know not, largely been writing with scripting languages.

I don’t really use languages where I have to roll my own memory management- nothing has given me any compelling reason to in the last ten years and I’m not sure anything will as scripting language runtimes get better.

In fairness, C# is only a bit less verbose than Java, but it’s a sigificant bit that would certainly incline me towards it in a situation where all other factors were equal…

I have one major gripe with C#: “properties”. These implicit accessors and mutators force a view of design where your objects are white boxes. This is contrary to all good OO design principles. Sure, an expert would know when to use properties and when to avoid them, … and we’re all experts, so the code will all be good, right? Bringing this back on track, the syntactic simplicity of breaking good design principles leads to higher coupling and therefore dependencies, and not all the injections in the world will help you then. (Okay, it’s only slightly on topic, but it seemed like an opportune place to give my standard C# rant.)