Hal Helms Real-World Object Oriented Programming (OOP) February Training And Discount Code

I am assuming that the price does not include accommodations...

Once I graduate from school I am going to go to one of those classes. It seems like I will expand my understanding exponentially.

OMG this sounds amazing! I wish I didn't live in the UK and I wish there was any way my boss would pay for this.

The heating's broken in our office and it's currently -5oC, FREEEEEEEZING!

I'm attending a private class at the moment with Hal. It definitely costs more than the Feb class coming, but I can tell you that it's worth every penny!!!

We've spent 10 hours together so far and it's probably the best 10 hours of learning I've spent when it comes to programming. If you can attend this class, I would strongly urge anyone to go. Hal has a great way of breaking it down and getting the message across.

Before taking the class, I used to start working my projects backwards, from the db and than to code, this is wrong as I found out. There is no reason why you can't build an entire functioning app that doesn't even have a database created for it. I know I resisted Hal on some of his teaching the first few hours because I was more comfortable from the database more than anything, but now I'm on the right track.

TAKE THE DAMN CLASS AND BECOME A BETTER PROGRAMMER!

I said it was wrong to start from the db and go backwards, I should have said that if you're building an OO app, it's wrong. I want to clarify this before it's misunderstood.

Hatem Jaber:
Could you please explaine why it wrong to start from DB?

Let me jump in on the "why it's wrong to start with the DB"...

Databases provide a wonderful way to store data. With something like SQL, they make working with data relatively easy. Codd's Relational Model is a work of great intellectual power.

BUT databases were never meant to provide the architecture for an application -- specifically an OO app. This is the biggest mistake beginning OO programmers make, and I'm sad to say, many never progress beyond this point. (This is why I'm so fundamentally opposed to "ORMs" that base objects on the database...but don't get me started...)

The foundation of an OO application is a domain model. This is a software simulation of the domain under study. It has NOTHING to do with databases. The hard part of OO design is getting the domain model right. This is where hard-won knowledge of design patterns is so useful.

Domain models are expressed in UML diagrams. Next, we provide a service layer as a way of accessing the domain model. If using databases is the most common mistake made, misuse of services is a close second. Commonly, a "service" is really just procedural code stuffed inside a class. Understanding how to build a good service layer is vital.

Controllers interpret user intentions and call services (and sometimes model components directly).

Finally, we need to be able to store the state of domain models. Finally, we come to the point of creating and using a database. The database's structure depends on the logic of the relational calculus; the application's structure depends on the logic of domain modeling. The two are sometimes similar, but may often diverge widely.

Hattem has it just right: if you want to build a procedural app, you may well want to start with your database. But starting OO apps with the database virtually ensures that your application will be "OO" in name only; you'll get almost no benefits (and you'll take on the drawbacks) of an OO system.

Bottom line: RESIST THE URGE to think about data. Think about objects and their behavior. Form the API of the application and, only later, concern yourself with how object data should be stored.

Thanks for your reply.

Yes, DB do not support inheritance, polymorphism, encapsulation etc what OOP does.

BUT DB not just can store data, it also can store/retrieve the data based on some logic. You can also build an object in DB and use that as business logic it can be functions, store procedures etc......

Im not trying to say what is wrong what is write, I just think its a metter of choice/requirements/application size etc ( 2 + 3 or 3 + 2 is always 5 ) .

Thanks again for your reply.

For more information on the issue of domain models vs. relational databases, along with one of the main problems that ORMs are attempting to solve (called the "object-relational impedance mismatch"), have a look at:

http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

@Misha,

Hal explained it better than I could or would have, i'm still learning and taking instruction at this point. I want to point out that you are absolutely right, you can do much more with the database than store data. SP's, Custom Functions, Triggers, etc... if the app calls for it in that data layer, do it. According to Hal's teaching, which took a few days to sink in, the last thing we want to think about in an OO app is the data layer. Matter of fact, in some situations, we may have a DBA who will create the DB and all we have to do is write the code to pass back and forth data. For all we know everything from the DB maybe encapsulated in SP's, it doesn't concern us with the code for the app.

@Brandon,

You will definitely walk away happy, I can testify to that. Matter of fact, as much as I love programming, this really made me love it even more and made it much funner.

Hal/Ben: This reverse-data approach seems super interesting to me. But, as a Web developer first (and student and lover of pure OO second), it seems to me like Web apps and even RIAs legitimately ARE and should be data-centric.

The grand majority of what I do on the internet is search, create, and manipulate data. The Web to me, is little more than a giant, accessible database (with the exception of rich media experiences, which I feel are best served by the Flash Platform).

For Web apps, I'm not expecting incredible animation or interaction or environment simulation. When I use Mint.com, it's just an interface to view related data and manage it. When I use Facebook, it's a way to interweave my data with other people's similar data. As an advanced ColdFusion developer, I savor and cherish the application development cycle/pattern I use like a fine screenplay every time.

I start, unanimously first, with a clear, crisp, arguably perfect database design that I implement live, without any diagramming and too much blind brainstorming, in a database IDE. This, to me, seems like the most vital, influential, and critical component of any Web application: the database. Every other aspect of the application seems to be naturally, intuitively dictated by this data design, layer upon layer like a tightly knit rubber band ball built on a glass marble.

Next, I very fluidly pour the data design's service layer over it like the liquid metal over a product's blueprint molding, or pin it on like an electrical outlet over its underlying wires. Exposing what needs to be, shielding what doesn't. Everything is dictated and confined by the data's shape and form.

Lastly, I create the interface. The visual, interactive elements that users will address and explore. Once this, the "interaction model" is finished, I plug in some standardized, reusable elements (like a collection of security layers) like an all-weather coating and test/deploy.

This formula, in my few years of experience, seems to be the quickest, most maintainable, cleanest process for rapidly architecting quality Web applications, because of the nature and predictability OF Web applications.

My question then is, is this "pure" OO approach that's distilled in the class more applicable to full, complex software concepts and projects, or do you feel like it's equally applicable to mainstream ColdFusion developers that work on fewer-developer (small team) projects and feel like they're pretty satisfied/infatuated with their current approaches?

Totally curious/intrigued. Thanks.

@David, when I first went to Hal I was thinking the same way you described in your posts. I would design the best possible DB that I could imagine, make sure to account for all the possiblities of the fields and so forth, and than move on to the other things that you mentioned. But Hal sold me on the idea of doing it like this, and Hal correct me if i'm wrong:

1) most obviously would be to get your head wrapped around the situation at hand by interviewing and consulting with the client. In most cases they haven't given it full thought from all aspects and this is where we need to be to hold the clients hand while we walk through the scenarios.
2) pre-prototype - build some mocks of the screens that we need and the various actions on each screen.
3) prototype - get some html going on this stage
4) mark up our prototype - go through each action on each page, what gets clicked, is the form submitted here, how do we get to this screen, etc.... write out the methods for each action, for example: getUsers(accountid:uuid):json and so forth for each action on that mockup
5) uml - create our classes, methods, etc... at this point we don't need to know every property, but we will soon enough

At this point the client has seen the screens, they've thought thoroughly and you've walked them through enough to possibly see anything else that they could be missing.

6) code - start writing our code based on our uml's, get the app functioning without a db
7) once it's approved, figure out how we handle the data

I'm still taking class with Hal, so this is what i gathered so far, we're still working on the project.

We've run into the situation where the client starts telling you more about the app as you have progressed in the development and than all of a sudden you have to tweak the DB and make changes. In some cases you end up reconstructing the DB or at least some of the tables. Going with this approach, the DB does what it's good for which is persisting data and returning it when needed.

I hope I didn't fudge it up, but if I did, i'm sure Hal will chime in and correct.

Just my two cents / wooden nickel.

I believe that for as long as I remember database guys have been revered like they can't do any wrong. Well here I am in the 13th year of programming and have come to understand that databases are not the final point in any application. I have seen good and bad databases but have come to understand that an application can be built without a database. Would I recommend it no by any means just wanted to remind you of that the next time some DB guy dismisses you like just another programmer.

That being said it doesn't matter how well your DB is created or how perfect the triggers or stored procedures are, or how the OO design of your app looks so pretty on your wall written in perfect UML. If the client does not get what they signed up for and there is no buy-in you will have wasted everyone's time. Your app should NOT start in the database or in the application code. Where it should start is in Requirements gathering, Screen mock ups that a client can follow their processes from start to finish and approve. Keep in mind that if you are on this end of the application then you dont know those processes well enough otherwise you would have a business too. Oh and BTW let the managers sponsoring the project that you want a brainstorming meeting with the line level users. Managers always feel like they know the processes better but here is a surprise they don't! Once all this is completed (yes I know that I simplified it) that is when you can start the process of making the decisions that will make your project successful, that is what architecting is all about. But keep in mind that APP guys (Java, CF, PHP, C++, ASP, …) will try and pull you to do it all in the app and DB guys (RDBMS) will pull out their DB cards (as if they were FBI badges)while holding their chin up and telling you that the DB is the most important part but you must resist and think about how to best provide a solution for the client. In the end the client could care less about the HOW they are looking at what they ordered and what they are paying for it. There is nothing worse that going thru the drive-thru and ordering the double meat and cheese only to get home and realizing you have a liver sandwich with sauerkraut.

Yes there will be times when you will have to steer the client to the solution but you should never steer them in that direction based on the APP guys or the DB guys changing how the client does their process. Oh I don't want to forget the web designers they too will put in their 2 cents and you should listen but listen to your clients needs before you accommodate the people working on the application.