OO Design Principles

[quadz]

Nice list ...

http://mmiika.wordpress.com/oo-design-principles/

[Whirlingdervish]

Pretty good info there.

A lot of it I picked up in C++ courses, but some of the principles weren't exactly worded as nicely as they are here.

Very simple and to the point, just like classes should be! 

[kren.Z]

C++ is such a complex language. It's not really a comfortable language for mere mortals. The methods in the standard library are cryptic, the seperation of namespaces and class implementations are a pain in the ass, the same keywords have different meanings in different situations (I throw around const like a fucking ragdoll), and you have to garabage collect like it's your fucking day job.



Thanks for the link quadz. The beauty of OOP is applying the methodology to different languages.




....Actionscript 

[quadz]

Thanks for the link quadz. The beauty of OOP is applying the methodology to different languages.

Perhaps interestingly, while some of the principles on that list are arguably universal (DRY, for instance), others would seem to make more sense in a language like C++, than a highly dynamic language like Ruby.

For instance, ruby's classes are open.  And it's a feature of the language.  A feature that does require discipline to use without shooting yourself in the foot, to be sure.  And a feature that I use sparingly...  But also very handy on occasion.

Here's an example of ruby's open classes... From the interactive ruby prompt, I'll add an 'md5' method to the core String class, on-the-fly:

>> require 'digest/md5'
=> true
>> class String
>>   def md5
>>     Digest::MD5.hexdigest(self)
>>   end
>> end
=> nil
>> "fubar".md5
=> "5185e8b8fd8a71fc80545e144f91faf2"

All instances of String now respond to the method md5.

Here's a recent post from the ruby-talk mailing list about the application of some of the OO design principles on the above list, to ruby:

> Re: Ruby's take on S.O.L.I.D
> >> Any thoughts on how duck typing impacts the usefulness or necessity of
> >> these design principles? For instance, I don't really hear much
> >> regarding Liskov's Substitution Principle around Ruby programmers and am
> >> interested in opinions as to why.

I was a SOLID developer in my C# days, but I don't feel it applies as
well to dynamic languages like Ruby.

The S, I still agree with: single responsibility per class.

The O is something I'm on the fence about.  Ruby allows you to open
classes and modify them, and I've seen how valuable this is when you
know what you're doing.

The LID (substitution, inteface granularity, dependency injection) are
just non-issues for me with Ruby.  I enjoy duck-typing so much more
than worrying about interface granularities, and I don't need to use
dependency injection anymore (which I really only used to make things
more testable, which I can do with Mocha nowadays anyway).

I'd be interested in other viewpoints on this, but I think SOLID is
great advice only for statically-typed languages and isn't quite as
important with a language like Ruby.

For me, the SOLID equivalent would go like this:

Single Responsibility per Class
Drive your development with unit tests
Have fun

...but "SDH" isn't as easily pronounced as SOLID. :-)

Regards,

[reaper]

This guy has some funny comments in my favorite program.

I wish I could understand it, hopefully one day I will figure it out : ).  There is some object oriented  code, pointers and using of malloc, it's not to long and written in C.  But I stopped learning C after I got pointers down, I don't really understand structures and objects ( although I've used some OOP in perl, I just didn't really know what I was doing )