748 reputation
1410
bio website last.fm/user/KaptajnKold
location Denmark
age 36
visits member for 4 years, 2 months
seen Dec 7 at 21:22
JavaScript developer by trade. Ruby developer in my free time. Lover of dynamic, reflective languages.

Aug
14
comment Why do people nowadays use factory classes so often?
+1 I find that adhering to a rule of absolutely no logic in a constructor is not a bad idea. A constructor should only be used for setting the initial state of the object by assigning its arguments values to instance variables. If anything more complicated is needed, at the very least make a factory (class) method to build the instance.
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
revised What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
Added an extra paragraph.
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
revised What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
added 72 characters in body
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
awarded  Organizer
Nov
5
revised What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
Add tag 'object oriented design'
Nov
5
suggested approved edit on What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
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
4
answered What is meant by, “A user shouldn't decide whether it is an Admin or not. The Privileges or Security system should.”
Nov
4
awarded  Yearling
Jun
10
awarded  Populist
Mar
11
awarded  Commentator
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.