Using the injectABL module made by Peter Judge. https://community.progress.com/technicalusers/w/openedgecloudarcade/998.oeri-dependency-injection-container-injectabl.aspx . Some commercials for this great work below, but first this:
It would be great if the documentation of injectABL (see the link at the top) would get some attention, so that it becomes more appealing to those new to the principles. It's worth the product (talking from experience, I use it for a couple of years now), and I think needed for acceptance by new programmers having to work with frameworks that makes use of it (I experience this problem myself at least with programmers starting with the framework I built - starting with aetf - and of course had a learningcurve myself when I started using it).
We now, with injectABL, have a module to manage lifespan of and dependencies between objects, in a highly configurable way. On IoC: http://martinfowler.com/articles/injection.html
We can for example avoid those handy singletons (one running instance per session) that you instantiate via a static, making it possible to use the class without first having to new (for example http://knowledgebase.progress.com/articles/Article/P159909).
Why is such a singleton to be avoided? http://blogs.msdn.com/b/scottdensmore/archive/2004/05/25/140827.aspx
As Fowler says (see link above) IoC has some pros above the factories, from the link above:
"IOC/DI is a complete ecosystem of domain objects and services in and of itself. It sets everything up for you in the way you specify. Your domain objects and services are constructed by the container, and do not construct themselves: they therefore do not have any dependencies on the container or on any factories. IOC/DI permits an extremely high degree of configurability, with all the configuration in a single place (construction of the container) at the topmost layer of your application (the GUI, the Web front-end).
Factory abstracts away some of the construction of your domain objects and services. But domain objects and services are still responsible for figuring out how to construct themselves and how to get all the things they depend on. All these "active" dependencies filter all the way through all the layers in your application. There is no single place to go to configure everything."
Some interesting remarks about the use of IoC / DI:
http://www.devtrends.co.uk/blog/how-not-to-do-dependency-injection-the-static-or-singleton-container
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
www.linkedin.com/in/stefanhoutzager
Thanks for the kind words, Stefan.
What kinds of improvements in the doc are you interested in? More usage examples? More/better 'javadoc'? Something else?
-- peter
The questions what, why, how, where, when have to be answered and you did, but I think you get into the deep too fast now and then, for some new to the subject.
First the need has to become clear. Most progress programmers are have a procedural programming background and are used to a lot but IoC. They are used to .p's and .w's instantiating other .p's and .w's.
ordermaint.w
run orders/ordershandler.p persistent set hHandler.
on push of button:
run createorder in hHandler.
end trigger.
and when they start with oo they repeat the old style:
ordermaint.cls
oHandler = new orders.ordershandler().
method private void buttonclick():
oHandler:createorder().
end method.
When they find out about statics they might find a shorter way attractive:
ordermaint.cls
method private void buttonclick():
orders.ordershandler:createorder().
end method.
Not all programmers are interested in new techniques to "hang out with the cool kids". Might be they work in a companies with conservative dinosaurs that hate (or fear or both) smartasses. First question that arises when they hear about DI / an IoC container is of course "what is wrong with the style I already make money with for fifteen years and why should I hurt my brain thinking about something like injectABL?".
The what, why and have to be explained:
What DI / IoC container mean (in short)
Why would you use DI / IoC container
How DI / an IoC container solve the problem.
The link to the ninject site shows perfect reasoning, well chosen! Following link could also help in understanding:
tutorials.jenkov.com/.../index.html
When DI / an IoC container are not needed (error objects, enum classes like they are built in aetf etc.)
Then some samples, starting simple and showing the different config possibilities with the module classes. An immediate dive into test_injectabl.p will cause an acute braincrash.
Some kind of do-it-yourself tutorial.
How could you introduce injectABL in your company:
"Do you work with these people on any smaller projects, or just one big one? It's easier to convince people to try something new on a secondary/tertiary project than the team/companies bread and butter. The main reasons are that if it fails the cost of removing/replacing it is much smaller, and it's much less work to get it everywhere in a small project. In a large existing one you either have a large upfront cost to make the change everywhere at once, or an extended period in which the code is a mixture of the old/new approach adding friction because you have to remember which way each class is designed to work."
Pulling yourself by the hairs out of the morass:
"I support a three-strikes rule: Make it work, make it clean, make it SOLID. When you first write a line of code it just has to work, and you don't get points for ivory-tower designs. Assume it's a one-off and do what you gotta do. The second time you look at that code, you're probably looking to expand or reuse it, and it's not the one-off you thought it'd be. At this point, make it more elegant and understandable by refactoring it; simplify convoluted logic, extract repeated code into loops and/or method calls, add a few comments here and there for any kludge you have to leave in place, etc. The third time you look at that code it's probably kind of a big deal. Now you should adhere to the SOLID rules; inject dependencies instead of constructing them, extract classes to hold methods that are less cohesive with the "meat" of the code, make sure class hierarchies are logical and that derived classes "look" like their parents if you were to substitute one for the other, etc."
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
www.linkedin.com/in/stefanhoutzager