11–20 of 21 posts
Object orientation is a black box to many and many people think they program object orientated, only because they program in Java or C#. But that's not true. Object Orientation is about program architecture. Learning OO-Pattern is essential for this task and to know the guiding principles of good architectures. Start SOLID and you are save.
There is a fantastic talk by Kevlin Henney where he deconstructs the SOLID principles as each being either misunderstood when they were written - or frequently misunderstood after. It was done here: http://scottishdevelopers.com/tag/solid/ http://sydney.yowconference.com.au/ I won't spoil it by writing all the points here - just some pearls. * The Open/Closed principle is redundant because it is already covered by th…
Also, not everybody has the possibility to visit a conference in Australia.
A lot of programmers don't like/know/care about SOLID or good code design/architecture and also end up complaining when their codebase is a big, huge mess. Often times, just following good OOP principles (and some FP principles) makes it easy to clean up most messes. The biggest thing I think many programmers suffer from is wanting to have too few objects with big, ugly methods inside. More objects, fewer methods, sm…
Nowadays I try to follow good coding principles on my home projects and the small parts I might have some responsibility over.
But for the overall projects, I don't care any longer. It is just playing Quixote on the enterprise, even more so if the project has outsourced or offshored components.
There is a fantastic talk by Kevlin Henney where he deconstructs the SOLID principles as each being either misunderstood when they were written - or frequently misunderstood after. It was done here: http://scottishdevelopers.com/tag/solid/ http://sydney.yowconference.com.au/ I won't spoil it by writing all the points here - just some pearls. * The Open/Closed principle is redundant because it is already covered by th…
Since there seams to be no online video (yet), could you please list the principles added? Also, not everybody has the possibility to visit a conference in Australia.
Earlier quoted context omitted.
If only there were some way to rectify these issues
If that was sarcasm directed at him with the implication that he should try to fix it by editing it himself, I'm not sure how much experience you've had trying to edit a Wikipedia article. It can be a horrid experience.
Interesting take on the open closed principle
Earlier quoted context omitted.
If only there were some way to rectify these issues
If that was sarcasm directed at him with the implication that he should try to fix it by editing it himself, I'm not sure how much experience you've had trying to edit a Wikipedia article. It can be a horrid experience.
A lot of programmers don't like/know/care about SOLID or good code design/architecture and also end up complaining when their codebase is a big, huge mess. Often times, just following good OOP principles (and some FP principles) makes it easy to clean up most messes. The biggest thing I think many programmers suffer from is wanting to have too few objects with big, ugly methods inside. More objects, fewer methods, sm…
Personally, I like the Alan Kay's definition:
>OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.
http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...
Earlier quoted context omitted.
Since there seams to be no online video (yet), could you please list the principles added? Also, not everybody has the possibility to visit a conference in Australia.
A bit meager, but it could be FLUID: http://www.slideshare.net/anoras/ndc-2011-the-fluid-principl... (same author)
A lot of programmers don't like/know/care about SOLID or good code design/architecture and also end up complaining when their codebase is a big, huge mess. Often times, just following good OOP principles (and some FP principles) makes it easy to clean up most messes. The biggest thing I think many programmers suffer from is wanting to have too few objects with big, ugly methods inside. More objects, fewer methods, sm…
My intuition is that in the junior-developer brain, a problem that's big enough to justify using design patterns and SOLID code is a really scary thing that's simply going to take more time than they have. They aren't comfortable with the idea that they can't contain the whole problem in their heads and inside just one or two files, so rather than breaking the problem apart so they can work on one piece at a time, they pick a part of the problem they can start with (usually something involving manipulating strings or very simple models... something that's simple to solve with a couple of methods) and "organically" grow it into more and more methods and shared state until it's bigger and scarier than the problem they started out with!
I've watched people's eyes light up with anxiety as they are introduced to a big and complex but well organized and decoupled solution that contains a lot of classes... the immediate reaction is "What a mess! There are so many files!" Their first instinct is to want to combine things together, thinking that it would reduce complexity or produce some kind of "savings." They will choose tight coupling over "more code" every time, which is ironic because as soon as a problem caused by the tight coupling crops up, the first instinct is to liberally apply more code until the problem is solved.