Here is the wikepedia definition of SOA. These principles are relevant to OO design in general. Try to build your CFC's in such a way that they can be used by more than just the application you are currently working on. Its easy to develop tunnel vision and only think about the task at hand when building and creating CFCs. It may be a little easier to think only in the moment, but that is junior league.
Think instead of who else could use this object and if someone else where to use it, what do they have to know about it. Think of the object as a small part of a larger system or environment. Think ecosystem and one plant or animal in that system. With that mind set, consider these principles in more detail.
Encapsulate - which means hide the complexity of its inner workings from the rest of the ecosystem.
- Think black box, others do not need to know how it works, just that it does.
- Think happy face to the rest of the world where the face is the API or interface. The API should show all interested parties how to interact with itself, what questions it can ask of it or what services it provides to the ecosystem and what information must be provided for the request to be understood and carried out by the object.
- Try to keep the knowledge of the environment out of the data access objects and only operate on data passed into it, do NOT rely on data that exists somewhere else, like in application or session scope. No reaching out.
Loose Coupling - This means minimum dependencies on other things in the environment. Let each thing be self sufficient.
- Objects in general have inherent dependencies, especially data service objects like DAOs and Gateways. Try to minimize these dependencies and even put them into a single place, like a object management service, like ColdSpring. At least then the coupling is managed and defined all in a single place and does not leak into the service layer.
Contract - This is an agreement that exists between two objects that interact.
- Think of this as a handshake or agreement that defines how communication occurs. This contract exist between two objects and should not change without informing both parties.
Abstraction - objects hold logic that is not exposed - only a contract is required to use it.
- Object a says to object b, i would like to call your method "get widget" where you require me to provide a widgetID. Object B says ok object a, you asked a question that i understand and provided me with the correct ID, so here it is - don't worry, i wont tell you about any of the gory details about how i completed this request for you. What? you want to know what else i can do for you? Ok, here is my API.
Re-usability - a holy grain of software design.
- Write code once and try to use it as much as possible. Some objects are inherently not too re-usable, like listeners and view files and controllers - they are all part of a specific application.
- The service layer and it dependent DAOs and Gateways are better candidates for reuse (IMHO). So, try to keep the knowledge of the environment out of the data access objects and only operate on data passed into it, do NOT rely on data that exists somewhere else, like in application or session scope. No reaching out.
Composition - collection of like services.
- This is the has a relationship that is referred to in UMLing. This is also how many APIs are wired together, via packages. Packages are like minded services.
Cohesion- a service, object or method is good at doing one thing.
- Do not try to be the doing of all things. Think in terms of small and numerous, not few and beefy. This is applicable to object design and method design.
Discover ability - the service should be able to be found.
- Especially if it is a public service, it should be findable. Using the hint property in CF is a good way to expose the intention of the object.
No comments:
Post a Comment