Object Oriented Programming And ColdFusion - What's The Point?

Posted October 27, 2008 at 9:10 AM by Ben Nadel

Tags: ColdFusion

Reader Comments

I don't see pure OO as a goal or a target. It is one way of looking at an application that may help you to do a better job of putting behavior alongside your data (which typically is good from an encapsulation and information hiding perspective).

Some of the stuff like domain objects not being able to persist themselves, I just flat out disagree with. I think it's great you took the course, and Hal is incredibly smart and knowledgeable. I'd just look at all the material you covered from a programming, first principles perspective (will this create a more maintainable app, etc) and then ask yourself which of the principles will make your app better and why.

It's important to understand we're not in the business of modeling real world objects - that is not what OOP is about. However, we may pretend that we are doing that to help us with designing parts of the domain model.

http://www.pbell.com/index.cfm/2008/10/27/I-Dont-Care-What-An-Object-Is

@Peter,

I definitely agree that we are not in the business of modeling real world objects. I think that is an OK way to start, but I think it gets way too muddy way too fast. As you have read in my previous posts on using Human as a model. When we come at it from a real world standpoint, its starts to become a philosophical discussion on what is really Human.

But, really, we are not concerned with existentialist debates - we are concerned with what an object is in terms of the System or Domain in which we are working. In such an environment, we cannot have nuances of correctness or validity. So, I agree that modeling real world objects is not our goal.

I think also what makes pure OO so hard to wrestle with is the fact that one of the big payoffs of it is that we can reuse our code in different systems within in the same domain. This is great - but how many of us actually do that? How many of us have a catalog of domain-specific CFCs that we can swap in and out of applications.

I think you've told me that you have like 4 physical CFCs in your SystemsForge stuff right? So, for you, the concept of reusing CFCs in different applications within a single domain is laughable as a goal - it would be very complicated for you to port a CFC to an application without also requiring LightWire and all the other aspects of your framework.

And don't get me wrong, I am not dumping on your strategy at all. If anything, this is a perfect example of where you are optimizing for your own goals: How can I most efficiently and easily create software that works. This is an awesome goal and I think the one that we are all striving for. What I need to do now is take the principles that I have learned in the class and see how I can apply them to my software development whether in whole or (most likely) in part.

At the risk of sounding quite naive here, what are some examples of applications that have behavior (and thus are more suited for OO)? The majority of web sites I visit are simply there to show me some data. Online banking, email, shopping, news, blogs, forums, facebook, ... are all just UIs for different kinds of data.

I could possibly see how video games or virtual reality UIs begin to get into behaviors. In a lot of OO intro materials you get example of a Dog object that has a bark method or a Car object that has a start method. That's good for getting the concept, but unless you are building a video game, you probably don't need a dog that barks in your application.

What are some common behaviors I would see in non-video game apps?

@Matt,

I think it's hard to find a system that is 100% behavior based. However, I think that most systems have *some* aspect that is behavior based. For example, in an eCommerce site, your Shopping Cart should probably be a CFC that can handle cart behaviors. In a banking system, you must have work flow systems that have decision logic that can be encapsulated.

I am new to this, so my examples are pretty weak :) But, I think that many systems can be heavily object-based without it being a totally OO system.

@Ben, A few comments!

> one of the big payoffs of it is that we can reuse our code in different systems within in the same domain

I completely disagree. Just because you are modeling the same class of real world object in two systems it is quite likely that they'll actually have different behaviors and properties as the two different systems will often implement different subsets of possible real world behaviors or will even use different conceptual approaches to the same real world objects. In my experience, reuse of domain objects between distinct projects is a fairly rare and limited situation.

> I think you've told me that you have like 4 physical CFCs in your SystemsForge stuff right? So, for you, the concept of reusing CFCs in different applications within a single domain is laughable as a goal

Well, actually I DI reuse objects between projects (notwithstanding what I've said above, because I have a lot of fexibility to direct the implementation details of my projects, I actually can quite frequently reuse domain objects between projects with fairly modest changes to their behavior, relationships and properties) - I just describe the objects using XML rather than coding them using CFC's.

> What I need to do now is take the principles that I have learned in the class and see how I can apply them to my software development whether in whole or (most likely) in part.

+1!

@Matt, I find my objects start getting behavior when the data isn't quite enough to describe everything. It starts simply when I need a DisplayPrice for my Product. It might encapsulate simple logic (If DiscountPrice > 0, return DiscountPrice, else return BasePrice). In my cart, the ItemTotalPrice is probably ItemUnitPrice * ItemQuantity (or even Product.UnitPrice * ItemQuantity depending on when product price updates affect the items in the cart). Those are the simplest possible behaviours as they're really just encapsulating the business logic required to get a property that doesn;t exist in the db. Same thing with a User.getAge() that'll calculate the age (which is not persisted) from the dob (which is).

Other more obviously behavioural behaviors would be things like Newsletter.Publish() or even site.Publish(). Project.generate(). page.display(). These are examples of methods I have in my apps.

You could also have things like message.send() and I find it perfectly acceptable to have things like NewProduct.validate() or NewProduct.save().

You could have a User.upgrade() method which would validate the request, change their status and persist their new status in the db (some composition would probably be involved - you probably wouldn't want to be writing SQL in your domain objects directly).

The common thread is that we're putting behavior and properties into one place to hide as much information as possible and to minimize coupling, so if I decide to change how I calculate my Product.displayPrice() logic, I change it in the Product object and because all of my screens just call that one method, I don't have to worry about changing the code in other places, hence making it easier to maintain my app.

@Peter,

>I completely disagree.

I agree with you in practice; I have never really reused objects between systems other than copy-paste-modify. But, I think one of the goals of pure OO is stop people from copy-paste-modifying. Think about something simple like a Float or something fairly complex like and Xml Document - these are classes that you want to be able to reuse across domains. I think having a float mean something in every system would be very confusing.

Of course, floats are very simple, and even XML Documents are very simple - but that is why they are the most reusable. Not *all* objects are supposed to be reusable across the domain. Some objects must be system-specific otherwise, our apps couldn't work :)

To me, I think one of the hardest parts to grapple with as I learn is the trying to discern which objects are meant to be reused and which are meant to be app-specific. And quite fankly, I don't really have enough experience here to argue one way or the other.

@Matt

. . . continued . . .

I never ask myself whether a real world page will know how to display itself or whether a real world newsletter will know how to publish itself. Why would I care? Why would that be important to me? What value does asking that question provide me with? Rather I ask whether the behavior is cohesive with the objects other behaviors, whether the class file is getting too big, whether it'll help to make the app easier to maintain., whether it'd be easier to test if I delegated the behavior to a composed object, whether adding a composed object might cause major performance problems if there were arrays of the object being displayed in my ColdFusion apps. Those are the kind of things I'm thinking about and I'll often trade one heuristic off against another. But I never worry about what a real world object would do as I don't usually find that to be relevant to the process of creating maintainable apps.

To each their own, however.

@Ben, I hear what you're saying, but my argument has for a long time been that in practice OO provides for greater maintainability but NOT for greater reuse and this seems to be a pretty common opinion. I wrote something about this a while ago:

http://www.pbell.com/index.cfm/2006/6/26/Maintenance-and-Reuse-One-Out-of-Two-Aint-Bad

Of course, in the domain of programming there are objects you'll be able to reuse. As you pointed out an XML document or a float will probably be the same across the majority of applications. So are generic DAO's and Service classes and IBO's which is how I get a good level of reuse of my base framework classes across web applications, because they are the same domain and I have control of the business rules I choose to implement within that domain of web applications. However, in my experience, the behaviors, properties and sometimes even the relationships between domain objects in rich OO apps are seldom reusable as is between applications.

Think of it this way. You could create a standard e-comm app and sell it to four people. procedural or OO, you'd be reusing code which is generally a good thing. But now try going to Amazon, Chevvy, Lenovo and a PriceWaterhouseCoopers. Ask each one what a product is in their domain and see how easily you'll be able to reuse your domain objects.

Typically the benefit of OO programming comes as the domain model becomes richer, and in my experience of building hundreds of web projects, the richer the clients domain model is, the more likely it is to be full of business rules that are unique to the way that they see the world and therefore the less likely they are to be reusable across apps.

There is no question that for simpler domain models you can reuse code. We often reuse page, user, newsletter, product, cart and a bunch of other items (we usually have to tweak a few properties as each client has slightly different needs and believe me - the solution is NOT to have a set of uber objects with every possible property and behavior - been there, done that, got the t-shirt). However, the richer the domain model, the more likely it is to be specific to the world view of that particular customer and the less likely it is that you'll be able to reuse the code.

@Ben,

I think another important point to make here is that not only are we not modeling idealized real world objects because of technical considerations (we need to model the behavior required to implement the essential user stories - not the whole universe of possible behavior), but in addition to that, our clients actually have their OWN conceptual model of what a product is or what a customer is or what another object is, and those conceptual models often vary widely between businesses. In some businesses a contact is a type of person that may or may not be associated to a company. In others, a company simply has a ContactName property. You can model the true real world relationship however you want, but what really matters is the conceptual model that the client has underlying their domain objects and often the same domain objects are thought about differently in different companies. That is what really kills the general re-usability - we're not modeling the same objects and the different clients conceptions of those objects vary - stopping us from reusing the same objects between those clients.

So when you say behaviors, I am not sure I understand. Take OOPhoto. Let's say you had functionality to:
- order in album, rank (favorite), print, resize, rotate, write caption, move, copy, make album cover, write on top of picture, tag, declare face-recognition, download, share, blog, embed, zoom, undo, next/back, replace, delete.

These are "some" of the things you can do in Picasa, for example.

So are you saying, none of these are behaviors? Wouldn't a picture know how to rotate itself? How to write a caption for itself? How to validate that the caption is acceptable?

OOP Does make alot of sense to use if you are coming from the systems analysis and design approach rather than just sit down and start coding.
OOP has come intuatively from UML.
With most large companies the senarios are planned out with use case diagrams and use case class diagrams. so from these you create your classes which are your objects.
so from that angle it is the easiest way to go about it.
if you are making a basic application then there is not really much need, but once you start to think in OOP they you just start to use it weather you need to or not.
Generally it just makes it easier to add extra functionality and for future developers to understand your code.

I just want to make sure that the anemic data driven apps that we are so often confronting are appropriate for OOP. There is a lot of overhead for object-relational mapping (even though CF9 will supposedly have it built in). And, to be frank, OOP breaks some of ColdFusion's Rapid Application Development tools as we know.

I'd like to see an honest discussion about the "it depends". I've seen everything but the "it depends" clarified.

@Peter,

I am leaning towards agreeing with you - OOP is more about maintainability rather than reusability. That is where I am seeing the real payoff, and if you go that route, I think the rules definitely change in the way you model your domain.

Also, when I considered reusing things cross-app, I never really thought about it in terms of cross-company. I meant really different apps in the same company.

@Glen,

Yeah, but OOPhoto doesn't do that :) But, yes, I think those are behaviors. I thought about the idea of resizing because photos in OOPhoto *do* get resized. In fact, they get resized three times:

* Original
* On Screen
* Standard Thumb
* Square Thumb

Now, here's one of the issues that I wrestled with - a photo *should* know how to resize itself; however, my photos need to be resized in a particular way (the square one needs to resize and crop). Resizing can be generic, but once you resize and crop, now we are talking application-specific behaviors.

This is OK, but to have a photo resize itself with a sort of GenerateSquareThumb() method or something, we have to get rid of the idea of reusing this "Photo" object in other applications. OR, we need to sub-class it and add special behaviors for just this app.

But, that seems a bit excessive to me. That is why I am starting to move to the Peter Bell camp that OOP is more about maintainability and less about reuse.

Still sorting this stuff all out.

Peter makes sense because he is a pragmatist.

He wants to make the most money, which means completing projects that meet every objective as quickly as possible. While pure theoretical OO is nice, you can spend a whole lot of time preparing for something that is a guaranteed flat result.

Why object-oriented programming? I think the benefits to decomposing your application's functionality into discrete pieces are almost too numerous to list. You can isolate changes to one part of the application, reuse components, unit test one tiny piece at a time, etc, etc.

But object-oriented programming is only one way to chop up your application. We've been inventing and refining ways to do this since the 1970s, when David Parnas introduced modular programming. Paradigms from functional to object-oriented to aspect-oriented have this goal in common.

As others have said, it is not a choice between OOP or nothing. Any way to modularize your code will improve your life and the lives of those maintaining your applications in the future.

@ Matt Williams

I just spent the last three weeks rewriting the core spidering robot for my website, WoW Lemmings. It is a multi-threaded CF app that is composed of two key parts:

- The main object that contains a list of spiders, and has methods that manage the spiders across threads, as they touch URLs, scan data, and update/refresh/delete a database.

- Multiple spiders that derive from a base spider class, which inherit common functionality that all spiders use. Derived spider objects implement an interface that requires them to supply certain methods back to the main object, which are either declared in the base spider or are overridden and implemented in a new and specific way in the derived spider.

The spiders themselves, and the parent object that manages them, all have properties, behaviors, etc. The application as a whole demonstrates common OO fundamentals, such as encapsulation, polymorphism, and inheritance.

This may be a more appropriate "concrete" example of an application as it pertains to OO-development in use within ColdFusion.

I think the struggle procedural CF developers often have with embracing OO is that it causes you to approach the development of an application from an entirely different point of view.

Ben's original quote: "Photos don't know how to do anything. Galleries don't know how to do anything."

I wager that with a bit of rethinking on the part of the developer, it wouldn't be too long before you had the following lines of code in your application:

galleryObject.DisplayPhotos();
galleryObject.DisplayPhotosByGrid(4, 3);

and

photoObject.Display();
photoObject.DisplayThumbnail();

Suddenly, photos and galleries now know how to do something.

As one of the people who sent Ben and email asking "What's the point?", I am happy he wrote this post. I didn't ask "What's the point?" because I think OOP is bad, but I wanted to hear from someone who had put for the effort to learn OOP to see if there is something I am missing, and to evaluate weather I should put forth a similar effort.

I appreciate how David said:

>...it is not a choice between OOP or nothing. Any way
>to modularize your code will improve your life and the lives of those
>maintaining your applications in the future.

I have done a lot of reading into OOP, and it seems like "Maintainability" is usually the primary reason the OOP experts give for implementing their chosen programming paradigm. However, it seems to me that in ColdFusion, OOP really just makes developing things more complicated, and sometimes adds unnecessary processing overhead. Also (as someone that regularly has to hire CF developers), it seems that the majority of CF Developers out there are more comfortable developing in a procedural fashion, and CF developers who actually are comfortable with OOP are almost always comfortable working with well organized procedural code as well. Threfore, it is easier to maintain a staff of people to maintain a CF application if it is procedural.

That is why, while I have implemented some OO-ish principles to my programming style, I continue to program procedurally, and I have not put forth a lot of effort in training my mind on how to turn everything I program into in an object.

I think if you do a good job of identifying the parts of the application that can be modularized with a generic CFC, or Custom Tag, or UDF, and you do a good job of organizing your code (so it doesn't turn in to a pile of spaghetti with 1000 .cfm files all in one folder), then maintainability is not an issue that should decide weather your do OO or Procedural.

The main reason I can see for choosing one programming paradigm over the other really boils down to simple personal preference.

@Shawn,

I definitely do need to rethink the way I envision an application. My concern with display-related logic is that it ties the model a bit too tightly to a particular view.

It almost sounds to me like we're discussing two different issues here. Ben and Scott seem to be thinking about OOP as an all-or-nothing thing, and they seem to be asking if they should make *everything* in an application an object.

Many of the people responding, I don't think are answering the question - or even really hearing the question. The question that people are hearing you ask is, "should I use any objects at all ever?" and so of course, they're answering that yes, you should, quite obviously you should.

That's my take on this discussion. Except for Peter, it looks like people are answering a question you didn't ask.

Here's my answer: should you make everything an object all the time without exception? I say no. But on the other hand, you should be intimately familiar with the power of OOP so that you are able to use the best tool for the job at hand. Many of the applications I write are *not* entirely OO, but in almost everything I write, I find that some part of it is best implemented as an object.

A quick example: I'm doing some integration with the google calendar. I get an authorization token from google and then use that token on subsequent reads and writes. This can be implemented procedurally. Procedure A gets an auth token, which the calling program stores in a global variable and passes to proc B and C, which read and write calendar entries.

But if you have that OO tool in your bag, you see this setup as tedious and needlessly complex. Ten years from now when I have to maintain this code, I don't want to have to think about auth tokens. I shouldn't have to remember rules like how long the token is valid.

An OO solution encapsulates the token and the read/write methods, and ten years from now when I have to make a change that tedious detail is hidden from me. Also, if I need to work with two calendars simultaneously, I don't have to juggle auth tokens in global variables. I simply instantiate two objects, and they handle themselves. Finally, when I start working with resource calendars, I'll find that the code is almost exactly the same - but different enough that I would need new procedures if I had implemented it that way - with OO, I can use inheritance and have the resource class make use of the calendar class' auth method.

The bottom line is, this is an incredibly power tool. You don't have to use it all the time, but you should be ready to use it when appropriate.

@Christopher,

I think that is well said and very accurate.

@Chirsopher,

As I mentioned in my last post I use some "OO-ish" principles in my programming style, and I have developed CFCs to create "objects" for certain parts of applications when I think they are appropriate similar to your google api example, and instantiate the object into a memory scope to maintain it's state and use it's properties and methods to handle events in my application. However, I have always been under the impression that there is a difference between writing objects that can be used by a procedural application and writing applications that are truly "OO".

Are you saying if I use a few objects in a generally procedural application, does that make it Object Oriented? Or is there perhaps a magical ratio of objects to procedures in an application that must be attained before I can call an application OO? =)

Nice discussion guys. This kind of topic would be a great round table discussion, recorded for podcast oh course.

By the way I do lean towards the OO side. Even at times when I seem to be creating more code than I would normally, in the end it comes together better and I do think it makes a more maintainable application. Overall I can't say that I think that I have ever made an application less maintainable by making to OO.

This may not be a good comparison but our admin side of one main portal application is its own entirely different site written using a different framework but we do re-use objects between them when we can. It usually works better if you know about the re-use up front. Some have xml (coldSpring) config files that load them up differently. Yes there are times when the needs are so specific we write completely different cfc's for the same objects.

@Jonny - you said 'OOP Does make alot of sense to use if you are coming from the systems analysis and design approach rather than just sit down and start coding.'

I have to disagree.

Using an Agile approach you may start off with a unit test and an empty cfc, write a few lines of test code then make the test pass with a few lines of code in the cfc.

You may well have a vague grand design sketched out on a whiteboard and have a good use case in front of you for the focused task at hand but I think OO works better using an Agile 'bottom-up' approach rather than a clasic 'top-down' approach.

I have always found my top-down design is completely different by the time I finish the project so tend to not spend as much time on it these days and just develop things, bit by bit

After taking a job that deals with coldfusion, the first thing I did was look into OOP. I have to admit, coming from a PHP and C# background, Coldfusion OOP seems pretty pointless as well. It's ugly and doesnt even seem to be OOP at all.

Just my two cents.

@ Ben

After a few additional years with OOP and being more seasoned with it.. how are you feeling about it now?

As I have been learning then ins and outs of CFML or jQuery everything has been like wow! I cant wait to use this! But with OOP, which I have just begun getting into, I keep questioning its utility in typical web development.

One of the truly profound benefits of designing and implementing an object-oriented system (whether in CF or other languages) is the intimate knowledge you gain of the business and domain you're coding to.

I was involved in a 3 year project involving the consolidation of numerous sites that offered conference registration, publication subscription, lecture viewing, and case study interaction, all of which we broke out into 'activities', which has common functions to all (ie. registerFor(), confirmRegistration(), display(), etc), but that got very specific once a user had drilled into them.

We built the site using FB5.5 (no-xml) and the mvc layout made for a very clear and consistent understanding of how the many parts of the site came together--especially helpful for members of the team not fluent in CF.

Once the objects were in and interacting, I gained much more insight into the business rules that needed to be enforced. It was one thing to read a set of requirements and understand the general idea of the objects...but it was another thing entirely to have them implemented, seeing how they differed in some places, and remained the same in others. I felt like I came out of the project with an intimate knowledge of the domain having never worked in that industry before (oncology, training).

I'd also like to add that it makes for reading/understanding/maintenance of other people's work an order of magnitude easier.

I moved to a new position recently and had the luxury of inheriting someone's ColdBox app, which was extraordinarily relieving. It read like a book. I very quickly understood all of the discrete objects in the system, how they interacted, what their role was, and how the system ran.

I didn't need documentation (is there ever any?) to learn how the system was built and functioned--it made sense from the start. The last time I experienced that...never.

In comparison, I've seen and inherited many a monolithic mess of spaghetti code with includes of includes of includes of includes, with no rhyme or reason, no consistency--and to me they are not only difficult as HELL to read/understand/maintain--but they don't demonstrate to me the developer even had that understanding of the domain...that every change that requested was just 'one hack on top of another' to make things work.

Who wants to be a professional software developer with that mindset?

@Shawn

Would love to just once take on an existing site where I didn't have to stumble down "Include Trail". I once had the pleasure of rewriting a site that had up to 11 deep includes in about 30 different directories with no rational for why they were there or even why the code was in an include. It was frustrating, but at the same time it was a invaluable lesson that inspired me to become a better developer.

In the past, I transiently invoked methods which has really made a difference, for me at least, in terms of a cleaner, more understandable and up-datable application.

Maybe OOP will be something I can appreciate much more once I really start implementing it on some projects.

@Chris,

Object Oriented Programming (OOP) is still something that I am constantly struggling with. And it doesn't matter which language I am in - ColdFusion or JavaScript. While I have a gut instinct that OOP is really awesome, I find it hard to figure out the right way to do things. I think a lot of this comes back to me simply not having enough experience and not taking enough risks on projects.

I definitely love objects, I love classes, I love encapsulation, I love the grouping of functionality.

In JavaScript, I've been starting to look at Modular code with things like LABjs and RequireJS. I am hoping that a dive into these types of organization will help me continue to chip away at the fog-of-war that covers my ongoing battlefield.

To sum up: I love objects and I try to leverage them to create cohesive, losely coupled code... but, I don't think of myself as a "good" OOP programmer by any means. I'm still a loooong way off on how to fit all these objects together and where different responsibilities should go.

@Shawn,

I'll agree with you on that one, whole heartedly. Having nicely packaged objects does make wrapping your head around logic a lot easier. When objects have high focus and low coupling, it's much easier to see how things work.

@Chris, @Shawn,

I have to say that I have had good and bad experiences following someone else' code with both Procedural and OOP. With procedural, following includes *can* be easy. With OOP, following method calls *can* be easy. However, both can also make it really hard. Especially when you get into OO systems where there's all kinds of configuration deeply "nested" methods calls. Both approaches can be done poorly.

Not long ago, I interviewed for a job with a company that was one of those 'contracting outfits'...that is, you go to the company because you are without work, and they have a collection of jobs from different companies that they send you on interviews for. It is both a benefit, and can be something of a con that they have extensive tools to help you along, including some level of training (the reason this is a con is because you can do great on interviews and actually get a job, but sometimes you are only loosely qualified for those jobs, and working can be a struggle at that point).

Anyway, one of the training pieces I had for a job was for ColdFusion. The people they were sending me to, the company, was insistent upon hiring an "Object Oriented ColdFusion Developer". During the training for this specific job, they stated that ColdFusion, that is CFML, was not written in an object-oriented way or in a way that was conducive to object-oriented programming. I know that what I am saying may cause some people to become insensed against it, but I am only trying to share an experience and hopefully some insight into this question...the question of "Object Oriented Programming And ColdFusion - What's The Point?"

And to back up the fact that maybe I have enough knowledge to comment, it's not ColdFusion that I would have struggled with. I have had many ColdFusion jobs, training in school, and am certified in ColdFusion 8. (93% on my exam). I know a lot of people don't puch much stock into those exams or certifications, but I still think the percentage range I fell into says I know a little bit at least about the subject...it'd be hard to 'get lucky' and get that high of a score. I was hired specifically for my last job for my ColdFusion experience, and was responsible for training my department to use ColdFusion. I'm not the strongest or the best ColdFusion developer, but I do have a bit of experience with it.

Anyway, back to my original point, the said that CFML was not an object-oriented language, or that it was originally not designed that way. Of course, the purpose of CFC's, I guess, was to bring it more into the object-oriented forefront, but what I have found at various jobs is that different people mean different things when they say "object oriented".

I know we don't want to get into an argument of semantics here, but I think what people mean when they say certain things is a pretty important thing to understand in any discussion. The company that wanted me to understand ColdFusion from an "object-oriented standpoint" didn't have any applications that I could see that were any more 'object-oriented' than my big toe. I have had many companies that I worked for that would ask me if I had an object oriented methodology behind my programming, and then when I would work for them, I would struggle to see any kind of an object oriented set up.

I even worked for a company that had what I thought was a great MVC set-up, but I didn't really see anything that was representative of the things I learned about in school when I took c++ and Java and learned about how Object Oriented Programming worked using those languages.

I'm not picking on ColdFusion...one of the companies that I worked for which asked about the Object Oriented thing developed using php, and I didn't really see too much object orientation going on there either.

I agree totally with @Ben, in response to @Chris and @Shawn, I have worked for companies before that did have a very Object Oriented setup, and their code wasn't always easy to follow...I have seen it implemented in ways which wasn't really terrible easy to follow. I think the implementation is more important when it comes to being able to go into someone else's code and make updates rather than a specific way it is coded...object oriented or otherwise.

I believe it was @Peter who brought up a great example of something that would do well with an object oriented set up, and also the aspect of developing different applications for different companies. There are companies that work on specific websites, but there are also companies that develop different applications, and then sell them to other companies, for example, for inclusion on their websites. I was going to work with a company that was going to do a shopping cart like that. Some other examples include calendars, testing modules, a help desk application, etc. But having the applications developed using an object oriented approach does help with developing an application that can be used by different companies. One of the software applications we bought at one company was a helpdesk application, and it was one of those that was developed by one of those companies that just develops applications in general and then sells them to companies like the one I was working for. Applications like that do well to be developed using an object oriented approach. Sometimes, though, when you are working for a company, and you have one site, it can be quite a challenge to write the whole site using the object oriented approach. Also, as was mentioned, when you start working for a company, and they have a whole site and/or application or set of applications developed, it's hard to go and re-write everything if the original approach was procedural, and it can also be difficult to sneak in object oriented stuff when the whole site/application/whatever was already set up a different way.

I have no preference either way, really. Generally, I just like being able to write code for stuff and it works. I have, probably fortunately and unfortunately, not had much say over the way stuff was developed for most companies where I have worked, for the most part, so I kind of just have to make it work in whatever way it works, usually. So it might be different if I had an actual say, but I don't. If I did, I might could choose either procedural, object oriented, a hybrid, or some other approach, but I just don't have that level of authority or control.

Post A Comment

Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.

Please review the following issues:

Author Name:
Author Email:
Author Website:
Comment:	Supported HTML tags for formatting: <strong>bold</strong>   <em>italic</em>   <code>code</code>
	Remember my information
	Subscribe to comments
	Send me a copy of this comment