Frameworks Suck!
Brian Rinaldi pointed me to a recent Thread on House of Fusion showing just how dangerous frameworks can be for developers still getting up to speed with OO development.
If you’re new to OO, start by learning the basics and writing a simple application from scratch. At some point in time you’re going to get fed up with writing all of the controller code, so feel free to drop in Mach-II, or Model Glue (not Unity) (or you could use Fusebox if you swing that way).
As your model expands you’re going to notice that all of your service methods are calling each other and their DAOs and Gateways (if you still use Gateways), so you might want to drop in ColdSpring to inject all of the dependencies to simplify and decouple your design.
Eventually you’re going to get tired of writing DAOs. You’ll try Brians generator, but as the requirements keep changing you’re going to get fed up changing them by hand and you’ll look at Reactor, Transfer or cfHibernate to automate the creation of your ORM code.
Of course, finally, you’ll save yourself from all of that nonsense by creating richer metadata and generating your applications instead, but I’m guessing I’ll have to clean up and post my code before anyone will take that one too seriously!
Frameworks are proven solutions to recurring problems, but there is nothing worse than having a sophisticated solution to problems you’ve never even considered and then trying to use that to learn the basics of how to develop OO apps.
Just wondering if you have a bias against Unity?
Doug
As you know, I agree that you need to know what problems a framework is solving for you before you know why you need a framework...and the "full-stack" approach of MG:U combined with the hype has led people to believe that this will make their transition into OO far easier than it will - and I think many of them won't realize this until they are deeply committed to using MG:U and Reactor. Again, I am not saying that using either is a bad thing, just that someone asking the question about which framework to choose folllowed by a MG:U lovefest filled with vagueries about how it will allow you to do projects without all the effort once required ends up being both confusing and misleading.
Actually I think MG:Unity is pretty cool. I just think that as someone is learning OO, it is almost overwhelming to learn OO, Reactor, ColdSpring and Model Glue all at the same time. You don't know a DAO from a Gateway and you have an application dynamically introspecting databases to generate DAOs that are Dependency Injected using Coldpring with a full front controller and even scaffolding from model glue!!!
If I was suggesting a simple front controller for someone who was still learning OO but had had enough of writing that code themselves, I'd suggest the older model glue as everything is focused on the controller. If someone with a little more experience was interested in creating an application, I would thoroughly recommend that they seriously considered MG:Unity.
This may just be an issue of documentation, but I think MG:Unity needs an MG:Light - a set of documents and resources that ONLY speak to the front controller piece, allowing people to take advantage of the out of the box integration with CS and Reactor only if they want to. That is not a complaint against CS or Reactor, but I like the Unix approach of "lots of little tools" and from a decoupling perspective, I'd rather have MG:Light with a seperate set of docs as a lightweight front controller and have the option of an install with or without ColdSpring and Reactor. I'm not saying Joe should do this, but I think there is a possibility of Mach-II becoming the more popular controller amongst people who want to mix and match their frameworks. I don't consider myself a complete n00b, but even I find MG:Unity overwhelming sometimes (not a "hello world" - but a real application)!
Best Wishes,
Peter
You've nailed it. I feel that the "ease" of MG:Unity actually makes it much more difficult to learn how an OO app actually works. It'd be like trying to learn to drive a car in a Ferrari. A stick shift and performance engine has power, but it's not the easiest place to start.
MG:Unity speeds development for experienced OO developers, but while an OO noob might be able to do a "hello world" in MG pretty quickly, I think it would actually slow them down from learning how to architect an OO app. Of course, once they've learnt that there are plenty of good reasons to choose a framework and go for it.
I tend to stay out the "which framework is better discussion" because it's a big smelly foot issue that can't be solved with over the counter ointment. IMHO, if you want to create full-blown enterprise level applications - you need all the control you can get. However, you have to give some of that control away if you are using "full-stack" frameworks. While scaffolds and ORM may speed up your development on the onset - you end up re-doing stuff after your first release of your application. I always hear the answer of "just don't use the scaffolds or ORM". Which brings the question of why do they have to be included in the core of the framework? Brian's code generator will mature as time goes by which will provide even more functionality (i.e solving the same problem independently).
Just imagine this...Why haven't electric lawn mowers caught on? Probably because most of them have extension cords still. I have friend that has one and it's look dangerous to use. He said it was cheaper and doesn't use gas (not to mention the effort it takes to avoid the cord while mowing). Why not all add an automatic lawn sprinkler on it as well? Now, in addition to the electrical cord we would have a water hose attached. Just more dependencies in the to get the same job done (i.e. cutting and watering the grass). What's about the two times a year you need to fertilize your grass? Ok, slap on drop feeder to you mower because you need it... Well, since you added that - how about X?
Ok, I'm getting plain silly now, but once you add one thing - you start getting the pressure to add more and then you end up with a product that might look a bit like something Willy Wonka would build. I am just trying to make the point that more isn't necessarily better and the decision of what should be in the framework is a question that should be taken lightly.
Choosing a framework all depends on your needs and there isn't such a thing as silver-bullet when it comes to frameworks. I think that something that newbies think sometbody is going to tell them - use X because it's lightyears ahead of the others. In the end, MG and Mach-II (as well others) are all trying to solve the MVC problem. Many things between the frameworks work the same -- only a change of verbs is the real difference.
The phrase of "use the right tool for the job" leads me to my next point... I don't like the idea that is floating around the CF community that if you pick up a framework you will learn OO. It's hard to me to believe that someone really can knows how big of a problem something like ColdSpring solves until they have to battle the problem of managing it manually. Personally, you can't really appreciate something until you know all the good and bad. This requires knowledge that can only be learned through experience. If you don't know how to change a flat on your car, do you really think it's possible for you safely install new brakes (i.e. you have to know how to take of the tire first before you can get to the brakes)?
So, how do you what tool to use on the job if you don't have the experience/training/etc.? That's the problem here - people ask which framework is better? Not my job to say, envangelize, instruct or declare. However, I will say that programming is a job that requires you always learn new things to stay with the game. If don't keep your skillset up, you end being the guy that says that CF 3.5 is the bomb and asks the question of why would you ever need CFMX 7?
::RANT OFF (ok, I'm done ;-)::
Cool rant, but you KNOW the electric lawnmower guys are going to be ALL OVER this post now. They are the wrong guys to piss off online, my friend :->
A little more seriously, MG:Unity solves a real problem. Why do you have to manually hook up MG, CS and Reactor every single time. The answer is that in an ideal world you would have the OPTION of either the the "light" front controller or a fully preconfigured app.
I think MG:Unity is a great step forward and for the right project it is a great solution. I think it is a HORRIBLE way to learn OO programming.
My personal feeling is that if you don't know what framework to use, you might want to consider not using a framework at all. Solve the problems yourself, sneak a look at the documentation for all of the major frameworks and learn from it. Once you've written a couple of apps you'll know exactly what frameworks you want to use and which ones are worth the trouble for your apps.
Why do you have to manually hook up MG, CS and Reactor every single time. The answer is that in an ideal world you wuld have the OPTION of either the complete package or the "light" front controller or a fully preconfigured app.
</quote>
You don't have too - create you skeleton to your specs that predefine the plugins and filters you want (whether they are pre-bundled or self-created). It could also include an exception listener that emails you errors and show nice errors to uses (if you application is running in production). Just a different way to skin a rabbit so to say. Just one of them is built-into the core of the framework and the other is user-created.
Frameworks are about quickly solving common problems using best practices and integrating CS and Reactor is a common requirement.
I think it is perfectly OK for a framework to come with optional integration distros that allow the quick integration of multiple frameworks that many people use regularly. It'll be interesting to see how Seans work on tying transfer into MG:Unity works out. It may end up being the first step to a configurable metaframework that allows for the integration of any/all sub frameworks without having to write your own framework. And Mach-II could have such functionality just as Unity could.
I engaged Brian in the thread on cf-talk (so thanks for highlighting it!) and it is interesting to see his responses and thought patterns unfold...
Any time I see a poster suggest just throwing their business logic into the Reactor generated DAOs and gateways I think that shows EXACTLY how dangerous frameworks can be. Also the idea of Reactor as a framework (as opposed to a persistence mechanism) . . .
I was one of the people in a rush and asking what framework to use and my answer now would be that if you have to ask the question, the answer is that you should build your own. Once you can answer the question yourself by comparing the complexities of mach-ii to the relative simplicity of model-glue or the relative strengths of an active record pattern to a more compositional approach, you're ready to use take advantages of the benefits that a framework can provide!
Back in the real world, I guess I just want to highlight that the more powerful and capable a framework is, the steeper the learning curve to create "real applications" and the more likely people are to code themselves into a box by not understand the strengths and limitations of the framework they've chosen.
As for the thread, I'm thoroughly enjoying your comments and Brians responses. As always I'm learning plenty!
My first thought is that MG:Unity has WAY too much going on to be a good MVC implementation for procedural programming. I would probably recommend Fusebox along with some best practices tutorials to enforce the distinction between controller and model (which can get mixed together in fb from what I remember).
That said, Sean recently added a good point on the original thread that you can just not install Reactor and ignore ColdSpring, but if you just need MVC, you can teach that in a few blog posts and a simple sample application - you really don't need a fully fledged OO framework like MG:Unity for that at all.
Does anyone else suggest using MG for procedural apps? It is certainly something I hadn't thought seriously about!
I'd hoped the title would flush out some of the best commentors and I've not been disappointed!
Years ago I was discussing this sort of thing with Scott Meyers (author of "Effective C++" amongst other titles) and he said there are broadly three types of programmers. He classified them in C++ syntax as "public", "protected", "private". Most programmers are "public" - they build applications and use tools / libraries to do it. The "protected" programmers are mentors and have in-depth knowledge of how the tools and libraries work and can usually debug a problem with a tool or library and may even be able to enhance such tools and libraries. Then there are a few "private" programmers - they write the tools and libraries.
This fits in with a sentiment I've heard a number of times over the years: great programmers are born, not made.
What we all need to accept is that there are tiers and not everyone will make it all the way up through the tiers.
Getting back on point, a lot of programmers don't have the skills / knowledge or even environment (lone programmer syndrome) to be able to tell whether they are getting into trouble or not. If you encourage everyone to build a framework, a lot of people will end up with a mess and not know it. That why mentoring is *so* important (in so many disciplines) and it is posited on the concept that there are tiers of skills - not everyone gets to be a great craftsman; most people can attain a competent workmanlike level, with mentoring, and some go on to become satisfactory craftsmen eventually.
I would not encourage people to attempt to build their own frameworks but I do agree that they need to learn OO in order to get the best out of some of the frameworks. Your point about blending business objects and active records etc speaks directly to that - a lot of people don't even realize they're doing it let alone why it is not a recommended practice. And part of the problem is that there really isn't much approachable literature out there that tackles this sort of conceptual learning and thinking...
Very interesting concept (and just the type of naming convention you'd expect from a C++ programmer :->). You raise a good point of course. It is quite a job to create a framework.
For team development, that is not such a big deal. You'll typically have an architect who can write the framework (or more realistically if it is a team project who will play around with the concepts and then choose the appropriate community framework based on the use case and skills within the team).
For a lone developer or team that doesn't have an experienced architect it is much more of a problem. However, I think I would still recommend learning OO programming before implementing an OO framework. If someone has a deadline, no OO experience and no framework, I think the best thing they can do is download a copy of Fusebox and hack together a solution. It won't be TOO horrible, and compared to the overhead of learning OO on a deadline, it's the only course of action I could recommend (having done the opposite myself!).
The real problem with OO programming is that it requires a substantial investment that may take years to pay back in terms of more maintainable applications. I am not sure that a 9-5 developer working for a small shop with no real motivation to go OO will get a worthwhile return and I think there may well end up with a schism between the OO CF developers and the many who just can't justify the cost of the learning curve.
I don't buy the lone programmer syndrome. I'm a lone programmer and that's why I use the lists and blogs. There is a huge amount of support out there for motivated developers to learn OO CF - it's just quite a task. I have a Computer Engineering background (pre mainstream OO - I learnt Pascal and C - not C++) and still found the learning curve steep.
Maybe it is just that we're early in the OO adoption curve for ColdFusion developers. If someone is having problems with OO CF and can't afford the learning curve (and doesn't want to be programming in their spare time for the fun of it), they may just want to wait a little. The documentation and tutorials are just going to get better as time goes by . . .
IMHO mixing learning OO with the selection of a framework really makes this neverending debate confusing. Should you learn OO? Well IMO yes but does that mean you always use OO? Absolutely not. Should you learn to use a framework? Yes. Should you always use a framework? Absolutely not. Use OO where it helps solve the problem. Use a framework where it helps solve the problem.
Attempting to learn OO and frameworks at the same time or debate OO and frameworks simultaneously will confuse anyone regardless of whether you are a public, private or protected developer. Learn one at a time and use them as needed to solve the problem. As developers we too often inject our personal philoshophy into solving a problem. Perhaps that's why more than 1/2 the projects we develop fail.
So in the end, what the solution? Which framework is best? Which tool is the best? Why the one that solves the problem and works of course.
I think it is still a worthwhile discussion, not to identify the "right" framework or approach (procedural vs OO), but rather to tease out additional heuristics that may affect the decision on which approach or framework to use in a specific circumstance.
"It depends" is a cop out. When we can post a comprehensive set of simple heuristics which clearly defines exactly what it depends on for any given situation then there is no need to continue this discussion. Until I see that comprehensive set of heuristics, I will continue to pose these questions!
It is like the language debate. I think Joel Spolsky nailed it when he said "the one your developers are most comfortable with" is the best language. I agree with him, but I still enjoy reading about the benefits of closures or the strengths of Ruby as it deepens my knowledge of programming languages and patterns which is always a good thing.
I can see your idea that its better to learn good OO before jumping into a framework, my question is what's the best way to learn OO skills for a CF developer. Is it to look at languages like Java, C# and see how they do things. And when do you know that your OO skills are up to speed so you can go and start working with a framework?
Stephen
Great question! I think one of the issues is that learning OO in CF is still a matter of digging around on various blogs rather than just buying a particular book, making it harder than it should be.
CFC-dev used to be a great mailing list (I'm not quite sure if it is still about, but Google it and check out the archives). I'm pretty sure Matt Woodward had some OO advice on his blog and there are lots of other good blogs around. I'd sign up for full as a goog and look at all of the CF blogs, searching their archives for "object oriented". There have been various OO wikis and sites in the CF community, but I don't know that any has really gained critical mas yet (although I could well be wrong).
In terms of the learning process, I'd start by creating a data access cfc for one object in one application (maybe product or article or category or invoice). I'd then create methods to save (or insert and update), get and delete and would try to tweak the application to call those methods. Once I'd done that I'd create a service component for doing all of the "work" for one of the objects. Again create save, get and delete methods, but carry on just passing the results back as queries or structs or whatever. The next big step is then to start passing around a business object encapsulating all of the information for a product or category or whatever and to get used to caling getters and setters for everything. Along the way you may wonder how to create such objects and the factory pattern will start to make sense (Sean has a good presentation about this at corfield.org).
Once you've done that you'll be comfortable with the syntax and the most popular types of objects within the model, so I think then moving to model-glue or mach-ii would be a lot easier.
In terms of reading, feel free to learn from Java as there is a good match between the patterns being adopted in the CF and Java worlds. The syntax is less important than the concepts. Feel free to check out Simon Horwirths blog. I don't agree with much of what he says, but some of the object oriented references are good books (just don't drink the "we don't need service layers or DAO's" cool aide he's been imbibing).
I wouldn't focus on c# just yet. Syntactically it is a pretty impressive language (arguably better than Java as they had the time to look at Java and figure out where it went wrong), but the patterns that most .NET developers use are really not very well thought out (page controller vs. front controller, master pages for layout inheritance, etc.). Oh, and one of the definitive references is Martin Fowlers Bliki - some great resources there.
Once in a while you might want to check out the archives on this blog. Most of the content assumes a fair level of OO knowledge, but I think some of the posts are fairly useful.
Good luck with the journey!
You say "I think one of the issues is that learning OO in CF is still a matter of digging around on various blogs rather than just buying a particular book". Developers should not learn OO in terms of CF they should learn OO. OO is not about DAO's, Gateway's or other patterns. It is an approach and a technique to developing software programs. There are plenty of good books on the market and I would never recommend any of the pattern books or specific implementations of OO (such as DAO's, Gateway's) as a way to learn OO. IMHO, that's part of the problem. Learn OO, first. Books such as 'OOP Demystified (Demystified)' or 'An Introduction to Object-Oriented Programming' (both and more can be found by searching <a href="http://www.amazon.com">Amazon</a> for <a href="http://www.amazon.com/s/ref" target="_blank">http://www.amazon.com/s/ref=nb_ss_gw/102-7083758-7264953?url=search-alias%3Daps&field-keywords=Object+Oriented+Programming&Go.x=0&Go.y=0&Go=Go">Object Oriented Programming</a>) Suggesting folks learn OO w/in the context of CF and DAO's or Gateway's is like me teaching my 4 and 5 year olds about numbers by teaching them to add and subtract. If they can recognize what a number is or understand the concept of a number, they'll never learn how to do addition or subtraction. Start with the basics first and then build.
Good point. OOP Demystified is a good book and Simon also points to a bunch of good books on his blog. It is also worth playing around with Ward Cunningham's CRC cards. I guess the issue for me was that I read 3 or 4 books on OOP (includign the one you recommended), but while it made sense theoretically, I still had no idea how to actually compose a real world application. One of the issues is that not enough distinction is made between domain modelling (which the Naked Objects and Object Think guys are focused on) and the patterns required to create scalable OO applications (such as service layers, factories and DAOs as well as other patterns like decorators and flyweights and the rest of the GoF patterns).
On reflection, I would sart by recommending reading something like OO Demystified. It gives you a sense of the idea of OO programming, even though it doesn't really tell you how to do it. I might then play around a little with CRC cards to practice domain modeling and to get an idea of extracting nouns from use cases and the like.
I would then still recommend working up an example wth a DAO, service object and business object to see some of the real world patterns you need to make objects a part of your code base (additional and subtraction may not be the best way to learn number, but without addition and subtraction numbers are not vey much use!).
From there you'll start to see he problems that the frameworks solve and will be ready to pick the framework(s) that best meet your use case.
http://www.remotesynthesis.com/blog/index.cfm/2006...
What do you mean by a service and business object?? Currently, when I develop apps I have my beans, DAO's and gateway's. It works out great for me and has proven real helpful. I have seen other people use CFC's for their objects usually referred to as 'objectName'Service or 'objectName'Manager. Are these types of CFC's supposed to act as a controller?? Somewhere where you put a lot of your logic that happens before a page is requested??
Good to know. I just remembered the bumpy period (everyone sending unsub messages which were then resent to the entire list about 10 times) and never got back into it. Have just signed up again. For anyone who is interested, it is at http://www.cfczone.org/listserv.cfm
Typically you use DAOs for persisting a single object (insert, update, delete and get 1 record from a table). It is really just responsible for the SQL - not for validations, transformations or other business rules (at most it is responsible for database validations to ensure you're not trying to save 100 characters in a varchar(15)). That way, if you ever need to support another persistence mechanism (a different DB, XML files, a web service, whatever), you can just swap out the DAO and you don't have to rewrite your business rules. Usually Gateways do the same as DAOs but for collections of objects.
The purpose of a service method is to provide an interface to working with a given object. So, ProductService will typically speak to ProductGateway and ProductDAO (I put the service, gateway, business object and DAO in the same directory and then make all of the gateway and DAO methods protected so that can only be accessed via the service or (in an active record pattern) via the business object). The service method handles all of the business rules relating to getting, modifying and deleting a particular object type.
The business object is the thing you pass around that encapsulates the values of (say) the product so you can Product.get("Price") in your display code without having to worry about how the price of the product is calculated (that is something that the business object should know).
Everything I have described so far is part of the model.
The controller handles all of the plumbing for interacting with the form, url, session, application and cookie scopes (is cookie a scope?!) and orchestrating the setting of static properties and dynamic parameterizations, the calling of methods, and any logic around those as well as the inclusion of the appropriate view screen(s) and persisting state information via sessions, cookies, URL or form variables and the like.
There again, I also return iterating business objects rather than recordsets for my "collections of objects" so that I can encapsulate getting and setting and use the same code to calculate the price of a product whether I'm displaying 1 product or multiple . . .
All I can say is: Amen. I am *so* tired of the "my framework can beat up your framework" arguments. I saw all this before when I was a woodworker, where there are various "systems" that are analagous to frameworks. Yes, for an experienced woodworker, a system can cut down on the gruntwork, but no system -- or framework -- is a substitute for deep knowledge. But, sadly, there is an appeal to jump on one bandwagon or the other and expend all one's energy there. It's a terrible trap and increasing numbers of framework proponents (of whatever stripe) encourage people to eschew the essential in favor of the convenient.
When I started off as a woodworker, I had a boss who, for one year, refused to let me use ANY power tools or machines. I could not have have a better schooling in woodwork (as opposed to knowing how to operate some machines). At the end of that year, when I did begin to use some machines, I understood what I wanted THEM to do, not what they wanted me to do. I saw other woodworkers, who had not had so kind/cruel (it was humiliating at times) a boss who were completely at the mercy of those machines.
Now, people get the idea that programming is about throwing around TLAs (three-letter acronymns) and learning how to make a blog in 8 minutes. "Woo-hoo! I'm a programmer." No, you've learned how to spout jargon and operate a machine. There's a big difference between the two.
Here's to hoping that people hear what you're saying.
I'm not sure the majority of "public" programmers, to steal Sean's analogy, understand that MVC is a design pattern and really has nothing to do with OO - you don't need OO to implement MVC.
Very fair point. The reason is that going from not getting the basic idea of OO to getting the basic idea of OO takes very little time (an hour? a day? a week?). Going from getting the basic idea of OO to figuring out how the heck to use it effectively takes months or years of practice in implementing patterns. So, statistically the chances are most people are in that second phase, so they're not talking very much about the first.
Heres the bottom line on the first phase. In OO programming, you stick both the data and the functions that operate on that data into a single thing called a class. So, for a Product you have methods like product.getPrice() and attributes like product.Title. In addition, good OO programming suggests that wherever possible you tell, don't ask. What does that mean? It means you TELL the object to do something with its data, rather than asking for the data and doing ti yourself. If you want to display ActualPrice, don't get Price and SalePrice and write logic to display it, write a method called getActualPrice() in the product and let it do all of the work.
This is good because it makes code more maintainable because most of the code affecting the product is right in the product object so it is easy to find all of that code when you change how prices are calculated rather than having to look all over the place to find and fix the code.
There is more to it, but not much. I think someone can get OO programming in 20 minutes. Figuring out how to apply it to a domain model is where all the decorators and DAOs and factories come in and thats what we talk about because that is the stuff we're all still trying to optimize.
Great to hear from you! Of course, I think there is also the place for tools, but they need to REALLY abstract people from what the are doing to where we don't need to learn the patterns and hack around with the code. I know almost nothing about how a java server works and for my CF work to date that has not been a problem. The issue is with partial abstractions which are what you get with RoR or MG:Unity mainly because scaffolding is an intermediate step towards application generation.
I see a point in the near future where app generators are sufficiently robust to generate almost everything, leaving us to specify a small number of things using tight DSLs and just to write the occasional subroutine for calculating x or y that will then be tested for correctness (as far as possible) and then published to the right file statically (or dynamically attached to the right class using mixins) and we won't have to even think about factories or decorators or DAOs.
I'll let you know when I'm finished writing it!!! Also, see my post on patterns = language deficiencies. I just think many OO languages are still quite deficient.
http://www.pbell.com/index.cfm/2006/9/14/Design-pa...
Thanks! As I blog and write about this more I'm coming up with more good example cases. I think that is the problem with most OO discussions. They only make sense with useful examples and way too many of the books use mathematical functions or other stuff that most of us just don't program every day.
Another good one is User.getAge() where the database only has a UserTable.DateofBirth. Brings up lots of interesting issues about true database abstraction when you start to realize that editable attributes and viewable attributes are only overlapping - not identical sets. Will be talking more about that in the upcoming ORM series!
My point is that I think most in the community don't effectively understand the fundamentals of OO. They have a look at examples like yours, and the many others (mostly CF-specific) on the lists and blagas and whatnot. But I honestly don't think the majority of CF'ers really every take the time to do step 1. I think they skip right into step 2. They see an example and they say, oh I get it, I put my data here at the top and I list some functions that work with the data, and that's OO. But they don't really understand OO.
Most of the people contributing to this conversation are exceptional programmers who I have no doubt are familiar with the concepts behind OO. I could use a term like "encapsulation" or "polymorphism" and most of you would know what I'm talking about. Every programmer in my shop has written a CFC, but I don't think any of them could tell me what "multiple inheritance" is, whether or not CF implemets it, and why you would or wouldn't want to use it were it available to you.
My mini-rant here isn't to say that they're bad people or bad programmers, or whether or not using just the packaging aspects of CFCs make code better than it was before, or any of that. I think that those of us who do understand these concepts need to be more careful when educating people who are new to OOP. I don't think that practical examples alone do an adequate job of helping people improve their skills, as much as it gets people to write different-looking - not better - code.
Eric Gamma (of Gang of Four fame) once received an anguished email in which the author lamented that he had been able to use all but two of the standard design patterns, but hadn't been able to squeeze those last two in. It may sound funny, but it's a very natural mistake to make when your "learning" is based on trying to do things "right", rather than discovering for yourself why such patterns can be so helpful.
I think what you are saying is a little different from what I said, but it fits perfectly with what I mean in a broader sense. One of the reasons I started the "building the framework" series on this blog (http://www.pbell.com/index.cfm/building-the-framew...) and many of my other postings was to build common concepts up from first principles.
I'm always amazed when object purists (who blieve that they understand OO, but in my opinion don't understand software engineering) post on the benefits of only having business objects (rather than service layers and DAOs) and they are often basing their arguments on the idea of "good OO programming" (whatever that is) as opposed to meeting the fundamental requirements of good software design.
I'm sometimes criticized for not posting enough code. The reason is that I believe there are many issues that need to be addressed that are more fundamental than code and I try to cover those on the blog. I wuld say the majority of my postings have no code at all, and I hope that they go towards providing some of the underlying concepts which are so important in creating well architected applications - object oriented or otherwise. If you see an article I post with code in it, you can bet there were probable two or three related articles before building up the concepts from first principles.
The Gamma quote (or one very similar) can be found in an interview online that I would recommend everyone trying to learn OO read thoroughly:
http://www.artima.com/lejava/articles/gammadp.html...
Interfaces is a really interesting starting point for OO design as it is a perfect lead in to polymorphism. I often start with encapsulation when I discuss OO just because it seemed to me a more fundamental driver of the benefits of OO design (primarily greater maintainability by decreasing coupling between classes and localizing changes), but interfaces are also about the whole idea of encapsulating how something is implemented and just describing (imperfectly in current languages) the contract between the classes so I can see how it could become a single starting point for all of the main underpinnings of OO design. I really will have to catch one of your classes one of these days!
I think the lack of examples (not code examples) outside of DAO, Bean's, Gateway's etc is certainly part of the problem. It's not the lack of code as much as the lack of examples folks can use and apply in other areas. Your getPrice example is a good start but just too basic IMO. It just doesn't get to the meat of OO. During my master's program we had to write a simple vending machine. The vending machine had 4 parts (or personas); a buyer, a sales person, a banker & a vendor. The sales person orchestrated the sale and communicated b/w the buyer, banker and vendor. The personas were only allowed to ask questions of each to accomplish the task.
Why was this a good example? Well 2 reasons.
#1 Everyone has used a vending machine and I'm sure has a pretty good idea how one works. The 'sales person' ask the banker to collect money. When the banker says yes we have enough, the sales person 'asks' the buyer for their choice and then gives this info to the vendor. Who responds accordingly and well the rest (if not all of this) is self explainatory.
#2 (and more important than #1) is this example teached basic fundamentals of good OO design in a way folks can understand. Does the banker really care if the vendor has a specific type of drink? No. Should the 'sales person' be responsible for collecting money? No. (Encapsulation & separation of concerns) Also the applicable to other areas (ones I never realized at the time). One such area, MVC. The vending mahine's behavior bears a striking resemblance to MVC and when I starting digging into MVC my vending machine exposure was a perfect base for understanding MVC. Basic concepts built one on top of another. And yes getPrice is certainly one of the items w/in this application.
In the end, "it's all good" IMO as it makes people think. That's the key! Force folks to think before making decisions.
-Jason
P.S. You can say "it depends" is a cop out but its the truth. There is no nor will there ever be a simple heuristic for which framework to choose. I use Fusebox for our main system at my company because of the nature of the application. MG nor MachII solve the problem as cleanly and efficiently as FB. Do I use FB for everything? Nope. So I guess my heuristic is use what works.
There is definitely a place for those kind of learning exercises. Coming form a procedural programming bckground, it can take a while to get used to "telling (the object what you want it to do), not asking (the object for the information so you can do something with it). I mentioned Ward Cunninghams CRC cards as while they were designed as a teaching tool, they are a great way of both learning and applying OO principles to the domain modelling process.
However, for people who've been programming for a while, I think the best examples (and the hardest ones to find) are real systems. A vending machine is fine, but it is much easier to figure out what you're doing if you can look through a real shopping cart, newsletter or cms. It is why the sample applications that come with each framework are so useful - along with the cfpetmarket applications, but the last time I looked through them I didn't feel that any of them was a great example of best practices OO design from end to end (if anyone would like to suggest that I revisit one of them that is a great example of OO design, please let me know, and I haven't looked at the Transfer cfpetmarket version yet - just downloaded that last night).
As for "it depends", it is both the truth (it always depends) and a cop out (imagine if your boss said that in answer to when/if you'd be getting paid this month). Unfortunately, "use what works" isn't a practical heuristic as it wouldn't allow other people without experience in the space to make good judgements.
What would be some tentative heuristics? Well, firstly I would suggest that if you have a deadline for a real project and no OO experience, I'd skip MG and Mach-II. I think the learning curve would be too steep. Another would be that if you are fairly new to OO, you should probably start with Model Glue as it is a little simpler than Mach-ii, but I'd start with 1.1 so you don't get confused by ColdSpring and Reactor right off. Once you start to notice how much of a pain making all of your singletons available to each other is, you're ready for ColdSpring, and when you're sick of writing your 5th DAO (and have puzzled over and figured out where to put the code for "hasmany" types of relationship queries), it's time to start playing with Reactor. Shortly thereafter I'd make the jump to Unity to get better integration out of the box, and around the same time I'd suggest at least playing with Mach-II to see the flexibility of their slightly more complex implicit invocation model.
I would say that would be a reasonable set of guidelines as an approach to getting up to speed with the frameworks and would make each step of the learning curve a little more manageable. Of course, you can argue (very easily) with each of those suggestions, but to someone who doesn't know where to start, I think they'd be more useful than a simple "use what works". If they knew what worked, they wouldn't need to borrow someone elses heuristics!
Best Wishes,
Peter
I answer to the initial proposition "Frameworks Suck", here are a few comments from one of those "public developers". Actually I'm a bit scared to call myself a developer on some forums, but you guys seem pretty objective. I came to CF programming from an IT background, but not a strict development one. I started writing little apps for myself. I now develop smallish web applications for one of the largest financial organisations in the world - intranet for the most part. Coming from a configuration management background, I looked at the start to find a way of of organising and managing the code I wrote, and starting using Fusebox. For me it is probably the one reason why I've managed to make a modest success. I like Fusebox because it is to my mind a lightweight framework. It doesn't conceal much, it's not too much of a black box. However it enables what I, and my clients appreciate above any more esoteric qualities. Here's how it works
1.They always wan't something quick
2. They always want to extend it
3. They don't want it to break
Now I'n no theoretical expert like a lot of people in this discussion, but these goals have been achieved and largely due to the simple benefits of using the franework
1. High visibility of processes
2. Modularity/reusability
3, Time saving concepts (integrated security, plugin and other processes)
I wonder if I'd dived straight into development, made all the mistakes, come up with my own solutions and frameworks if it would really have benefited the clients? I might have been better equipped to join in discussions like this, but for me anyway that's not the point. I'm just grateful that there are people out there whoo have made it possible!
Finally a little background on one of the apps I'm repsonsible for, to put this in perseptive.
An educational application which started off as a simple means for users to select courses from an external application (SAP/people soft) and store them for use in goal assessment programs. Started of as a Fusebox 4.1 app, but pretty simple. It worked ok, so then the following happened.
Can we now add a booking process?
Oh, that's nice, now can we manage course resources (rooms materials etc) - sure we'll just plug it in
Right - now we want some approval and feedback workflo.....
Oh and when you've time can we add the ability to propose vet and submit external courses and track vendors and assign manage budgets and .....
.... Oh - and this SAP/People soft back end - do we really need it to manage the catalogue, can we just write our own?
I'm not trying to sing my own praises, but I honestly believe this was a success story for using frameworks.
With all the talk I have had a look at the extending things using Reactor/Transfer or some other ORM components. I'm not convinced that I will make the jump. Seems to me that this is mainly a time saving exercise for writing CRUD processes, which is not much of a chore and for most objects it's a one off task. SImilarly with Coldspring - might take a look, but not convinced that it will improve maintainability and robustness. At the moment these are not issues for me
Thank you for that post. I can't tell you how great it makes me feel to hear from someone who uses frameworks for what they're meant for: to achieve successful projects. You inspire me.
Hal
For someone without an object oriented programming background, fusebox is a perfect solution. It allows you to structure your code logically, it is well documented, there are books, sample applications and a good community of other developers to learn from. It simplifies some tasks and stops you from writing complete spaghetti. To the extent that fusebox meets your needs I wouldn't even consider moving to anything else.
If you find yourself developing more and more complex applications over time, you may find limitations with writing procedural code. You may start to notice that it is getting hard to maintain your applications just through fusebox, UDFs and custom tags. If that ever happens, you may want to consider learning about the benefits that OO coding provide. If that never happens (and it is quite possible that you will develop great applications that never happen to hit that complexity threshold), the only reason to learn about OO or Reactor or ColdSpring would be for the same reason you'd take up horticulture - if it happens to be fun for you!
OO programming is not "better" than procedural. It can make large applications easier to maintain, but that important benefit comes at a huge cost in terms of the learning curve and I would make only two comments: (i) if you don't need to learn OO programming then unless you want the skill on your resume or for career development as a programmer (or for the fun of it), don't learn it! (ii) If you may need to learn OO programming, try to start a really long time before you need to actually deliver a working OO application - it really takes a while to get comfortable with all of the concepts.
As for Reactor and ColdSpring (ESPECIALLY ColdSpring), to put them into a bigger perspective, they are designed to solve problems CREATED by OO programming. If you're not writing OO code, there is no real reason to look at them. Similarly, if Fusebox works for you with procedural coding, I can think of no reason to make the leap to Mach-II or Model Glue (1.1 or Unity). And as I've suggested above, if you DO need to "go OO", I'd start by learning the basics without a framework and only drop in MG, ColdSpring and Reactor once you've experienced the problems they solve and "feel the pain" they can relieve.
OO programming is a great approach for developing applications where maintainability is becoming an issue using a procedural style, but it is not "better". There is a lot of discussion about it because for those who need to learn it, there is a lot to talk about and figure out, but all of that noise shouldn't stop developers from using existing frameworks to do what all of this is about in the first place - deliver applications that provide business value!
Hal, Do you never sleep?! I'm in the UK on business so it is mid morning - what's your excuse :->
Best Wishes,
Peter
As far as Fusebox goes, I've written many FB apps that were object-oriented. Fusebox is perfectly amenable to OO. The big difference between something like Fusebox and Mach-II is whether the framework code is written as an OO app. For most people, whether it is or not doesn't make much difference.
The joys of Transylvanian travel I guess :->
Of course, FB is perfectly amenable to OO development, so for someone used to Fusebox, it may be the perfect way to start to code in an OO manner (and wth FB 5 the core is OO as well). My point was more the other way round - that Mach-II and MG and really not great for writing procedural code.
Thanks for the long reply. em..... I thought my applications did use OO concepts as far as is possible with CFCs. I could be wrong of course......
Oops! Didn't realize that - sorry! It is just that you don't NEED to use OO concepts within fusebox.
If you're using CFCs, you may find eventually that ColdSpring will help. The question is, if I am in the ProductService and I want to use the UserService, how do I call it? At first you might just stick it in application scope. A little later you might write your own service locator, and eventually when that has too much code to be easy t maintain and read, then you might want to graduate to CS. Other reason to consider CS for creating your singletons (it CAN be used to create transient business objects - but that is a whole other discusssion) are that you get AOP features (aspect oriented programming features) allowing you to do some VERY cool things with cross cutting concerns. Most common examples are logging and security, but I believe it was Chris Scott who wrote a very cool demo showing how you could use AOP so if your database was switched off, it'd switch immediately to a cached versio of the data. It was more a proof of concept than anything, but it showed the versatility of AOP.
As for Reactor, to me the biggest benefit is when you're in a hurry to build your apps. A lot of typing is required to create all the DAOs and Gateways (if you use them) and beans. I save much of the typing by using base classes, but it is still pretty cool to be able to just hook up a new DB to MG:Unity and have naive admin screens and most of your data logic up and working pretty much without effort. If you're working on a single application for weeks or months it isn't such a big thing, but if you've got an app with 20 business objects you'd like working in a day or two it can sure speed things up!
With Reactor et.al, I haven't really looked at it that much, but a lot of the delete/update processing that we encounter is rather complex, (not just RI concerns either). It seems that you will probably always have to cater for exceptions from the standard 1-1 1-many, many-many relational scenarios - will ORMs help beyond this stage? Especially when some tactical de-normalisation is applied for performance reasons. Additionally, the most complex data access scenarios tha we encounter are actually to do with reporting where we have queries that would make your eyes water. These will always have to be handcrafted I guess.
I'll do what you suggest, and if I seem to be tying myself in knots with maintaining object dependancies and deciding where to do what, I'll have a look at Coldspring
Thanks for the all the advice
No problems! One of the limitations with most ORMs is that they make it easy to do quite a few things, but for data models that weren't designed around the ORM (or aren't consistent with the way that the ORM thinks about things) then at best they are no help and sometimes they can even be a hinderance.
As for reporting, I think there is a place for some metaprogramming and a domain specific language to try to simplify the creation of some of the reports, but I'm not sure that an ORM would be the right place to put such code, and there will always be reports that don't fit within any simplified pattern.
We have imperative programming languages like CF and declaritive languages with the richness of SQL for a reason - some solutions can't be simplified to fit within common patterns. However, I do think in the future we'll see a lot more people starting to use scaffolded/generated approaches for many applications. For instance, Microsoft Word probably doesn't work exactly the way you want it to, but you'd have to have a heck of a use case to write a word processor from scratch in-house these days. Similarly, I often help clients to subtly modify the way they achieve their business objectives and it often allows me to generate sites in minutes instead of having to code it over weeks or months. The question is usually whether the performance or flexibility of a truly custom solution provides sufficient business benefit to outweight the fact that it'll cost tens or hundreds of times more to use such an approach. Often it does, but not always!
There are plenty of ways that a framework can suck but each discussion is unique to the framework being evaluated. It might be buggy, it might have an invasive API, it might be difficult to extend, it might be difficult to use, it might not handle corner cases well, it might be slow. Saying that all frameworks suck because they force you into doing things a particular way (its API) is probably just as stupid as saying that all programming languages suck because they force you into doing things a particular way (its syntax). In a field as complex a programming, any sweeping generalization should be met with much skepticism.
I don't mean to be rude and post harsh comments on your blog, but when I see a title that looks like flamebait I'm happy to respond accordingly!
As you can see from the comments (mine and others), the real issue is with OO novices starting with a complete framework like MG:Unity and ending up with an almost complete OO app that they can't modify intelligently because they have no idea of the patterns the framework is using or why.
I'm more than happy to defend the title as I think it started a debate which was valuable (I certainly got a lot from the comments on this one). Some times it takes a controversial title to stimulate a more nuanced debate.
Best Wishes,
Peter
I don't have a problem with any type of framework. They all have appropriate use cases (again, read the comments, not just the headline!) I think the risk of any framework is that while it helps you to use best practice patterns, yu can get into trouble if you do't understand what they are and why they are. I think that people should use frameworks (wherever possible) to solve problems they currently have (or at least conceptually grasp).
For me the perfect example is ColdSpring. Try explaining to a programmer with no OO experience the benefits of a DI framework and yu're going to have a confused programmer. Tell someone who is having problems getting their singletons to interact that there is an easier way and yu'll have a convert in no time!
The strength and weakness of full stack frameworks are that they solve a LOT of problems. To really understand them, you need to understand a good number of the problems that they solve. Its like Seans comment about someone using Visual C++ being unable to write the 10 lines of code required to complete the generated app as they had no idea what they'd created (and when I FIRST wrote a VisualBasic app many years ago I felt the same way for a long time).
I'm really saying that frameworks solve problems and that there is an inherent value in understanding the underlying problems. I suggested that writing your own framework is a good way to understand the issues. It is like Hal being forced not to use power tools for the first year - I bet he was a much better woodworker because of it.
While frameworks are great (including full stack frameworks), there is also a need for understanding the underlyign patterns and problems so people can more intelligently choose or use frameworks rather than being confused and controlled by them. MG:Unity (to me), is not the best way to learn OO programming. It is a wonderful toolkit for quickly generating OO apps and is a great case study for many best practice patterns.
Back to the car analogy. Ferraris are cool and fast, but I don't recommend them for leaning to drive in!
Best Wishes,
Peter
I find it very clever how you turned a 'Frameworks Sucks' post into, Frameworks aren't a good way to learn OO post. Frameworks are not meant to teach OO. That's not their purpose. I definitely didn't read "I wrote MG:U so CF developer could learn OO" anywhere in the release notes.
I find it completely irresponsible to lead a junior developer to believe they shouldn't use a framework. Unless of course you are trying to get them fired, because that is what happens in the real world. I've had great success teaching junior developers the finer points of programming (not necessarily OO) while having them work on a framework-based app.
To get straight to the point, I think there is a subset of developers who want to act like they write 'Enterprise Applications' when they really do not. They throw OO terms around to inflate their ego. Instead of truly writing large enterprise-level apps and managing large teams of developers, they write multi-page dissertations slamming proven solutions just to drive traffic to their blog.
This post isn't sparking a debate, it's stating the obvious. Frameworks are a good way to learn, but not the ONLY way to learn. Frameworks don't suck. People on soapboxes suck. Honestly, I don't even know why I bother..... you can save yourself the effort, I'm not going to read another one of your multi-page responses.
I think that if a junior developer has an experienced mentor, a framework provides a great environment for teaching them how to implement a well architected OO application and I am glad your junior developers have had such a resource. Not all developers are on teams with an experienced architect such as yourself and I think many are getting confused because they are using tools that they don't understand.
As for the personal attack, I'm sorry you don't find any value in the great comments elicited from people like Hal and Sean (even if you find the original post uninteresting). Maybe I am just a little less experienced than yourself. I personally found their comments interesting and enlightening.
Best Wishes on the new position at Adobe
Peter
The biggest problem caused by OO is more typing to achieve the same functionality. Creating well encapsulated code takes extra typing. You have to create all the cfc's, document their cfarguments for the properties, instantiate the cfcs at the correct time, pass them in all of the information they need access to . . . OO code is typically more complex and more typing than similar procedural code. However the complexity is better abstracted so it is easier to get your head around complex domain models, to know exactly where the code is for each element and to have a pretty good idea that changing the way you calculate ProductPrice in the product object won't break all of your view code or a little subroutine in your cart controller.
Know how you feel though . . . OO can seem paradoxical for a while!
Opinions:
1. If upgrading the framework/methodology makes the application obsolete, rename the framework/methdology! Making an old app run in a new version should be VERY MINOR changes. (That is why we stopped doing fusebox. KUDOS to Sean on Fusebox 5, he broke the broken code trend! He did an upgrade in Fusebox right!)
2. Frameworks should have seperation from methodologies. When the two mix then you cannot have different level developers learning and building apps for the same site unless they dumb down or geek up the code for all apps. (Let the methodologies mix!)
3. One size doesn't fit all. Eventually some apps will outgrow simpler frameworks and methodologies. It is also a waste of resources to scale up smaller applications to complex enterprise specs, when simpler good business specs would have been a much greater ROI, and done all that was needed. In fact, those apps that outgrow the system usually have so many other changes, that they need to be rewritten at the point they should go enterprise. So the deep initial investment is lost on two fronts.
4. Seperate the presentation and the data out of the business logic regardless of the level of app you are building as soon as you can learn how. This is what MVC is actually about. It is about seperation of function. When you start out with a framework that allows for stand alone template pages, and allows other methodologies you can mature to switch based apps. Then you can mature to MVC oriented apps if you like that path. (Or you could roll one of your own!)
5. Write the framework so it equips with things like presentation/content handlers, authentication, API, etc. Make sure they are extensible. Make the framework hi-tech, and the interface low tech to implement! Make it stay out of the way, but warm it up so it will be ready to go if requested.
6. Make tools that help do the mundane tasks that get done over and over and over and over and over... to save time. Custom tags, CFCs, javascript libraries (and of course make it work with a number of other good libraries already out there, no one can do all the work alone.), Flex components, etc. Also create development tools that do things like Fusebuilder for Fusebox!
7. Write apps that can be packaged up so you can have reused applications and not just code segments. With shared authentication and presentation under a common framework it will be very fast to deploy. Place framework files on server, set up database, create custom skin (or plug in exiting skin for presentation), and install apps. Applications should run on sites without rewritting them for authentication or presentation. Here is where a framework shines. Even if the apps are written in different methodologies, they should still be able to run on the same Framework.
OK... so I am likely the only nut on the block who is seeking to achieve all these things in one framwork. Work is progressing nicely. Hope to show everyone how our Framework, 3 methodologies, ORM (2 styles), and much more all work together. (And how many pieces can be pulled out to use in your own software without our Framework.) It's quite interesting all that we are learning along the way!
@everyone - I'd forgotten about this post about why not to use Cairngorm (A Flex framework), but it is making same point that I was - learn what you're first doing and then you're ready to select a framework.
http://weblogs.macromedia.com/swebster/archives/20...
Thanks it helps me a lot
Of course, FB is perfectly amenable to OO development, so for someone used to Fusebox, it may be the perfect way to start to code in an OO manner (and wth FB 5 the core is OO as well). My point was more the other way round - that Mach-II and MG and really not great for writing procedural code.
Is OO the ultimate example of MVC? (It seems frameworks have gone ultra OO.)
One of the things that we have been proposing to the community is the ADS rating system. (Accessible technology, DRY, Sustainable) Does it require OO to make a perfect score on the ADS rating for a framework. Let's just ask simple little questions.
1. Does OO provide accessible technology?
When you have to learn more, and the teaching of those concepts isn't plain without years of experience it "may" score hire in sustainable, but certainly not when it comes to being "accessible". Therefore the cost of maintaining such an application must by needs include staff with specialized skills.
2. DRY (Don't Repeat Yourself)
Does it take turning an entire framework and the exercise of using that framework (which would be called a methodology) into OO coding? Is it possible to have a mix of OO and non-OO and still be a Sustainable fast delivery platform?
3. Sustainable
Now we all know on the front side that OO can improve things... but how much OO do we need, where do we need it? It seems there is a "MYTH" that making something OO makes it better. While there are many times this is true, the global push of some to OO is sort of a techno-cult. (sorry, but it is) Spaghetti code can come in procedural code or objects. The fact that there are patterns to describe how to "weave the spaghetti" doesn't preclude it is not another form of spaghetti.
With that said, please don't misunderstand me. I am very much in favor of OO and use it also. Yet the need to move anything and everything into OO that we touch shows a gross ignorance of the power of things like custom tags in ColdFusion. Yes, it appears we tossed the baby with the water when CFCs came into being cool. We should still use good design patterns, but doing OO so we can do design patterns is... counter intelligent. Considering and using design patterns to solve or design a solution can be good... but not if we feel we must. This approach can be a way to complicate things just to be cool or charge a higher dollar for something that just isn't needed.
There is no silver bullet (except maybe code gen :-) ). OO isn't the solution to every problem. It can be looked at as a design pattern with design forces that affect its suitability for a given project. That said, the more OO I do, the more ways I find I can use OO programming to create maintainable code quickly and cost effectively.
The biggest downside to OO is the learning curve, but if you're serious about software development you're going to want to be competent in procedural, OO and functional paradigms to have a well stocked toolchest with which to solve your problems. I don't think OO is the ultimate solution, but I think that an indepth study of the paradigm repays the effort many times over.