# From functions to classes, where should I start? **URL:** \ **Category:** Ruby\ **Created:** [July 9, 2010, 12:40pm UTC](https://www.ruby-forum.com/t/from-functions-to-classes-where-should-i-start/191306 "2010-07-09T12:40:43Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![salamond](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@salamond](https://www.ruby-forum.com/u/salamond)\ **Post date:** [July 9, 2010, 12:40pm UTC](https://www.ruby-forum.com/t/from-functions-to-classes-where-should-i-start/191306/1 "2010-07-09T12:40:43Z")
Guys, I’m not sure if this is the right place to ask questions like this. I’m a software tester, working for 4.5 years. Most of the work is about manual testing, for 1-2 month per year, I need to write my own scripts for automation or tools. For the first 2 years, all scripts are pure steps, do step1, step2, if fail, exit. Then I came across this book: clean-code: a hand book to agile software craftsmanship. I read it through once, several chapters twice or even more. My code starts to evolve with more structured functions, meaningful names, etc. Now that I want to try OO, to change my procedure function level to class level. But I just don’t know how to evaluate my OO designs, how to start refactor functions to classes. Is there any books, tutorials, heurstic lists that I can start reading or practice? Thanks JaordZZ ---
**Author:** ![salamond](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@salamond](https://www.ruby-forum.com/u/salamond)\ **Post date:** [July 9, 2010, 7:15pm UTC](https://www.ruby-forum.com/t/from-functions-to-classes-where-should-i-start/191306/2 "2010-07-09T19:15:31Z")
Hi JaordZZ, I began software development using OOP can’t recall any books to recommend. I would encourage you to think critically about when to use OOP, rather than doing it simply because of Agile dogma. When reviewing my code, I’ve often found that I tend to use classes for everything – just out of habit (and due to a heavy Java background). When coding, I now try to ask myself, “Does this code represent something that benefits from OOP, or should it exist as a function(or Module or static method)?”. Here are some of the most common reasons to consider OOP: 1. Making state information handy to the functions that need it. If you find yourself passing the same data in as parameters to related functions, then consider wrapping the data and functions up into a class. 2. Organizing large amounts of code OOP allows you to present public interfaces that simplify the usage of code. This is very helpful for large projects, but not usually necessary for smaller scripts and projects. 3. Use of inheritance or polymorphism If you want to benefit from subclassing objects. And some common reasons to consider your current approach: 1. You are already using it and it works (or does it?) 2. There is a small performance penalty with each object that is instantiated I know this is very oversimplified, but my lunch break is ending soon. 😉 Hope that helps a little. ---
**Author:** ![salamond](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@salamond](https://www.ruby-forum.com/u/salamond)\ **Post date:** [July 9, 2010, 11:15pm UTC](https://www.ruby-forum.com/t/from-functions-to-classes-where-should-i-start/191306/3 "2010-07-09T23:15:33Z")
On 09.07.2010 19:11, Jay wrote: > Here are some of the most common reasons to consider OOP: > > 1. Making state information handy to the functions that need it. > If you find yourself passing the same data in as parameters to related > functions, then consider wrapping the data and functions up into a > class. The key word for this is “encapsulation”. I believe it is the most important aspect of OO. > 1. Organizing large amounts of code > OOP allows you to present public interfaces that simplify the usage of > code. This is very helpful for large projects, but not usually > necessary for smaller scripts and projects. I think this is normally named “information hiding”. I use it even for smaller scripts. > 1. Use of inheritance or polymorphism > If you want to benefit from subclassing objects. IMHO inheritance is overrated (or maybe overused). Often people turn to inheritance where composition would be a better choice. But I agree, this is another important aspect of OO. > And some common reasons to consider your current approach: > > 1. You are already using it and it works (or does it?) > 2. There is a small performance penalty with each object that is > instantiated > > I know this is very oversimplified, but my lunch break is ending > soon. 😉 … and I have to go to bed now. 🙂 Cheers robert PS: JaordZZ, a book or tutorial about patterns might help. See here for a start: > **[Software design pattern](https://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29)** > > In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.... ---
**Author:** ![salamond](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@salamond](https://www.ruby-forum.com/u/salamond)\ **Post date:** [July 10, 2010, 6:51pm UTC](https://www.ruby-forum.com/t/from-functions-to-classes-where-should-i-start/191306/4 "2010-07-10T18:51:26Z")
On 10.07.2010 01:44, salamond wrote: > Thanks, Robert and Jay. > > I started programming with C, not the type of a natural OO programmer. > And yes, the Procedure Oriented way, or function way works fine for > me, almost all the time. The funny thing is, you can code OO even in a language like C. Of course it is much easier in a truly OO language but if you look at the C standard library you can look at it in a OO way in parts. For example look at syscalls open(), write(), read() and close(). open() returns a file descriptor (aka object id) and this is what you pass to the other three methods - pardon: functions - along with more parameters. You can see read() and write() as ordinary methods and close() as the destructor. Of course you do not have polymorphism in C but these functions are definitively a case of encapsulation: you do not really know (nor do you need to know) what your operating system’s kernel stores along with the file descriptor and how it performs all those operations. > So here’s what I’ll try: > > - I have a copy of Design Patterns by “gang of 4”, seldom read, I’ll start now > - I think if unit testing is what I need, I should go through unit > testing patterns, see how OO works for a real problem > - I’ll definately follow your suggestions, see if there’s sign for OO > in my scripts, (encapsulation, etc). Sounds like a plan. I am not sure though about the connection you are doing between unit testing and OO. Although most testing frameworks in Ruby are in fact object oriented the whole concept of unit testing also works for non OO code - and a testing framework does not necessarily need to be OO. A strategy for finding classes that I find pretty slick is CRC Cards. This does not have too much overhead and leaves out a lot of detail in the first step. IMHO that helps concentrating on abstract entities. > **[Class-responsibility-collaboration card](https://en.wikipedia.org/wiki/Class-responsibility-collaboration_card)** > > Class-responsibility-collaboration (CRC) cards are a brainstorming tool used in the design of object-oriented software. They were originally proposed by Ward Cunningham and Kent Beck as a teaching tool but are also popular among expert designers and recommended by extreme programming practitioners. Author Martin Fowler has written that CRC cards may be a sensible means by which multiple alternative interactions may be quickly devised, as they avoid a great deal of drawing and erasing. CR CRC card... Another book I usually recommend for in depth coverage of OO is OOSC: > **[Object-Oriented Software Construction, 2nd Edition](https://www.eiffel.org/doc/eiffel/Object-Oriented_Software_Construction%2C_2nd_Edition)** Although it does cover a completely different programming language (Eiffel) it covers all OO concepts I am aware of in a very minute manner. > Again, many thanks to you guys. You’re welcome! Kind regards robert ---
**Author:** ![salamond](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@salamond](https://www.ruby-forum.com/u/salamond)\ **Post date:** [July 10, 2010, 1:44am UTC](https://www.ruby-forum.com/t/from-functions-to-classes-where-should-i-start/191306/5 "2010-07-10T01:44:52Z")
Thanks, Robert and Jay. I started programming with C, not the type of a natural OO programmer. And yes, the Procedure Oriented way, or function way works fine for me, almost all the time. Until I’m considering adding unit tests to my own scripts. With the mock pattern, an interface like Cat with a function “catchRats” is a must to have, then CatImp and CatMock. That’s how mock works. That’s where I start thinking, maybe it’s time to OO. But as you say, it doesn’t have to be OO all the time, unless there is a specific problem better be solved that way. So here’s what I’ll try: - I have a copy of Design Patterns by “gang of 4”, seldom read, I’ll start now - I think if unit testing is what I need, I should go through unit testing patterns, see how OO works for a real problem - I’ll definately follow your suggestions, see if there’s sign for OO in my scripts, (encapsulation, etc). Again, many thanks to you guys. On Sat, Jul 10, 2010 at 5:15 AM, Robert K. ---
**Author:** ![salamond](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@salamond](https://www.ruby-forum.com/u/salamond)\ **Post date:** [July 11, 2010, 7:19pm UTC](https://www.ruby-forum.com/t/from-functions-to-classes-where-should-i-start/191306/6 "2010-07-11T19:19:52Z")
On Fri, Jul 9, 2010 at 10:15 PM, Robert K. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid)wrote: > The key word for this is “encapsulation”. I believe it is the most > IMHO inheritance is overrated (or maybe overused). Often people turn to > inheritance where composition would be a better choice. But I agree, this > is another important aspect of OO. There are (at least) two interesting posts on this on Rick Denatale’s Talk Like A Duck, in which (amongst other things) Rick quotes Alan Kay: [http://talklikeaduck.denhaven2.com/2008/01/01/alan-kay-on-the-meaning-of-oop](http://talklikeaduck.denhaven2.com/2008/01/01/alan-kay-on-the-meaning-of-oop) I’ve written before in this blog about how the meaning of the term “object-oriented programming” got hijacked from it’s original meaning. For example I go into this in some length in my mini-memoirs. [_see link below_] I recently ran into an interesting site with links to “Classical Computer Science Texts”, which in turn led me to this e-mail exchange with Alan Kay on the meaning of OOP from July of 2003. This exchange gives support, with details, for my description of Kay’s concept of what Object-Oriented Programming was supposed to mean. [http://www.purl.org/stefan\_ram/pub/doc\_kay\_oop\_en](http://www.purl.org/stefan_ram/pub/doc_kay_oop_en) [http://talklikeaduck.denhaven2.com/articles/2006/07/29/about-me](http://talklikeaduck.denhaven2.com/articles/2006/07/29/about-me) … One of the things which always attracted me to Smalltalk was that it placed encapsulation above all else. As Alan Kay noted in his memoir about the origins of Smalltalk, his original conception of object-oriented programming was that software should be composed of objects which were, in effect, little computers themselves, which encapsulated both data and behavior, and hid the implementation of both from other objects, with objects interacting via sending messages to each other and replying. This uniform object model separates languages like Smalltalk and Ruby from other “object-oriented” languages. The various versions of Smalltalk all shared this model, although they varied as to some of the semantics of message sending and reception. The idea of classes and inheritance as a way of factoring implementation was actually a rather late addition to Smalltalk. Although Kay acknowledges the Simula language, which also lacked classes and inheritance, as one of the influences on his thinking leading up to Smalltalk, it’s been a popular misconception that the better known Simula-67 was his real influence, when Smalltalk and Simula actually evolved independently. Kay’s term “object-oriented” got hijacked when Peter Wegner published paper entitled “Dimensions of Object Based Language Design” at the second OOPSLA conference in which he defined “object-oriented” as “objects + classes + inheritance.” [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk\_Abstract.html](http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_Abstract.html) … ---
**Author:** ![salamond](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/f14d63/32.png) [@salamond](https://www.ruby-forum.com/u/salamond)\ **Post date:** [July 11, 2010, 9:05pm UTC](https://www.ruby-forum.com/t/from-functions-to-classes-where-should-i-start/191306/7 "2010-07-11T21:05:13Z")
On Sun, Jul 11, 2010 at 1:19 PM, Colin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Kay’s term “object-oriented” got hijacked when Peter Wegner published paper > entitled “Dimensions of Object Based Language Design” at the second OOPSLA > conference in which he defined “object-oriented” as “objects + classes + > inheritance.” > [http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk\_Abstract.html](http://www.smalltalk.org/smalltalk/TheEarlyHistoryOfSmalltalk_Abstract.html) Thanks for the mention Colin. Recently, one of Wegner’s students, William Cook, drafted a paper [http://userweb.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf](http://userweb.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf) which points out what was missed back in the 1980s, that there is a vast difference between Abstract Data Types and Objects, something which I’d argue caused a lot of confusion over the past 25 or so years. – Rick DeNatale Blog: [http://talklikeaduck.denhaven2.com/](http://talklikeaduck.denhaven2.com/) Github: [rubyredrick (Rick DeNatale) · GitHub](http://github.com/rubyredrick) Twitter: @RickDeNatale WWR: [http://www.workingwithrails.com/person/9021-rick-denatale](http://www.workingwithrails.com/person/9021-rick-denatale) LinkedIn: [http://www.linkedin.com/in/rickdenatale](http://www.linkedin.com/in/rickdenatale)