743 reputation
1410
bio website last.fm/user/KaptajnKold
location Denmark
age 35
visits member for 3 years, 9 months
seen Jun 26 at 9:27
JavaScript developer by trade. Ruby developer in my free time. Lover of dynamic, reflective languages.

Jun
4
comment Significant amount of the time, I can't think of a reason to have an object instead of a static class. Do objects have more benefits than I think?
@Prog You speak of static classes with state. That's basically just a singleton. So you question then is: Why don't just have that instead of using the Singleton pattern? Honestly, I don't know. But! Many consider the Singleton pattern to be more of an anti-pattern, because it is effectively the same as a global variable. See here for why: c2.com/cgi/wiki?GlobalVariablesAreBad
Nov
22
comment What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
I was adressing your claim that a class that indirectly performs 50 tasks not directly related to its area of responsibility, is in violation of SRP. I claim that it is not, if the responsibility of actually performing the work is kept out of the class. This is the point of view that the article lends weight to, and I'm baffled that you don't see that. It is obvious that Robert Martin sees no problem with a class having a wide interface that exposes behavior it is not itself directly responisble for. In fact he seems to consider it a good thing.
Nov
20
comment What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
@Aaronaught Bob Martin (who coined the term SRP) clearly doesn't agree with your definition of SRP: butunclebob.com/ArticleS.UncleBob.SrpInRuby
Nov
13
comment What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
@GlenPeterson I agree, and part of my answer was that it is the Context (Widget in my example) that is responsible for deciding what a given User is permitted to do. It may decide based on the Role of the User (is it an Admin? Does it have at least 50 karma points?) or on whether the User has some special relationship with the Context (think of a file or a blog post: Is the User the owner or the creator?) or on some other policy (Is the User on the list? Is it monday?). Whatever the policy though, you should still only depend on the User object and the Context object in the client code.
Nov
6
comment What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
@Aaronaught Yes, User.isAdmin() might be called be 30 other classes, but why is this is problem? You keep hammering on SRP, but fail to explain the nature of the risk I run by violating your definition of it.
Nov
5
comment What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
@JamesSnell Maybe we misunderstand each other? The question of whether or not a user is an admin is not the same as the question of whether or not a user is permitted to perform a specific action. The answer to the first question is always independent from the context. The answer to the second is very much dependent on the context. This is what I tried to address in the second half of my original answer.
Nov
5
comment What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
@JamesSnell Maybe. If. But that's an implementation detail which I would still confine within the isAdmin method on User. That way your client code doesn't have to change when the "admin-ness" of a User evolves from being a boolean field to something more advanced. You might have many places where you need to know if a User is an admin and you don't want to have to change them every time your authorisation system changes.
Nov
5
comment What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
@GlenPeterson Well, I tried to address the part of the question which was 'what it looks like done "right"' Also: You should absolutely not feel guilty about agreeing with me :)
Nov
5
comment What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
"There's nothing wrong with a User.IsAdmin field... unless there is also a User.Name field" you write. But what isAdmin is a method? It might just delegate to an object whose responsibility it is to keep track of permissions. What is best practice in the design of a relational model (what fields an entity has) is not necessarily translatable to what is best practice in an OO model (what messages an object can respond to).
Nov
14
comment Drawbacks of code kata
@dzieciou: I have experience in martial arts kata having practiced Karate for several years. And while I believe that there are some useful aspects of fighting that can be learned from kata, I also believe that it is ultimately not a very efficient way to train. You should train as you fight as they say. That is if your purpose is to become a better fighter. Some people find practicing kata to be a joyful pursuit in itself. There's nothing wrong with that. Eventually some of them become very good. At kata.
Dec
27
comment Two HTML elements with same id attribute: How bad is it really?
You write that browsers are too accommodating like it's bad thing, but surely you don't believe that?
Dec
7
comment Why aren't there other client-side scripting languages for websites?
"it can be OOP"... It is OOP! Inheritance is not what defines OOP. Objects are.
Nov
7
comment OO best practices for C programs
No reason to try to implement inheritance. As a means to achieve code reuse, it's a flawed idea to begin with. Object composition is easier and better.
Oct
20
comment Why is Scheme my first language in university?
I agree; I started CS knowing Pascal, C, Basic, x86 Assembler, while others had experiences in different languages or none at all. We were introduced to ML which not only no one had any prior experience with but which had a paradigm so foreign that it was like starting over even for the most experienced among us. Later, I think ML (the functional paradigm) is the most useful thing I learned at CS.
Sep
30
comment Do you write titles in code comments?
Another benefit: Having a properly named, small function guarantees that the description does not 'rot'. Oftentimes people will forget to update comments when they update the code, making the descriptions unreliable and is actually worse than not having them at all.
Sep
19
comment How do you manage refactoring with a large code base and many developers?
Why do you want to prevent that? Is it to avoid complications (bugs) or to save developer time? The solution depends very much on the answer to this IMO.
Dec
15
comment Which things instantly ring alarm bells when looking at code?
Re. handwriting: I don't care if someone's handwriting isn't beautiful, but I do care if it's slobby and looks as if they couldn't even read it themselves. I'm really just talking from my own limited experiences, and yours may be different.