OO birds eye view

OO - think in terms of objects

OO - think in terms of data and functions together in a single entity

OO - think in terms of reference, not value

OO - think in terms of encapsulation (self sufficiency)

OO - think in terms of

OO - think in terms of singleton -vs- transient

OO - think in terms of state of an object

OO - think in terms of security (accessors and modifyers) - getters / setters

Software Architecture (MVC)

think in terms of layers

think in terms of separation of concerns

think in terms of maintenance

think in terms of clarity

think in terms of sessions

Desing Patterns

think in terms of DAOs, Gateways, Beans

think in terms of anti pattern (3- 1) - not every entity needs its own service, gateway and DAO

a service should serve more than just a single DAO and Gateway.

think in terms of doctor - patient (a doctor has many patients)

think of singletons -vs- transients

singletons application wide, transients user wide

transients (have state)
singletons (no state)

*for the singletons (many users using a single instance) think in terms of varing
every variable in it. these are objects stored in application scope.

Frameworks

think in terms of maintenance

thinks of tradeoffs

think of consequences

think of payoff (work up front, payoff later)

think of overhead

think of consistency - predicatability

OO programming from domain to presentation layer

I am always trying to get a better handle on OO programming techniques. I come from that produral background and i think it is always influencing the way i see layer and communication.

If i can think of the objects as two types
singletons - only one copy exists per session per user - these have no state
(these are DOA's, Gateways, Services)

transient - have state and need to keep the state while living in memory
(these are beans or value objects)

In my main application that i support, this means

transient objects or beans that have state (specific data associated with them) are
assessments
standards (performance indicators)
resources

Each of these beans is updated when a new one is selected.

For each user a set of each is created (assesment, resourse, standard) value bean. They are created in the service that is used to communicate with them.

There is only a single service object (a singleton) that is created once when the application starts. The singleton is placed in a application scope and is then accessible to every user who comes to the site. They all share the same instance of the object or class. There is no race concerns because the application (coldFusion) takes care of the threading.

So - one instance of the services for all the users who come to the site. A collection of objects for each user when they initially hit a part of the site that uses the service for those objects.

Also in the service, besides the instantiating of the transient objects, are the rules for when to call the other singletons. The service is the big DOG. It knows about the other services and the other singleton and transient objects. If you looked into the init() of the service.

Again - think like this

- whenever you have data to persist for a value object
- ensure a copy of it exists in memory
- use the DAO to get the updated data (if reading from table)
- use the Form or URL parameters if updating to a table)
- update the current bean in memory
- pass a reference to the bean from the service into the DAO/Gateway when necessary
- pass a reference back to the presentation layer when feasible.

I dont think rules like this are always adviseable, some times it just makes sense to pass by value and not reference. But, in the spirit of OO - think like this by default and work from that position.

I did this in a couple view pages i was recently working on. The the user clicked on a resource or assessment or standard, if the request was to view something - then i would go to the service who who use the id and existing reference to the value object, and pass them both into the DAO gto get the details from the DB. If the request was a update, then i would use the updated values in the form fields and pass them along into the service and update the current bean using the arguments passed in and then pass back a reference to the value (bean) object. now in my presentation layer im referencing the bean that is in memory. Im not actually going back into the db (which is a no no from a MVC perspective) - but referencing the value bean via the object passed along. Encapsulationa and OO techniques!

Im not sure if this is really the smartest way to go about this, but it is my attemp to continue to push out OO concepts and challenge myself to learn to think in terms of Objects and encapsulation.

cheers
What i started to do recently, in the spirit of OO, is to return the pointer or reference to the presentation layer.

3rd party editors - usability

Ive build a utlility application that uses a 3rd party editor called Fckeditor. Its a popular editor, that is implemented in each of the major platforms, java, coldfusion, asp, etc..

I brought it into play originally for another utlitity application that i was working on. Each of the two utilities are about feeding data to a relational db.

Each of the two utilities needs to upload files as part of their jobs. Lots of text, with images needed as well as other upload types. the challenge is that each utility needs to store the uploads in different places. I could, i suppose use different implementations, meaning give each utility its own set of core files (thats about 400 total) - seems a little overkill. What im looking to do is dynamically inform the path where the editor will upload the images to.

Ive dug into the editor a bit and found the upload configuration file that is defining the path where the uploads are going. Now i need to figure out the smartest way to inform the editor where it being used from and pass that variable into the configuration file to dynamically set the userpath.

If this gets too hairy, i can always use plan A, each utility having its own implementation of the fckeditor core files.....but i really dont want to do that.

stay tuned

Im back - im thinking i may try to scale down the size of the fckeditor core files - since alot of them are for implementations that i am not using. Then each Utility could have its own version of the core files. Then, each would have its own

fckeditor.editor.filemanager.upload.cfm.config.cfm

and i could set one where it is now and the other where it needs to be, including the dynamic updating still needed.
Resources path = userfiles/image
assessments path = assessment/assessmentID/

perhaps...i need to continue my heavy lifting around this before moving into a implementation.

Im thinking about creating a utility helper CFC where i could set a session variable or application and use that to inform the assessments *dynamic portion. In the assessments app, im using a framework where i could use a build in plug in point to instantiate the helper object upon application startup. "bootstrapping".

Application.cfc and Frameworks

im working on a utility and am setting up a little session state management. I have a request from a customer like this "when we choose a question type of A, can it remember that for the next one record i add?". Of course, a common request, what i would referr to as state management. Keep the last answer provided by the user via the interface and use it to inform the state of the interface. Session variables come immediatly to mind.

I set off to implement this solution. I thought about it for a little while first, heavylifting, my biggest question was where to lookup and update the session variable. I did not want to do it on the view page, but rather somewhere in a *session object. My thinking brought me into the Application.cfc, which is a special *framework like component that Coldfusion provides that have built in plugin points. This means there are points in a request where the developer can interceed and do some kind of processing, testing etc. These built in functions include application start and end, session start and end, request state and end. This is pretty handy IF you ARE NOT ALLREADY using a framework.

I am using machii and so have a means already to interceed where i need to. Additionaly, the framework allows me to interceed in the event that i want, not all the events. That feels a little better than sticking the test in a OnRequest function. I could put logic in the OnRequest and have it only perform when needed - but even then, that wrapper logic would be read on EVERY request. My framework allows me to place the same test in a listener or service request that is ONLY read when i explicitly call for it.

The framework adds overhead, but pays for itself in many ways, including this one.

Bottom line - dont expect to use Application.cfc or the old school Application.cfm IF you are using a framework. This is a quote from mega smart Sean Corfield.

"It doesn't really. Frameworks generally provide their own plugin points and ignore Application.cfm - and they pretty much ignore Application.cfc as well. Perhaps future versions of the frameworks will support / integrate with Application.cfc? "

Application.cfc and Frameworks

im working on a utility and am setting up a little session state management. I have a request from a customer like this "when we choose a question type of A, can it remember that for the next one record i add?". Of course, a common request, what i would referr to as state management. Keep the last answer provided by the user via the interface and use it to inform the state of the interface. Session variables come immediatly to mind.

I set off to implement this solution. I thought about it for a little while first, heavylifting, my biggest question was where to lookup and update the session variable. I did not want to do it on the view page, but rather somewhere in a *session object. My thinking brought me into the Application.cfc, which is a special *framework like component that Coldfusion provides that have built in plugin points. This means there are points in a request where the developer can interceed and do some kind of processing, testing etc. These built in functions include application start and end, session start and end, request state and end. This is pretty handy IF you ARE NOT ALLREADY using a framework.

I am using machii and so have a means already to interceed where i need to. Additionaly, the framework allows me to interceed in the event that i want, not all the events. That feels a little better than sticking the test in a OnRequest function. I could put logic in the OnRequest and have it only perform when needed - but even then, that wrapper logic would be read on EVERY request. My framework allows me to place the same test in a listener or service request that is ONLY read when i explicitly call for it.

The framework adds overhead, but pays for itself in many ways, including this one.

Bottom line - dont expect to use Application.cfc or the old school Application.cfm IF you are using a framework. This is a quote from mega smart Sean Corfield.

"It doesn't really. Frameworks generally provide their own plugin points and ignore Application.cfm - and they pretty much ignore Application.cfc as well. Perhaps future versions of the frameworks will support / integrate with Application.cfc? "

Beans, DAOs, Services, applications

Im working on a Utility that does standard CRUD stuff. My brain got a little confused, again, in the area of relationships between services, beans and DAOs. Specifically, i could not decide the best way to implement the relationships between the three. In a SOA, we use the Service object as the laison between the application and the domain objects. Does the service also keep the responsibility of creating a persistence bean for a certain object? I think so, i added the instantiation of the resource persistence bean into the init() of the service. Now the service init() function instantiates DOA, Gateway and bean objects. I am using the variables scope in front of each and have tested the threading, which should not be a problem, since each user who instantiates their own service object gets there own copy of each of the other objects.



In my service, I have a set bean method, that updates the "empty" bean object, by passing a objectID into the set bean method - which then goes to the DAO, since thats the object that should have the SQL or whatever DB code you are using. The bean itself should not know about the database that is being used to get its data so it can do its job of persisting. So, the service calls a getRecord method in the DAO, the DAO sends back a 1 record query to the service. Teh service checks to be sure it has a valid result and then passes the query result to the set bean method in the bean itself.



This seems to make sense - following these good OO practices.

• Service creates objects needed to do the work requested by application
  
• Service asks the DAO to get a single record, passing in objectID
  
• DAO returns a single record
  
• Service ensure the record returned is valid (this could be done in DAO too)
  
• Service then calls the set bean method in the bean itself, passing in the record to update
  

In conclusion:

• The DOA does not know about the beans
• The beans do not know about the database
• The service knows about beans and DAOs and Gateways and other services.

new development

Im about to begin development on a medium sized project and wanted to document some of the things i know i should be thinking about before i begin.

Who is my customer - define this, have them in your mind. You should be able to say in a couple works who they are.

What do they want - get a requirements document nailed down. Thats happening now, my customer is detailing the requirements from our meeting, he will share those back with me for agreement before giving to his client. Be very specific about what the specs indicate will be done in the initial iteration. We could use a front to back design methodology that gets the product in front of the client sooner than later. We may still try to do this. I am following the Agile approach, not the water fall. In other words, create smaller more focused iterations of the product, rather than larger more consuming ones. This is a tenent of good design or process.

Getting down to business. I will follow a mature design pattern, MVC. This pattern will focus on the separation of functionality into three distinct pieces. Think usability in the view layer. Ensure the interface is easy to use, clean and reliable. Not too much clutter or needing to dig to see things. Provide immediate feedback in the interface. Perhaps use AJAX type functionality. This will be a data intensive application, so AJAX techniques would be valuable. At the same time, be sure the application works in both IE and FF. AJAX stuff sometimes is cross browser problematic. I could use the built in CF8 AJAX libraries, but this would require that the hosting server would also be using CF8, which is not quite true, yet. I should stay away from cf8 specific functionality for now.

The controller. I will probably use machii or some MVC framework. Other utilities and the main application all use machii. I *could be consistent or i could use as opportunity to try a different framework, like model glue or Tarten. I could forgo a framework all together, but i like what the framework provides and I know that this application is going to grow in complexity.

The model. This is the part that is most interesting to me. I do like the other layers, but the domain modeling and service, DAO, bean objects are of most interest. I have implemented these patterns a few times now and each new opportunity provides more insight and hopefully a tighter design. I could even try to use a ORM tool to stub out the intial domain objects. The domain design includes how to manage the relationships between the collaborating entities. I will probably use ColdSpring again, since i just think its a superb piece of engineering. Maybe i wont use CS, and show how the objects themselves could keep that knowledge, via init and constructors.

Ill return in a couple weeks when im done with the initial build of this Utility.