OO Crash Course NVCFUG March 2015 Presented by Denard Springle

What is an Object? Die – Sides Dots (or number, or image, etc.) – Color – Shape *Properties*

What can be done with an object? A die can be: – Thrown – the result of the throw being the die lands on one side, with the other side facing (the result) – Combined – with other die throws, the result of which can be manipulated (added, multiplied, divided, etc.) depending on the [business] logic desired – Saved – the die could be placed on a shelf in the last thrown configuration – Retrieved – the die could be taken off the shelf in the last thrown configuration – Discarded – the die and it’s last thrown configuration can be thrown away – Rethrown – the result of the rethrow overwriting the previous result – Etc. *Methods*

Bean (aka Data Model) ‘Bean’ is a Java term for ‘Object’ (loosely). Data Model (or more simply, ‘model’) is the modern term for ‘Object’ (loosely). Model’s are used to instantiate an Object – they return a single instance of a single Object. Can instantiate the same model multiple times, each with it’s own Object instance.

Data Access Object (DAO) Manages all CRUD methods for working with a single model (bean, object). Expects and returns Objects (models, beans). All other code interacts with the DAO so that data access occurs from the same location in code.

Gateways Manages all data when working with multiple rows (e.g. in a query). Expects [filter] parameters and returns a query (or array). All other code which reads multiple rows interacts with the gateway so that queries occur from the same location in code.

Service Layer A combination of: Data Access Object (DAO) for working with a single instance of a model. Gateway for working with multiple rows of data (filter, cache, search, etc.). Utility methods that manipulate the data in other ways (convert from query to array, return a JSON or XML representation of a model instance, etc.) – this is often done in a baseService.cfc which other service layers extend (inherit).

Why models and services? Maintainability – changes only need to occur in a handful of places within a few files (depending on implementation). Abstraction – the application only needs to know what data to pass and receive to the service(s). Ease of implementation – services can be injected by a factory, convention over configuration architecture can be employed, etc. Ease of understanding – other developers can readily understand the functions derived from using standard OO methodologies.

Centralized Data Management Using models and services centralizes data management for the rest of the application. Services can be invoked from handlers/controllers, passing data to views or being passed the data from forms, etc. Services can be invoked from API’s, scheduled tasks, gateways, etc. while always using the same functions and expectations as any other part of the application.

OO begets MVC (FW/1, ColdBox) The ‘model’ in Model-View-Controller frameworks refers to the beans and services used for data management and manipulation. Without OO fundamentals, MVC is not feasible (though technically possible, but ugly and defeats the purpose). Services do the heavy lifting - *not* controllers and *not* views – controllers should pass and return data between the model and the view – no more, no less. – This view is being requested – this data should be retrieved from the service and handed off to the view. – This [form] data is being received – this data should be handed off to the service and the service will hand me back data to hand off to (the/another) view.

Utility Functions Are Services, Too! Day to day programming involves many aspects of security and validation that are well handled by services. – Authentication, Access Control, Session Management – Form [API, etc.] validation and cleansing – Encryption/Decryption – Any function not specific to an individual object used by multiple parts of an application

Composition A die is composed of multiple sides – Each side of each die can contain different information (e.g. number of dots, numeric representation (1, 2, 3, etc.), images/icons/graphics (cow, dog, bird, etc.) – ‘sides’ would be a separate table, related to the ‘die’ id for each side, and would be comprised of information about that side – ‘side’ could be a model, and each die would have X number of ‘sides’ – ‘sides’ can be also be composed into the ‘die’ model as a property. The service layer(s) would then have to handle CRUD for both tables based on the data in the model (optimally, you would call a ‘sides’ service from the ‘die’ service)

Inheritance Provides the extending component access to (and ability to override) the parent components methods (functions) All frameworks work by extending your Application.cfc from the framework’s own CFC – thereby giving your application access to all of the frameworks methods (functions) baseModel.cfc and baseService.cfc – used to store generic model and service related utility functions common to all models and services (e.g. getMemento() for models, queryToArray() for services) – all other models and services extend their base model or service, respectively.

Other Design Patterns Factory method – abstracts the instantiation of objects (models and services). Dependency Injection – injects instantiated models and services from the factory on an as-needed basis. Façade – Inheritance based pattern that allows implementation and overwriting of parent methods in an abstracted fashion Modern frameworks (FW/1, ColdBox, etc.) make use of design patterns to abstract the complexity away and provide you with a consistent, reliable method of building MVC applications. They are steeped in OO methodologies and work best when utilized in that expected capacity.

Resources Gang of Four Design Patterns Kevan Stannard (dated but relevant) - Adam Tuttle (and friends) - Matt Gifford (dated but relevant) - Adrian J. Moreno (dated but relevant)