Computer Science

In going through the well-done set of tutorials by Koushik Kothagal at http://javabrains.koushik.org I have learned quite a bit. Though I watched the videos and followed along each video with him I need to recall and record what I think I learned so that I can really know how much I was affected by the videos.

I organize content primarily by video. Comments for each video follow the format of "<video number> <Video Title>" as a heading followed by my comments for the topic or the video.

I have gone through all 23 of the videos for Learning Spring Core and all 12 of the videos for Understanding Spring AOP.

Overview

The core value in the Spring Framework seems to come from techniques discovered over time to help overcome common problems, or situations, in programming. Dependency injection and aspect oriented programming seem to be the top of the list as far as the important uses of the Spring Framework. When I think about the ability to scan XML files and .properties files for information to be used in creating Java objects I think about dependency injection. Dependency Injection seems to be the core of what enables aspect oriented programming to take place.

As a programming design pattern dependency injection seems very useful. The video series showed me a good amount of what dependency injection is used for. Dependency Injection also seems to be a wonderful complement to the design pattern of programming to an interface.

Spring Framework series (link to YouTube playlist)

1. Understanding Dependency Injection

Using shapes to explain dependency injection seems like a contrived example and I want to see more real world applications of dependency injection. Though contrived the illustration was enough to show me some of the mechanics of dependency injection, such as defining components (Java beans) from XML files.

The idea of dependency injection seems very useful even outside of the computer science context. It seems like the idea of making a connector between two things that is universal or more standardized than having a tight coupling of things together.

I think of the idea of rights. Say a person has a right to property or the privilege of doing a particular action. If only that person was able to have that right then that right has a complete dependency on that person being there. What if an individual could assign those rights to another individual if the other satisfied a set of criteria? It wouldn't matter who the individual was, how old they are, or many other characteristics of individuals. None of that would matter so long as the individual could satisfy the criteria for Assignability of the right. As long as the ability to have the right is bound the Assignability characteristics then there is no reason an individual who could possibly satisfy the characteristics couldn't hold that right.

Consider the idea of ownership in a Partnership. If the business has assets and in order to make decisions regarding the access to and use of the assets an individual has to satisfy the criteria of being a Partner then it doesn't matter what other characteristics the individual has. As long as one possesses the characteristics required to be a Partner then access to and use of the assets is a possibility.

So, is a Partner a position or a job description? A position is supposed to be able to be assigned to a person, so it is Assignable. A job description is supposed to include all of the things needed to accomplish a particular objective. Positions can exist independently of job descriptions and vice versa. A position can have many job descriptions and a job description can be assigned to many positions. Partner is definitely a position though in order to really be a Partner one must perform the duties associated with the Partner position. There are certain duties and rights associated with the position of Partner that without them the term Partner would be meaningless. If the Partner position did not have the privileges of sharing income and debt of the organization then it wouldn't be a partner.

As I further define these terms in my mind I see the idea of identity is more connected with Job Description than Position. So is a position a glorified job description? If three job descriptions are to be accomplished and only a certain sort of person can accomplish that set of job descriptions then that position filled by that person is only an aggregate of the things needed for each of the job descriptions. If an individual is given a position with the three job descriptions even though the person cannot accomplish the duties of the job descriptions then the person hasn't really been given that position. The person has been given a lesser version of the position since over the long term the true intent of the position will never be expressed.

Job descriptions seem like interfaces and positions seem like things that collect interfaces. Positions implement the job descriptions. Without positions the job descriptions' duties are never accomplished.

So, a position is like a Java Bean and a job description is like an interface. However, it doesn't quite work that way because an object that implements an interface can be passed around by the interface handle. Can a position be passed around by the handle of the job description? Maybe it can.

2. Setting Up

It is nice to see the details on adding JAR files to a project. Even though I can figure it out it is useful to have an example of creating user libraries and the use of those user libraries.

3. Understanding Spring Bean Factory

I understand the idea of dependency injection but the idea of a Factory hasn't quite set in. It seems like instead of instantiating an object directly every time then a factory pattern is the idea of using the factory object to request a particular class of object. It seems like the main benefit with this pattern is that the object returned from the factory could be initialized with a particular set of standardized properties. With Aspect Oriented Programming the factory could be returning a proxy object of the requested class type so that Spring could include advice into the returned object that enables lifecycle management. I would like to see why using factories is valuable.

4. Writing Code Using the Bean Factory

I have used things like Session factories in Hibernate though I have yet to use a factory of my own making. Once I have experienced the condition of needing a factory I will gain the appreciation of using the factory pattern.

5. ApplicationContext and Property Initialization

It seemed very handy to have one place, one XML file to define all of the major components in the application by defining <bean> elements. I like the idea that the application context I define is the main thing in the Spring container. It seemed very straightforward to connect the idea of the application context to the idea of an object container in which connections could easily be made between objects in the container.

I also liked the idea of initializing properties through an XML file so that they only have to be typed once and only have to exist in one place. It seems like a no-brainer to do this sort of activity for configuration options.

Summary

With all of the things I learned in these first videos I learned that dependency injection is a topic I will be studying and using for quite some time. It seems like a communication construct as much as a computer science logical construct. All this talk of job descriptions and positions sort of helps me put context into the idea of dependency injection though I want to free my mind from using one set of ideas as the pattern of all others until I find that universal pattern, if such a thing could possibly exist.

Using factories seems to make sense in the light of standardizing object initialization so that byte code can be amended to include commands for lifecycle management and interfaces for interaction with other objects. Using Spring makes me think of putting all of my things in a box and then having great control over how things in that box interact. If I don't define an interaction then I know it isn't happening, which is very nice.