I am planning to do a Spring Framework (.net, java)seminar at the new Finetix office. The general gist is that I would like to cover the .net and java implmentations and I would like this to be open to the public. I already spoke to the Spring.net folks and they will make a post when I have a date sorted out. I imagine I can get the original java based Spring folks to post as well. Anyhow – I was asked to put together a general overview – this post will cover my initial thoughts. I hope that I can comple one of the folks in the Finetix office (perhaps a particular collegue that spent the past serveral years @ sun) to do the Java portion of the chat – while I will do the .Net portion. Below are the .net relevant thoughts I have so far. If one of the other guys will not do the Java chat – I surely will do it.

1. Intro to Inversion of Control
1. compare and contrast vs service locator
2. The importance of seperating interface from implementation
3. Eliminating the need to pass references through classes that should not need to depend on them
2. Defering singleton-ness decisions from implementation – when you can – INTERFACE BASED SINGLETONS
3. How IoC relates to testability
1. Unit test framework (NUnit)
2. Mock framework (Rhino Mocks)
4. Spring general components overview
1. Core Container
1. object factory
2. initialization method
3. getting properties off of objects in spring
4. prototype vs singleton
2. AOP – basic intro
5. Setter vs Construction Injection
6. A demo of Spring for implementing a large strategy pattern implementation (.net based)
7. The need for service locator in UI applications, Windows Forms, Swing UIs
8. Touch on Copeland Ruby example IoC container, PicoContainer, MicroKernel/ Windsor, etc.

That is about it – anyone with thoughts – put em out there.

-Chris

So

Been using SpringFramework.net on my current project for ~5 months now. All in all – it has been very helpful in a few ways. One of the things that I have needed in the past was to associate objects created dynamically with stuff IN the spring context.

For example: I need to take some logon information at some point – with this logon information – I need to pass it to legacy objects that NEED to use constructor injection – else the throw exceptions etc. So – I want to push dynamically created content.

Enter Seam…

Interesting…. As usual – the folks at JBoss are doing interesting stuff. One of thier many sub-projects; Seam – “Contextual Components” is one of the more interesting things they have going on IMHO. Seam does lots of stuff – but this I found most interesting:
excerpt: (wouldn’t xlink/ xpointer be handy for things like this excerpt)

The notion of inversion of control or dependency injection is an elegant means for a container to assemble stateless components or services. But for stateful components it is insufficient. Subversion of control (or bijection) is a unique feature of Seam that allows auto-assembly of stateful components.

WOW. Isn’t that just fantastic! Bijection, Subversion of Control. Anyhow – I will be posting more about Seam as there are several truly noteworthy things that they are doing over there with Seam. This is essentially where a variable can be annotated with an “In” and/ or an “Out” marker. Then the container can get data off of and/ or inject data into, thus providing ‘bijection’ for objects created at runtime – with state.
(** this is NOT the same as this reference to ‘Subversion of control’ where a container ref is passed to the object.)
I will also mention – as I have in the past – that another alternative to Spring on .net (2.0 only) is the Object Builder in CAB is one of them. I would love to work on a ‘bijection’ update to spring.net, objectbuilder – or something new

Excited about technology as always.
-Chris

I just wanted to make a few quickie comments on mock frameworks. I have been using Rhino Mocks daily. It is great. In the past I had tried NMock and just found it too clunky.

In short – NMock leaves you with a lot more ’stringy’ stuff to deal with. Rhino is MUCH more in the language. You type normal code. Your refactoring tools work. Your IDE helps you, etc.
The purpose of using a mock framework is basically so you can just work on testing the CUT (class under test). The CUT should usually be the ONLY concrete class in the test. This all works when you are practicing IoC. When you are using IoC – you pass in dependencies from the outside. When you do this – and you are seperating your interfaces from implementation – you can pass mock interfaces to your CUT. Once you do that – the mock can act as a spy.

1. The mock lets you wriggle into code branches so that you can test pieces of the code that are otherwise difficult to get to.
2. The mocks make your tests simpler. You do not have to instantiate lots and lots of classes correctly – you just set up interfaces and expectations and you are good.
3. The mocks make your tests more stable. You do not have to worry about changing test data etc.
4. The mock can act as a spy and tell you if it is being treated as you expect while it is ‘on the inside’

This used in conjunction with a code coverage tool (like Clover or NCover) helps you to really work your tests to cover your codebase fully.

Carry this over to the Java world – Rhino is much more like EasyMock which I am now writing some tests with. I had formerly used JMock (sort of like NMock in usage) – but I just replaced my jar reference and updated several tests. The tests are immediately more understandable, cleaner and therefore – better.

More another day – Maybe I will get around to posting comparison examples.
Chris

I was flipping through Fowler’s Analysis Patterns tonight. He uses the term “Conceptual Modeler” – I like that term. I think it is a very accurate term that describes a key element in software development : conceptually modeling the domain in the software. He also had a quote in the intro of the book that was something like

 

“Much of my skill comes from a knowledge of modeling techniques and how to use them”.

 

I also agree here. I think that much of the value I add to projects comes in the conceptual modeling. This is a notion that I think is often overlooked and more often under appreciated in software development. While I find myself being ‘anal’ as can be as a coder – and demanding the same of my teams – I believe that the modeling part is much more important than just the ‘raw coding’ part.

 

In maybe my all time favorite software book – Domain Driven Design, Evans talks about “conceptual contours”, “digging out concepts”, “supple design”, “making implicit concepts explicit” and “a model expressed in software”. These all echo the same sentiment that Fowler is indicating. In the end – there is an underlying set of real world concepts that we are trying to model in the software. Our task is to make the most useful software model of the real world domains that we are dealing with. We work with domain experts to elicit the real underlying ideas and concepts from them so that we can structure our software in a way that mirrors the real domain.

I often think that what I typically call “Modeling Sessions” are just about the most productive times that I have with my groups. Modeling Sessions are usually impromptu times when I grab 1 or more developers and try to model out some ideas. Since I generally do not believe in BDUF – so these modeling sessions are NOT a week long endeavor. Having a close knit team with extremely high levels of communication enables frequent, relatively brief modeling session.

Basically – we white board, draw on scrap paper and talk around the domain we are trying to model. We do our best to extract the most useful yet simplest model for the domain we are dealing with. Sometimes we have ‘impassioned’ debate (usually between 2 or more senior level developers that have modeled the item in debate differently in the past). In general these sessions have 1 goal – define a set of abstractions for this specific ‘item’. Often we have ‘class notes’ as an output of these meetings – some drawn out interfaces (used to describe behaviors) and perhaps some more ‘entity object’ type structures that model heiricacaldata and/ or database data. “Design patterns”, the classic ones, and the repeated patterns within our applications come up again and again in these meetings. You could hear us say things like:

1. “Usually you would use a strategy pattern for this type of situation” or

2. “In order to be consistent within the application, we did this thing in place X and this notion is similar – should we do it that way here?” or

3. “That thing you keep mentioning – the ‘…’ was it? It is not in the software really – lets make it absolutely explicit” or

4. “Wow – if we introduce this idea, then ‘…’ and ‘…..’ will become significantly more clear and easy to work with – it just makes total sense.”

Modeling sessions also enable more jr developers and/ or new team members to learn a great deal. I believe these sessions can accelerate the learning by ‘amplifying’ the knowledge in a context that is relevant. When people are learning abstract software development patterns and paradigms, out of context they can seem academic and useless. When people are seeing software modeling in practical context – relevant to their work, the ideas become clear, the patterns seem full of utility and fulfil their purpose.

In these sessions, patterns provide a great meta-language. The ‘classical patterns’ and the patterns that are part of the domain model your team has developed become the meta-language of these modelling sessions. You do not really have to say “We can just make a class – who’s only job it is – is to create concrete classes that are derived from this abstract base class”. In stead – you just say we need a ‘factory’. This is also something that Evans talks about in Domain Driven Design – he calls it the “Ubiquitous Language”. When the team is comminicating frequently and effectivley – using a meta-language of ‘normal patterns’ and patterns that are specific to your teams domain model – much more can be accomplished.

Anyhow – modeling sessions – take your team, work with them. Do architecture as a group – this is often a series of ‘modeling sessions’. Software developers really should be 1st class ‘conceptual modelers’ not just ‘coders’.

 

-Chris

Object oriented software development is something that takes people time to get. Often I find myself pointing people to this this article to sum up why I am doing or something, why something feels right or wrong to me.

This is not a new article – I just find myself pointing people to this better explaination than I could give on more and more occasions.

Summary of principals:

The Open Closed Principle (OCP) ?
A module should be open for extension but closed for modification.

The Liskov Substitution Principle (LSP) ?
Subclasses should be substitutable for their base classes.

The Dependency Inversion Principle (DIP) ?
Depend upon Abstractions. Do not depend upon concretions.

The Interface Segregation Principle (ISP) ?
Many client specific interfaces are better than one general purpose interface

The Release Reuse Equivalency Principle (REP) ?
The granule of reuse is the granule of release.

The Common Closure Principle (CCP) ?
Classes that change together, belong together.

The Common Reuse Principle (CRP) ?
Classes that aren’t reused together should not be grouped together.

The Acyclic Dependencies Principle (ADP) ?
The dependencies betwen packages must not form cycles.

The Stable Dependencies Principle (SDP) ?
Depend in the direction of stability.

The Stable Abstractions Principle (SAP) ?
Stable packages should be abstract packages.

So…. I spend most of my day typing C# code for the past several years. This is of course not to mention running dev teams to ‘get the job done’, being a husband, dad, etc. I also spend time writing Java code, Ruby code, when I need to – C++, etc, etc – i will spare the list. That all said – there is so much debate lately regarding dynamic vs static typing…. I think that there are some missed points in these debates as I have been experiencing while writing my C# to Java converter (lets call it Hydrogue).

Many of the ‘debates’ regarding static vs dyamic typing seem to have left out much of what my experience tells me are key differentiators. Most of the dynamic language fans say:

“Type errors are such a small part of the error spectrum – why be burdned by type constraints???. Focus on unit tests.” Sounds good – take away the ‘constraints’ of strong typing.

But:

1. Dynamic languages force you to know the implementation – or the type expected – how about that! This is the biggie in my mind. BREAKS ENCAPSULATION/ INFORMATION HIDING.
2. When data modeling – I WANT to know the types/ subtypes etc of aggregate objects (see 1st bullet too – I must go look around to see the ‘interface’ of an object/ sub-object)
3. Tools have a hard time helping
1. Refactoring support
2. Intellisense like support
4. “Duck typing is fine” – but it does NOT help me when I need to expect certain ‘interfaces’ will be passed into a routine. (related to bullets 1,2)

The worst of all of these has been point 1. Without knowing types of objects – I am constantly having to run around and look at routines innards to see what methods they will be calling on my objects I pass to them. If I pass an interface reference – this is effectively saying – you can call only these things on me – and I expect it. With out this notion – I need to go look inside and see what the client class will call…. thus breaking down encapsulation.

It is hopeful/ possible/ likely that a dynamic language IDE will support statement completion (Ruby Eclipse does MINIMALLY). When this happens – it will be beyond helpful. I find that even though it is ‘more code’ I can turn out more code in an automated fashion using IDEs that support refactoring, intellisense, AND INTELLIGENT find usages/ implementors, etc.

That all said – I LIKE Ruby. Writing Hydrogue has been fun, educational and useful. Just pouring over the C# language spec @ msdn has been worth the work as my understanding of the bowels of C# from the inside out have gotten all the more clear. The extra Ruby education has been great – and getting everyday back into Java has been great as well. I will just say that – either IDEs have to get smarter, or I do to be as productive with a dynamically typed language as I am with a strongly typed language.

My thought was, and continues to be – the right language for the right job. I am not convinced (as many others seem to be) that dynamic languages are ready to do the things that C#/ Java do (much less C++). Perhaps I will be more convinced to use Ruby for ‘bigger’ or ‘more complex’ applications eventually. I will keep working with Ruby and hopefully by the time the tools catch up – I can contribute to the community of developers that start with them…

Enough;

Chris