I don't love the single responsibility principle • Hacker News Board

Re: I don't love the single responsibility principle

#121

Post by fleitz » Wed, May 07, 2014, 10:22 PM UTC

kasey_junk wrote: post #44

fleitz wrote: post #36

Earlier quoted context omitted.

Well, I'm assuming we're comparing code that works. Maintenance is generally a red herring, it's best to use statistical methods to determine the likelihood of maintenance. Usually if you're doing lots of maintenance you have other problems in your code / workflow, such as mistaking your codebase for your database.

"Well, I'm assuming we're comparing code that works." That is an interesting assumption given that in many problem domains proving that the code works as specified is the hardest problem. "Maintenance is generally a red herring, it's best to use statistical methods to determine the likelihood of maintenance." I really dislike anyone who makes general claims about the entirety of software development. I for one spend…

Proving your hand won't go through a wall is a difficult problem in quantum physics, for most people they just push against the wall. I don't care whether the code is provably correct, I care that it does what the user expects.

Actually 'change requests' are even easier when the requirements change frequently, just provide an estimate in excess of when you think the next change will be, then put your feet up and wait for the requirements to change again.

PS. Changing requirements isn't 'maintenance', it's a change request.

PPS. Having to add code to add fields to a form means you spec'd your solution around your forms instead of specing your solution around solving the problem of changing forms. (aka. you baked your problem domain into your code and now you're fucked) (eg. you mistook your codebase for your database)

Re: I don't love the single responsibility principle

#122

Post by unclebobmartin » Thu, May 08, 2014, 1:23 AM UTC

pjschwarz wrote: post #120

unclebobmartin wrote: post #103

SRP is very simple. If two different people want to change a class for two different reasons, then pull those reasons into two different classes. That is the SRP. Example: A class that analyzes a data stream and prints a report. The data analysis will interest one group of people. The format of the report will interest another, different, group. The first group will ask for changes to the algorithms. The second will…

Hi Bob, >SRP is very simple...different people want to change a class for ... different reasons... Back in October 2009, in https://sites.google.com/site/unclebobconsultingllc/getting-... I asked you a question on the SRP and you replied as follows: "SRP says to keep together things that change for the same reason, and separate things that change for different reasons. Divergent change occurs when you group together…

Not at all. SRP is about enhancing the cohesion of things that change for the same reasons, and decreasing the coupling between things that change for different reasons.

Re: I don't love the single responsibility principle

#123

Post by tragic » Thu, May 08, 2014, 9:33 AM UTC

kyllo wrote: post #114

tragic wrote: post #98

Earlier quoted context omitted.

Having worked with both, there's a trade-off. Given that in Django you're (mostly) explicitly importing classes and modules rather than autoloading, it's handy to have them all in one place. OTOH, when your project grows, you end up with enormous model files (especially if you follow the fat models/thin views pattern). So you then have to split them into different apps, so fragmentation slips in eventually anyway. (I…

Especially since the Rails way is not "decoupling" in any real sense. Splitting tightly coupled code into multiple files != decoupling. I also like that in Django, you declare the fields on the models first and then create the db migrations from them, rather than writing a db migration first to determine what fields the models have.

Indeed, decoupling is probably the wrong word here: I haven't seen an ORM implementation that was not tightly coupled to the database layer, which in the end is surely the point of an ORM - to represent stuff from the database in application code. (I know some people consider this a bad abstraction, but whatever.)

South/1.7 migrations is definitely the best way of the two to manage that coupling. Rails's charms lie elsewhere.

Re: I don't love the single responsibility principle

#124

Post by kyllo » Thu, May 08, 2014, 8:36 PM UTC

tragic wrote: post #123

kyllo wrote: post #114

Earlier quoted context omitted.

Especially since the Rails way is not "decoupling" in any real sense. Splitting tightly coupled code into multiple files != decoupling. I also like that in Django, you declare the fields on the models first and then create the db migrations from them, rather than writing a db migration first to determine what fields the models have.

Indeed, decoupling is probably the wrong word here: I haven't seen an ORM implementation that was not tightly coupled to the database layer, which in the end is surely the point of an ORM - to represent stuff from the database in application code. (I know some people consider this a bad abstraction, but whatever.) South/1.7 migrations is definitely the best way of the two to manage that coupling. Rails's charms lie e…

Right, and the debate raging in the Rails community now is whether your business logic should be in your models at all, or whether it should be extracted into plain old ruby objects, separating your domain model from your data model. Reason being, the OOP purists see it as a violation of the Single Responsibility Principle--an object should only have one reason to change, and the models are tightly coupled to the database schema so they have to change if the schema changes, plus you need to start up a database just to test their business logic, if you put business logic in them.

Meanwhile a lot of the practically minded developers like DHH just accept that their objects will be tightly coupled to the database and just deal with it, claiming that anything else would be adding unnecessary layers of indirection.

I am pretty new to Django, but I get the impression that it's not so hard to just not put your business logic in models.py, and put it in separate classes of plain old python objects instead. Maybe that's why I haven't heard about this debate playing out in the Django community the way it is in the RoR community...

Re: I don't love the single responsibility principle

#125

Post by Cymen » Tue, May 13, 2014, 11:16 PM UTC

thibauts wrote: post #119

thibauts wrote: post #50

Earlier quoted context omitted.

"Instead of thinking out of my box for once, I'll biker about OP that's probably not a craftsman (tm) and assume pretty much anything about him and his bad intentions provided it helps me rationalize my fear in a belief-preserving way". So no thanks, I don't want Uncle Bobby to save me, I don't need an encyclopedia either. Have a good day my friend. (Go easy on the blue pill ...)

I may have been a bit harsh, sorry for that.

I too was too harsh and I too apologize. It can be a struggle to try to convey one's thoughts about a subject while still being reasonable.