Tuesday, January 18, 2005

Overemphasis on OO and Modularity

As I have seen more and more in our industry, the call for modularity has surpassed the original intent. In far past, too many applications were to huge, hard to read, and were using similar code, that could have been re-used, and save some time.

There is a lot of common sense involved with code re-usability:

1. Making sure we don't waste time in writing the same codee
2. Making sure that long applications are broken up into more readable applications

But I feel we've finally gone way over the edge, by these simple but needed changes in how we code, way too far into OO-land.

I feel there are times when OO can be useful, but not when you are coding coldfusion applications 99% of the time.

Coldfusion is a very powerful language for creating web applications, but is most know for it's speed of concept to results, Rapid Application Development. So that means there has to be a logical path from a to b, and that's the end of the application.

We are getting invested into things that may be interesting but are inhibiting our speed of delivery.

Simply said, Object Orientation, requires thinking in non-logical ways, that make it hard to work with and hard to communicate about.

What happened to plain old english logic?

I felt this when I had taken my first java class, I could figure out how eventually to do whatever i wanted, but no one would talk in a logical manner.

If I wanted to X, what things do I need to do X. A Simple Question, but because of object orientation, there was no way to logically describe the problem and solution.

Object Orientaton sounds really fascinating, but experiences like really a waste of time.

I have no problem finding new ways to both improve the quality of the code, and improve the speed of delivery, but I have never believed OO was the path to do that.

I am sure there can be a more logical approach to working with Java, without having to use OO language.

I mean, I've worked in javascript, which has methods and objects, but I've had no problem doing what I needed to get done, because it's coders use logic.

This goes along with CFC as well. Which were originally meant to be used for web services only, which is fine. But now everyone wants to use them for non-webservice related projects?

Doesn't anyone have a clue how to code for scalability? It's interesting and new ways of doing things, but they are not always the best ways.

We have to use our common sense.

So what things can we do to improve coding quality?

Start with the basics:

1. Commenting
2. Code Readability including good indenting
3. Use a Project Management Process to avoid coding mistakes
4. Documentation
5. Learning from Mistakes

My Motto - "Doing it the right way the first time"

Understand how to code for best performance, and code as if each application will be serving millions of users consistantly.

Understand how to write the best sql statements to get the data you want, but write it for performance. Use stored procedures, dts packages, all the functionality to move cf scheduled events into the database, so the web server can just focus on serving pages.

There are so many ways that we fail every day to just do the core, and all of us are into whatever the current fad is.

If there are other ways to be better coders, I am sure eager to know. I do not assume I know it all. But I do try to know what works, and what is a waste of time.

Coldfusion is about speedily creating great applicationss, so are you?

4 comments:

  1. I honestly hope people aren't getting behind OO in CFMX because its the latest "FAD".

    If thats the case then agree.

    I personally got fully into OO In CFMX for many reasons, mainly for the fact that i could start consolidating my code into portions of logic. It stemmed mainly from common websites all using the same CFINCLUDE file but each implementation was different in some form or way.

    CFC's in all honesty were not made specifically for webservices - i'm not sure where you read that - they were to actually entice the "enterprise" tag developers to the product that and give developers a bit more grunt in the way they can develop.

    Its a managed language and it comes with limitations and if you wish to think in procedure - then by all means do it, not one person will flag you for it that are worth their salt in this industry.

    Blackstones got some more goodies in the basket in regards to events and threading, now to the average joe schmoe who makes basic websites - this will seem to be an overkill in complexity.

    For persons like myself who work more on applications that are used in so many ways (shape and form) - ontop of that make use of a mulititude of datalayer types (Oracle, SQL, XML, SOAP, LDAP etc) i kind of need to start abstracting a lot of this crap into portions of code that can be agile enough to leveridge at different contexts.

    The simplicty of providing an API via CFMX is enough to simply shoot down all the folk who disbelive in CFMX's OO capabilities.

    CFMX by nature is as you put it RAD (buzzword000) but its a lot quicker and many ways easier to get things done in this good ol CF instead of others like J2EE or .NET C# (ASPX is orrible).

    I've used all of the above and i'm learning C# more so, so i'm all for OO in all languages as god knows re-use is more clearer in objects then it is in TAG farms.

    Scaleing in OO is the ultimate prize, if you can shelt the innerds of how logic is stored in cache, you then have the power to adjust freely and more with more agility then you typically would in a simple procedure endurance test (CFMODULE can be argued as just as effective as CFC but its more verbose).

    I'm sorry but i disagree with some your comment of "non-logic" ways..

    I think like "Management" in that i treat scenarios like i would in business..

    an example:

    I am a manager, i need to hire an employee but a certain type of employee. I need to do this in a cheap way so that i get the full get go out of my employee(s) but if the time comes where i need more, i want clones of my harvested employees.. point is its all based on how you attack the problem - sometimes it helps to think about in a non-logical way in order to solve it as you tend to have blinders on.

    having said all that (closing the comment up) if it takes you 115 lines of code to write "Hello World" then you seriously need to consider what you are achieving by doing so.

    there is re-use and then their is hitting an anthill with a case of dynamite.

    ReplyDelete
  2. Wow, provacative post.

    My experiences have been quite different from yours. I really fail to see OOP as a fad. All of the major languages have moved in that direction.

    While the logic is definitely different than procedural approaches, I don't think there is a LACK of logic. I find that OO logic actually tends to fit business problems better. It lets you manipulate a model of your project domain as if it were real.

    Regarding your steps to improve code quality, 3 of the 5 have built in support with CFCs.

    Commenting and documentation are supported by the hint and displayname attributes (and in some cases your own custom attributes using metadata).

    Code readability is greatly improved by moving distinct processes out of the flow of your pages.

    For example, to check the validity of a credit card number you could have something like this:

    custCreditCard.checkMod10();

    You can easily use this as the test in a conditional statement if your funtion returns a boolean value.

    You might have 50 lines of code to wade through to do the check inline. I don's see how that could be easier to read.

    ReplyDelete
  3. OOP isn't about non-logic. OOP isn't about procedure. And purposed code isn't reusable.

    Sorry, Craig. We can debate this at my next CFUG preso in February... but I couldn't disagree more. Having recently made the transition from PP to OOP, I can only say with conviction: It's a subtle, but essential shift that's the only vehicle to enterprise-class applications.

    "Applications" being the key word. Understanding the transformation of CF from a tool to quickly create dynamic WEBSITES to a tool that can do that as well as create full-steam-ahead enterprise-class web APPLICATIONS is where we as a community go wrong. But a database-enabled website is not a web application, and if we're going to develop more and more applications we need to adopt standards and practices that have proved, repeatedly, to empower applications and the people that create them.

    We can, and should, still use the old methods for situations where they're appropriate. Absolutely no argument there. For a simple, straightforward site that displays data on pseudo-static pages and with limited traffic I'm perfectly content to consider the old-school CF development style. However, after having seen commercial site after commercial site start in CF (probably because it was so strongly touted as a RAD tool, and comparitively inexpensive) and almost as quickly show up converted to ASP, Java, even Perl or PHP, I am tired of watching CF get a black eye every time I turn around. It's design and architecture that cause these sites to fail, not the language, and yet CF is often blamed for these failures. And now that the underpinnings of everything we do are Java-based, and we can apply the full power of Java's core libraries to our development, if we simply implement the most powerful new tools at our disposal we can engage our profession in greater and greater projects.

    I suppose what it boils down to is a shift away from something I read by Ben Forta. I can't recall the source, but Ben expressed the idea that CFers aren't programmers... they're developers. At the time, he was right. Now, it's much less true. But the beauty of CF is the fact that those who choose to can remain developers... and those who choose to evolve beyond that and begin to forge ahead in the "New Context" can do that too. We can now, with a fair degree of ease, become programmers.

    I'm not going to, nor would I at any point in the foreseeable future, say that PP no longer has a place, nor that the only good site is one built on FuseBox or MachII or any other particular framework. But, to say that OO and CF should never be mixed, or to assert that we shouldn't apply the vast amount of information available from millions of man-hours of reasearch into enterprise software development is equally as short sighted.

    So, Craig, while I absolutely respect your skills in CF and the amount of knowledge and skill you have in applying CF to solutions, I utterly diagree with your comments and would even go so far as to say I think it's a fairly irresponsible position. At the very least it's completely unfair and one-sided. Then again, we get to express the counterpoint in the comments here. Perhaps it's a challenge, to me (as the new OOP evangelist in the Minneapolis CFUG), to prove the point, and make OO more logical and less confusing. I'll do my best, I promise.

    And I never did get that CFC/cfinclude issue to work... thanks for the help, though. Alas, you probably don't even remember... but I did, and still do, appreciate your drive to support and enhance the CF community, even if we disagree on something.

    Regardz,
    Jared Rypka-Hauer
    cf.objective@gmail.com - cf.Objective 2006!
    cmg.llc@gmail.com - Continuum Media Group, LLC
    http://www.web-relevant.com

    ReplyDelete
  4. Anonymous5:05 PM

    As far as reusable code, the best technique I've found is regular old-fashioned functions. The trick is to use named parameters which are optional, or something that simulates them (such as associative arrays of options). Example: pageHeader("title", closeButton=off, ad=on, flashyStuff=off, etc...)

    This gives a buffet/smorgy of relatively independent options, while OO tends to force hierarchical noun taxonomies on you, but the real world does not change in a tree-shape for the most part. (And OO is really messy when using something more powerful than sub-type trees.)

    Further, making the Ultimate Generic Thing is a futile excercise. Such a contraption would merely become a bloated feature pack-rat over time. Thus, just copy a version from a similar app and modify it for the particular project. Over time you'll learn how to improve your little toolkits to make them more adaptable. Direct reuse across applications is a dead ideal. copy-reuse across apps is a decent compromise because it does not tightly bind multiple apps together.

    I haven't seen OO help reuse in a demonstratable way, at least not better than functions with named parameters. I want to see a realistic example of OO being better for business apps; not shapes, animals, and device drivers. Many seasoned OOP proponents do not even claim "reuse" as the main selling point anymore. (Although they are wishy washy or inconsistent about the real selling point of OO.)

    ReplyDelete