On Wed, Feb 27, 2008 at 11:42 AM, Aschwin Wesselius <aschwin@xxxxxxxxxxxxxx> wrote: > Nathan Nobbe wrote: > > i understand designing for simplicity is key, however, things can only > be > > kept > > so simple beyond reason. the more something does, the more complex it > is; > > period. > > > > -nathan > > > Nice touch, but what I'm most afraid of is abstraction layers. It is > good to know what to abstract, but also how it is abstracted and where > it came from. > > Sometimes, abstraction makes it so unbelievable complex, just because of > the sake of abstraction (or over-engineering). Maybe it's just me, but I > like things clean and simple. I can't grasp oversight easily. Especially > when it's someone else's code. > > I do acknowledge the need (or purpose) of OOP, but sometimes you can > make it more clean and simple by getting rid of the clutter. If you > don't know anymore where the code is that you need to edit, you have to > read the code over and over again (parsing it in your head to something > that makes sense). If you have to do this 10, 20 or even 50 times a day > my head explodes. > > I have to deal with spaghetti code from some old code-base every day, it > frustrates me because I can't get inside the head of the programmer who > wrote this trash. Nice patterns, nice classes (not so OOP), no > documentation. It takes to much memory, to much included files (125+), > to many templates, sometimes a 1000+ queries per page (mad!). > > No. Give me procedural code please. I can read that from top to bottom, > it sticks on 1 flow of the processing. Downside is having some code > multiple times all over the place (hence an argument for OOP). But that > saves me time and a huge headache every day. I like it to maintain it > that way. And maybe the programmer after me has to clean it up too. But > refactoring procedural code is way easier that refactoring OOP code is > my opinion adding layers of abstraction arbitrarily is foolish no matter what style the code is written in. design patterns are largely methodologies for adding abstraction but it takes time and practice to know when to use a particular pattern and how to implement it. one of the things that functions, and patterns do in general is assign labels to concepts. this is where functions take the first step over procedural code; you have something people can refer to in an abstract way; w/o referring to the implementation. this enhances conversations, and reduces complexity, think about a conversation where people are discussing a procedural block of code; "you know in said file, where the code does that one thing..." where as w/ a function, you can easily refer to the functionality; "you know, the doThatOneThing() function..". patterns do the same thing for software engineering, so rather than saying; "dude, i built this thing where other things can like register, then they can like all get messages from it when it changes.." thats where a patterns guy steps in and says "ya dude, thats observer!". and if you all know about it in advance you can save yourself the hassle and just say observer, then youre all on the same page immediately. think of the impact this has on a design session; it doesnt quickly degrade into a low level conversation about implementation details, because you already know how to implement observer. -nathan
