Page 1 of 2

understanding OOP, but app design is killing me...

Posted: Thu Oct 12, 2006 5:34 pm
by Luke
I have finally gotten to the point that (for the most part) I understand OOP and I can usually follow along in discussions about OOP concepts, design, good practice, etc. but so far I've built two applications since my "click" of understanding OOP, and I'm just still not able to plan and execute applications very well... it takes me FOREVER. and also, just design in general kills me. I just got a copy of VISIO, and when I go to lay out an outline of an application, I just sort of draw a blank. Any suggested reading... books, articles, etc that can help me? I'm starting to hate programming because I can never finish a product... even if I finish one, I'm never satisfied with it because usually I'll start off with a very clean application, but by the time I'm done it turns out to be a heap of hacked crap. It just seems that I'll never be able to take a project from an idea to a reality. :(

Posted: Thu Oct 12, 2006 6:41 pm
by Luke
Alright... here's a diagram... am I missing anything? I've never really planned too much ahead, but I'd like to start doing things right... please take a look and let me know what else I should take into consideration...

http://upstatecaliforniaadventures.com/Map.gif

Posted: Thu Oct 12, 2006 7:18 pm
by RobertGonzalez
The logic flow to you? Now look at it from an implementors/users standpoint. Would it make sense to them? I only ask that because there have been numerous apps that I have seen that, I know the original developer knew it was absolutely stunning when it was designed, but did not really follow a decent logical flow.

Without knowing a whole lot about the app or what it does, I am not really able to look at with a keen enough understanding. But that is just me. I'd bet arborint or ambush commander could tell you in a matter of seconds if there were things missing.

Object Oriented Painting or My advice to TheNinjaSpaceGoat

Posted: Thu Oct 12, 2006 9:11 pm
by neophyte
I'm considering writing a book entitled "Object Oriented Painting: A painters guide to coding" :)

Okay I'm nutzzzz!!!

Not really the principles behind designing a masterful painting and designing a great application are very similar when you get down to it. I'm not saying that I know everything about designing an application I'm still learning. But your a designer so I figure you should be able to relate.

With a painting you do thumbnails -> ie flow charts. You might need to several and even do preliminary studies before you jump in.

Now you've got your composition but your still not 100% sure how it will all map out. So you start broad: assembling libraries (adodb, smarty, frameworks) and developing code that has little or no dependencies. Once you've got the background laid down you can start working back to front with generalities. No specifics yet. You may have to go back and replan or adjust.

Along the way you may have to do some case studies. Working out class relationships with classes with bare functionality to no functionality. And just like a painting you can do these studies on a scrap piece of paper or outside of your work.

If you've done this right the rest comes easy? Right? Well that depends on how experienced you are. After all you wouldn't expect to paint a Rembrandt after 6 months of study or even 1 year. So start small and work up.

Well that's my half baked advice.... Just remember craft counts.

And just incase you were wondering, NO I haven't been smoking anything today. :D

Posted: Thu Oct 12, 2006 10:40 pm
by Christopher
I personally don't use diagrams like that because they don't really give me the information that is not obvious about the design. They are good for the basic structure though. You could also try using Roles, Responsibilities, and Collaborations Cards

Posted: Fri Oct 13, 2006 1:02 am
by Todd_Z
To address the issue of having hacked up crap at the end of a long project, you should try a very strict framwork. By using a strict framework [that you wrote yourself], you will be forced to use certain standards.

Here is an example of what to do:

Every "action" which would change the database in any way, has to be called on the top level, from a database. So if an action is called, for example delete-38, it will check the database for whether the "delete" action exists in correlation to the current page, and if so, execute the method, if not, ignore the request. This is important for two reasons, it filters a part of the url, for example my urls look like /foo/bar/page.html~action-id, secondly, it forces the function called action_delete ( $id ) to have the respective code.

Posted: Fri Oct 13, 2006 5:54 am
by Ree
You should regularly refactor code as you progress. After you advance some, look through what you have coded and look for things that could be improved (dependencies, responsibilities, interface). This way you will end up with a better final product.

Posted: Fri Oct 13, 2006 8:40 am
by neophyte
arborint wrote:I personally don't use diagrams like that because they don't really give me the information that is not obvious about the design. They are good for the basic structure though. You could also try using Roles, Responsibilities, and Collaborations Cards
Thanks for the book tip, aborint.

Posted: Fri Oct 13, 2006 9:11 am
by MrPotatoes
like with anything programming it takes time and practice.

i had friends in school that had a hard time with classes and took them a year to completely understand. if you think of it as an encapsulation device (like a struct) you're better off. then in time you'll stop using it like structs and more as a design methodology

*mad props*

[edit] which is funny tho. i have some friends that couldn't grasp for loops and with cold fusion they think they are a better programmer than me. man, i really hate to break it to old "apprentices" or whatever you call it.

they'll be better when i die. HAHAHAHAHAHAHAHAHAHAHAHAHA!!!!

*poo nuts*

Posted: Sat Oct 14, 2006 5:09 pm
by Yossarian
@Ninja.

How depressingly brutal, stark and honest a post you made there.

They don't explain that in the OOP books do they?

I would go along with the poster who said make a Framework, actually many pieces fell into place when I just used a Framework - I don't feel skilled enough to make my own... Yet using a framework has kind of realeased me focus on set parts, like trying different domain models, use their Active Record or make my own? Try making data mapper.. Then wander off and play with views and view helpers, start fiddling and twiddling, try making an observer to report errors... You have to play.

It did help me to get some pretty nifty code out of the door - as I was learning.

The other major thing i did that made some more pieces fall into place is to read Fowlers POEAA.

Posted: Sat Oct 14, 2006 7:05 pm
by alex.barylski
Planning is alot of work. Something most developer don't do because it's not really what a software developer does. You need experience developing software before you can plan a software project, but the two are quite different.

It's awesome your looking to form a solid application document plan, but if your working on a project solely for your own purpose, it might be overkill?

If not, here is some advice.

Think abstract. Like Everah suggested, your flow chart is to implementation specific. The slightest code change and your document is now garbage, or atleast requires re-designing. Abstractions *anything* don't break as easily. Regardless of whether it's high level abstraction in a project planning document or low-level in the case of a ABC.

The next step, is abstraction decomposition. Make your abstractions less abstract, but not so concrete that implementation changes cause you to redo your documents. The book on XP i'm reading right now really made me realize where my mistakes were. I planned to much (I love to plan, maybe more than writting code) and when implementation changed my documents needed changed. But after spending an hour or so making a document look good, the last thing you want to do is redo it, so you get into the habit of "I'll change it later" syndrome. Something I did so much my documents rarely stayed in synch with my code base.

OOD and application or system design are slightly different. OOD typically revolves around problem solving in OO perspective. You take the problem on head first and generally wack out a single monolithic class. That class must then be analyzed and likely decomposed. I read in an excellent C++ book by Bruce Eckel??? If your interface doesn't fit on a sticky pad (sticky notes or whatever their called) your class API is to large (general rule of thumb not hardened guideline).

Personally, I have experienced almost any object (after some thought) could be further decomposed. It's problem solving from an OO perspective. Like any problem, you start big and break it down into smaller and smaller problems until a atmoic state has been reached.

This is where TDD comes in really handy, at least the principles, not the practice. If you write your tests first, you don't waste any time writing code, only later to discover your object could be further broken into 2 or more objects. Thus forcing you to refactor - not a bad thing, but in this case can usually be avoided with proper planning, at least somewhat.

Another thing which I really appreciate about XP, is it's stance on staying Agile and not locking onto any single method or approach. Keep your SDLC (software development life cycle) changing, improving, etc. Evolve basically. Learn over time.

It sounds like your expecting to much, too soon. It's a process which never stops. You'll never get your application 100% correct, ever! Cranck out some code, print it, read, whatever. Understand it, map it to design patterns, etc.

1) Rename functions to make more sense.
2) Refactor objects into a more atomic state.
3) Re-iterate the above over and over again

Software is truely like a living organism, only when a project dies does it stop growing and changing. So like your source code your methods and techniques should change and evolve to fit your requirements, etc.

I would suggest reading XP or Agile books, but they don't really disscuss anything design specific. They are more geared towards project managament, developing a culture of high performance developers, who adapt and don't just accept what is said to be the best or only way...

They also kind of assume you've had experience working on large projects, where you have maybe experienced sympotoms of code rott, or fragile source bases, etc. I'm not sure where you stand in that department, but for now it sounds like you need to read up on OOD.

Those design pattern books that Arborint always suggests, are a good start, but again it helps if you've written code and made those realizations yourself first then have them formalized by a third party. They do serve a purpose:

1) The further your grasp/understanding of abstract thinking - this cannot be learned except through osmosis.
2) The give a common vocabulary to begin easily disscussing ideas amongst others and assist in further understanding what it is your code is doing.

I'm not sure I am as enthusiastic about them as arborint is, but they good to know, even marginally. Just a general understanding will make a difference in your overview of your own code. Reminding yourself, that "the application entry point where pages are selected based on GET variables and pulled in with a simple PHP include at runtime, which are invoked by specially constructed URL's in the client end" it's alot easier to assume some defaults (native to your PHP environment) and just tell yourself front controller...

Less words, more pictures...afterall a picture is worth a thousand words, not visa versa.

Cheers :)

Posted: Sat Oct 14, 2006 7:37 pm
by alex.barylski
Yossarian wrote:@Ninja.

How depressingly brutal, stark and honest a post you made there.

They don't explain that in the OOP books do they?

I would go along with the poster who said make a Framework, actually many pieces fell into place when I just used a Framework - I don't feel skilled enough to make my own... Yet using a framework has kind of realeased me focus on set parts, like trying different domain models, use their Active Record or make my own? Try making data mapper.. Then wander off and play with views and view helpers, start fiddling and twiddling, try making an observer to report errors... You have to play.

It did help me to get some pretty nifty code out of the door - as I was learning.

The other major thing i did that made some more pieces fall into place is to read Fowlers POEAA.
Nope, that is usually saved for OOD books. :)

Posted: Sat Oct 14, 2006 8:34 pm
by MrPotatoes
dude. you just gotta write a book. i'm saying this in jest cuz every single one of your posts goes into nauseating detail. i think i fainted twice when trying to read that post.

omg lol

Posted: Sat Oct 14, 2006 9:04 pm
by Luke
Thank you all for the advice.

I realize learning just takes time, I just hope that soon I'll be able to give with any confidence a realistic timeframe when somebody asks how long a project will take. Last time I gave an estimate, I estimated 12 hours and in reality it took me about 30 or more. I told my bosses when they hired me that I was really only learning PHP and wasn't ready to start building large applications yet... I think that I tend to try and go overboard with things too... the application that I grossly underestimated was mostly because it was already built, and just needed some pretty major adjustments, but after an hour or two of digging through it's horrible code, I just decided to start over... I tend to do things like that often. :?

Luckily, my bosses are great guys, but I just don't want to waste their money. I'm pretty sure that they realize that right now I'm learning, but the more time I spend learning, the more valueable I will be in the long run.

Posted: Sat Oct 14, 2006 9:21 pm
by alex.barylski
The Ninja Space Goat wrote:Thank you all for the advice.

I realize learning just takes time, I just hope that soon I'll be able to give with any confidence a realistic timeframe when somebody asks how long a project will take. Last time I gave an estimate, I estimated 12 hours and in reality it took me about 30 or more. I told my bosses when they hired me that I was really only learning PHP and wasn't ready to start building large applications yet... I think that I tend to try and go overboard with things too... the application that I grossly underestimated was mostly because it was already built, and just needed some pretty major adjustments, but after an hour or two of digging through it's horrible code, I just decided to start over... I tend to do things like that often. :?

Luckily, my bosses are great guys, but I just don't want to waste their money. I'm pretty sure that they realize that right now I'm learning, but the more time I spend learning, the more valueable I will be in the long run.
Hmmmm...most people padd their hours...some more than others of course, but I don't think adding 30-35% (hours) would be untypical...

I don't think anyone can estimate exact time frame for anything but the most simple applications.

p.s-If the code is bad, it makes sense to reuse what you can but redesign it...

Cheers