OO Design Principles Compilation • Hacker News Board

Re: OO Design Principles Compilation

#11

Post by techiferous » Sun, Feb 27, 2011, 11:13 PM UTC

Notice the number of shoulds. A list of what you should do is like training wheels: useful for beginners but not as much for the advanced.

Instead of thinking in shoulds I like to think in terms of causes and effects. If you don't follow the law of demeter then these will be the effects. Then the programmer realizes they have a choice: even though the law of demeter usually brings about desirable consequences, maybe in a particular situation the effects of not following the law of demeter bring about the better set of consequences.

Thinking in terms of causes and effects also loosens potential dogma.

Re: OO Design Principles Compilation

#12

Post by extension » Sun, Feb 27, 2011, 11:44 PM UTC

Nate75Sanders wrote: post #8

hello_moto wrote: post #3

This list is very useful. It's 2011 now and you have no idea how many people don't know more than half of the list.

and also how many programmers are extremely effective and know perhaps none of the list.

I think the best programmers know all this stuff instinctively.

Re: OO Design Principles Compilation

#13

Post by extension » Sun, Feb 27, 2011, 11:46 PM UTC

techiferous wrote: post #11

Notice the number of shoulds. A list of what you should do is like training wheels: useful for beginners but not as much for the advanced. Instead of thinking in shoulds I like to think in terms of causes and effects. If you don't follow the law of demeter then these will be the effects. Then the programmer realizes they have a choice: even though the law of demeter usually brings about desirable consequences, maybe…

Someone please add this to the top of the list.

There is little value in following programming rules that you don't understand.

Re: OO Design Principles Compilation

#14

Post by fleitz » Mon, Feb 28, 2011, 12:10 AM UTC

extension wrote: post #13

techiferous wrote: post #11

Notice the number of shoulds. A list of what you should do is like training wheels: useful for beginners but not as much for the advanced. Instead of thinking in shoulds I like to think in terms of causes and effects. If you don't follow the law of demeter then these will be the effects. Then the programmer realizes they have a choice: even though the law of demeter usually brings about desirable consequences, maybe…

Someone please add this to the top of the list. There is little value in following programming rules that you don't understand.

Agreed. Most of software 'methodology' is really software ideology. It's just cargo cult programming. For me the key consideration in building software is whether it produces more money than it consumes.