Ruby version of UnicodeFileToHtmlTextConverter both original problem and tested and refactored solution #14

Merged
merged 3 commits into from Sep 12, 2012

Conversation

Projects
None yet
2 participants
Contributor

Sam-Serpoosh commented Sep 12, 2012

And here is the last one! Thanks again for publishing these exercises they were interesting!

Regards,

Owner

lucaminudel commented Sep 12, 2012

A question on the solution. Isn't possible to use IO (does it define a general protocol for input or output for files bat also others in memory sources?) as generic source to pass to the initialize method ?

That should work with files but also with strings (in tests) or in future other sources. In this way the OCP is also respected.

lucaminudel added a commit that referenced this pull request Sep 12, 2012

Merge pull request #14 from Sam-Serpoosh/master
Ruby version of UnicodeFileToHtmlTextConverter both original problem and tested and refactored solution

@lucaminudel lucaminudel merged commit 428078b into lucaminudel:master Sep 12, 2012

Contributor

Sam-Serpoosh commented Sep 12, 2012

You mean instead of the file_path we pass the IO through the constructor?
can you elaborate that a little more (maybe with a code example?) cause I'm
not sure if I get your point!
Thanks

Regards,

Sam Serpoosh
Software Developer: http://masihjesus.wordpress.com
Twitter @masihjesus http://twitter.com/masihjesus

Owner

lucaminudel commented Sep 12, 2012

If I understood correctly (I'm new to Ruby) File::Open return a File object that inherit from IO like all the input/output classes in Ruby. Let's say that IO define the abstract concept of an i/o stream.

I can write UnicodeFileToHtmTextConverter.initialize that accept an object that implement the IO protocol (for the input part since the class read only).
If the parameter instead is a string, the initialize can open the file and use that as input.

Something like this:

def initialize(source)
   if source.respond_to?("read")
       @source = source
   else 
       @source = File.open(source)
   end 
end

Does this make sense?

Contributor

Sam-Serpoosh commented Sep 12, 2012

If I understood correctly (I'm new to Ruby) File::Open return a File
object that inherit from IO like all the input/output classes in Ruby.
Let's say that IO define the abstract concept of an i/o stream.

I'm not experienced in Ruby (and in the whole software development cause
I'm very young yet but I'm super-passionate about about software
development principles, patterns and practices and programming. I'm sure
you got that already!) but most of my experience from the technology and
language point of view is in Microsoft technology stack (C#, ASP.NET, etc.)
and mostly in software craftsmanship idea. about how to produce high
quality software, write clean code, having automated tests in different
levels, etc. And for the past 6-8 months I've been
reading/practicing/working on ruby and rails!

I can write UnicodeFileToHtmTextConverter.initialize that accept an object
that implement the IO protocol (for the input part since the class read
only).

It's a totally true statement. But the thing is in my opinion (maybe I'm
wrong) you are thinking in the style of statically typed languages and this
thinking is true of course in the dynamic typing languages but at the same
time it's not for these kind of languages. As they say in these languages,
"if it walks like a duck and it quacks like a duck, then it's a duck"
(duck-type languages) so if it responds to the read method for example
that's it. (as I said in my comments there that we should handle it with
DIP more strictly in a language like C#, Java, etc.)

If the parameter instead is a string, the initialize can open the file and
use that as input.

Something like this:

def initialize(source)
if source.respond_to?("read")
@source = source
else
@source = File.open(source)
end
end

This is exactly how we should do it in this way. But there's a different
functionality than the original one in this scenario we are not just
supporting the file path for this class. we are supporting in our class
both file path (in that case we do a stream opening for that file) and also
we're supporting the IO directly instead of the file. And it's of course
totally true. Thanks a lot for your suggestion, it was interesting and more
general handling of the thing!

Regards,

Sam Serpoosh
Software Developer: http://masihjesus.wordpress.com
Twitter @masihjesus http://twitter.com/masihjesus

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment