Principle of Best Principles

I seem to run into a couple of design issue a lot and I never know what
is
really proper. On one hand I often hear that I should limit coupling and
stick to single responsibility, but when I do I often find it difficult
to
get the information to part of the program when it is needed. For
example,

class Singer
def initialize(name)
@name = name
end
attr :name
end

Then should Song be:

class Song
def new(singer)
@singer = singer
end
end

or

class Song
def new(singer_name)
@singer_name = singer_name
end
end

The later has less coupling, so according to principles I should use it.
But if I later discover something in Song needs to know more about the
singer, I’m in a bad way. e.g.

class Song

def play
puts “Belting it out by #{@singer.name}, winner of
#{@singer.grammy_count} grammies!”
end
end

I’d be in a fix if I had used the later Song class instead of the
former.
But then I suspect someone would remind me of SRP, single responsibility
principle, and suggest instead:

class SongPlayer
def initialize(singer, song)
@singer, @song = singer, song
end
def play
puts “Belting it out by #{@singer.name}, winner of
#{@singer.grammy_count} grammies!”
end
end

And yea, I guess that makes sense, since another singer might do a cover
of
some one else’s song, right? But then, would it really be the exact same
song? In most of my cases it’s never the same “song” so I never have
that
kind of scenario. So is the SRP worth the extra classes it brings to the
code then?

I sometimes think many OOP principles, SOLID or otherwise, arose out
limitations of Java, and don’t apply so well to Ruby.

If you are interested Ruby Design Patterns and Idioms, check out Russ
Olsen’s books Design Patterns in Ruby and Eloquent Ruby. They really
helped
to take my skills to the next level.

On Sun, Nov 20, 2011 at 2:42 PM, Intransition [email protected]
wrote:

end

class Song

And yea, I guess that makes sense, since another singer might do a cover
of some one else’s song, right? But then, would it really be the exact same
song? In most of my cases it’s never the same “song” so I never have that
kind of scenario. So is the SRP worth the extra classes it brings to the
code then?

I sometimes think many OOP principles, SOLID or otherwise, arose out
limitations of Java, and don’t apply so well to Ruby.


Sincerely,

Isaac S.
Section C-4B Vice Chief, Order of the Arrow
Vice Chief of Administration, Tecumseh #65
Eagle Scout

Just delegate.

On Nov 20, 2011, at 8:42 PM, Intransition wrote:

I sometimes think many OOP principles, SOLID or otherwise, arose out
limitations of Java, and don’t apply so well to Ruby.

Hmmm… perhaps… but does this have anything to do with OOP per se?

Alternatively, irrespectively of implementation flavor, how would you
model your song-singer in an entity-relationship diagram [1]?

A song has zero, one or many singer? Potentially many, one would guess.
A singer has zero, one or many song? Potentially many, one would guess.

So, looks like a many to many relationship, no? Irrespectively of
implementation language, no?

[1] http://en.wikipedia.org/wiki/Entity-relationship_model

On Sunday, November 20, 2011 3:53:43 PM UTC-5, Steve K. wrote:

Just delegate.

Ha. I first read that as “Just dance!”

I like that song. :slight_smile:

Just delegate.

Such an answer does not help at all.

Let’s send it to /dev/null.

I myself tend to ignore most patterns. When a class
needs to know something, I change it so that it will
know.

It’s more important to get the job done than strive
for the perfect design.

While ramming it in is an option, I think that it does pay to try and
come up with good designs that will be flexible. I’ve found that
ramming things in seems to fall apart as soon as my boss decides that
he needs something different or I realize that my initial thoughts on
the problem were wrong. Just the other day I realized that some code
I had been working on simply would not work because there was no
elegant way to tell whether a record was primary,secondary, or
tertiary. I had to rethink the form and the code (Which I had been
preparing to move into a custom asp mvc model binder and out of the
controller action. So I guess it was good timing.) on the server side,
as well as the Javascript I had been using up until that point.

On Mon, Nov 21, 2011 at 06:19:33PM +0900, Kevin wrote:

On Mon, Nov 21, 2011 at 3:54 AM, Marc H. wrote:

It’s more important to get the job done than strive
for the perfect design.
While ramming it in is an option, I think that it does pay to try and
come up with good designs that will be flexible. I’ve found that
ramming things in seems to fall apart as soon as my boss decides that
he needs something different or I realize that my initial thoughts on
the problem were wrong.

Well, my experience so far is that it’s wrong to just rush
forward without even trying to design, plan and experiment;
but it might be just as wrong to overengineer in terms of
the first usable result availability.

I’ve read an interesting thing in Ed Hillary’s book on the
conquest of Everest: it’s often not feasible to understand
the path beforehand until you climb high enough to see the
cracks and whirls lying forth (and I’ve walked even if not
climbed mountains myself as well to concur).

Maybe a good part of the reason behind sane (sic!) application
of agile techniques is related to this same phenomena: we’re
better off exploring and advancing in iterations without relying
on our – or boss’ or customer’s – understanding of the problem
at hand which might just honestly overlook something important
or change over time due to unpredictable circumstances change.

So to me you’re both right in some sense.

Further reading might include “The Rise of ‘Worse Is Better’”
and subsequent “Worse Is Better Is Worse” for those interested.

(diving back to makefiles and shell of a distro build metasystem)

On Sun, Nov 20, 2011 at 8:42 PM, Intransition [email protected]
wrote:

Then should Song be:
end
I’d be in a fix if I had used the later Song class instead of the former.
end
And yea, I guess that makes sense, since another singer might do a cover of
some one else’s song, right? But then, would it really be the exact same
song? In most of my cases it’s never the same “song” so I never have that
kind of scenario. So is the SRP worth the extra classes it brings to the
code then?

I believe it helps to look at this with a bit more abstraction (think:
UML class diagram). For me the solution of this example is pretty
clear: a Song has a relationship with a Singer (or Interpret) - and
not with a singer’s name. In fact it’s a n:1 relationship. If you
want to model the act of singing you could add a class Performance
which binds together a Song and an Interpret (not necessarily the
original Interpret) along with additional properties like location and
time (there may be more: duration, unplugged?, paid?, charity_concert?
…).

I think the mere fact that it is quite obvious that you may want to
access more features than just the singer’s name when dealing with a
Song is indicative of the fact that you should not use the name only
but the Singer instance instead. IMHO using the name would be too
loose coupling - which isn’t good either because - as you notice - it
needs much more context to get at the Singer from the name only. Also
note, that a singer’s name may not be unique, so it does not lend
itself easily to a primary key which must be unique. And if you start
adding an id to the Song then you need at least an additional Hash
with id as key and Singer as value to find the proper Singer back.

There is a saying by a guy which was pretty slick and I think it
applies here as well:
http://www.brainyquote.com/quotes/quotes/a/alberteins103652.html
:wink:

Kind regards

robert

NameError in ClistingsController#create

undefined local variable or method `clisting’ for
#ClistingsController:0xb6d63d58

Rails.root: /home/gbolahan/sites/spotvilla
Application Trace | Framework Trace | Full Trace

app/controllers/clistings_controller.rb:45:in `create’

i am wondering why i am having a no name error in the above segement of
code
pls assis t in sorting out hte root of the problem.

here is some segement of the code i the controller to give some
clarification.

def create
@categories = Category.all
@clisting = clisting.new(params[:Clisting])

respond_to do |format|
  if @clisting.save

As it turns out you (and others) are pretty spot on, though I’m not sure
the n:1 relationship is necessarily the best way to think about it, it
did
provide a good starting point. But the “too loose coupling” is really
the
great point here. And that’s something you don’t often hear!!! We always
here about over-coupling. But really it’s “just right coupling” that is
the
real deal.

So in my (real life) case I kept the coupling.

However, I did end up applying the Single Responsibility Principle, and
though it was bit difficult to work out the restructuring as first, the
code turned out much cleaner in the end. So that pattern at least proved
itself.

Lessons learned.

Thanks.

On 21.11.2011 13:50, gbolahan a. wrote:

here is some segement of the code i the controller to give some
clarification.

def create
@categories = Category.all
@clisting = clisting.new(params[:Clisting])

 respond_to do |format|
   if @clisting.save

Try this:
@clisting = Clisting.new(params[:clisting]) #Clisting.new instead
clisting.new
Because Clisting is a constant and the name of the model and clisting is
local variable

On Mon, Nov 21, 2011 at 11:00 PM, Intransition [email protected]
wrote:

As it turns out you (and others) are pretty spot on, though I’m not sure the
n:1 relationship is necessarily the best way to think about it, it did
provide a good starting point. But the “too loose coupling” is really the
great point here. And that’s something you don’t often hear!!! We always
here about over-coupling.

Just out of curiosity: whereabouts do you hear so often about
“over-coupling”? One explanation for the high frequency might be that
a lot of code that gets written has too tight coupling (“spaghetti
code”) - at least that’s what I see in my daily work. One reason for
that in turn might be that people do not have a clear understanding
where they are heading to with a piece of code. Another reason might
be that the purpose of a piece of code changes over time and often
people do not go through the exercise of refactoring - either because
of laziness or - more likely in the corporate world - because they
don’t get the resources (time) granted (which, btw, seems a very short
sighted strategy to me because it will come back haunt you later).

But really it’s “just right coupling” that is the real deal.

Absolutely. It’s generally easy to go to extremes. It’s much harder
to find the right middle ground. A good solution to a technical
problem requires more work than a mediocre solution. So chances are
that good solutions rather lie in the middle ground than at the
extremes. You can even generalize that to other areas of life itself:

http://en.wikipedia.org/wiki/Middle_way

So in my (real life) case I kept the coupling.

However, I did end up applying the Single Responsibility Principle, and
though it was bit difficult to work out the restructuring as first, the code
turned out much cleaner in the end. So that pattern at least proved itself.

Lessons learned.

Thanks.

What a great feedback! It’s good to see how the community evolves
through collaborative learning experiences. That’s what makes this
community such a great place.

Kind regards

robert

PS: I find Meyer’s book “OOSC” a great source of OO design advice -
although it is hidden in a large description of Eiffel. The way he
dissects various aspects (e.g. inheritance) shows that he has thought
a lot about OO - and came to an understanding which is rarely equaled.

-----Messaggio originale-----
Da: Sean O’Halpin [mailto:[email protected]]
Inviato: marted 22 novembre 2011 09:28
A: ruby-talk ML
Oggetto: Re: Principle of Best Principles

Not really on topic, but if anyone’s interested in the gory details of
the
complexities of modelling music, see http://musicontology.com/.

From the intro:

“The Music Ontology Specification provides main concepts and properties
[for] describing music (i.e. artists, albums, tracks, but also
performances,
arrangements, etc.) on the Semantic Web.”

Disclaimer: Yves Raimond, one of the authors, sits behind me at work.
Cooking up more fiendish things no doubt.

Regards,
Sean


Caselle da 1GB, trasmetti allegati fino a 3GB e in piu’ IMAP, POP3 e
SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f

Sponsor:
Conto Arancio al 4,20%. Soldi sempre disponibili, zero spese, aprilo in
due minuti!
Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid923&d)-12

Not really on topic, but if anyone’s interested in the gory details of
the complexities of modelling music, see http://musicontology.com/.

From the intro:

“The Music Ontology Specification provides main concepts and
properties [for] describing music (i.e. artists, albums, tracks, but
also performances, arrangements, etc.) on the Semantic Web.”

Disclaimer: Yves Raimond, one of the authors, sits behind me at work.
Cooking up more fiendish things no doubt.

Regards,
Sean