|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
Thanks! I have another question, this time regarding SRP (Single Responsibility Principle).
So if you have a class Person (standard fields such as name, age, etc). Is it reasonable to have a method, e.g. calculateAge() which calculates person's age based on their birth date? Basically, I'm confused if such a method is regarded as a second responsibility for the class, thus violation of SRP. So, how do you go with reasoning in such cases?
On the other hand, this reminds me of 'Feature Envy' (from the book Clean Code), so such a method would wish to be in the class perhaps. Anyway, I'm just confused as I said.
|
|
|
On June 15 2014 07:48 darkness wrote:
Thanks! I have another question, this time regarding SRP (Single Responsibility Principle).
So if you have a class Person (standard fields such as name, age, etc). Is it reasonable to have a method, e.g. calculateAge() which calculates person's age based on their birth date? Basically, I'm confused if such a method is regarded as a second responsibility for the class, thus violation of SRP. So, how do you go with reasoning in such cases?
On the other hand, this reminds me of 'Feature Envy' (from the book Clean Code), so such a method would wish to be in the class perhaps. Anyway, I'm just confused as I said.
The point of design principles isn't to create a rigid set of rules, they're to create sensible code structure.
In this specific case, you really have to ask "Should the age of the person be accessible from the Person class"? Or, maybe more importantly, "If I reuse this Person class, should I have to import a whole other class just to find the age"?
|
Quick question for anyone in the know: is there a trusted textbook for learning VBA? I am comfortable coding in python and java, but I want to pick up VBA. So far, I'm finding it hard to find a good book, because there are so many ads for books on excel and VBA geared toward finance types with no coding experience (and honestly they don't look very good).
I was just seeing if anyone has read a comprehensive VBA book they found particularly good.
Thanks!
|
On June 15 2014 07:48 darkness wrote:
Thanks! I have another question, this time regarding SRP (Single Responsibility Principle).
So if you have a class Person (standard fields such as name, age, etc). Is it reasonable to have a method, e.g. calculateAge() which calculates person's age based on their birth date? Basically, I'm confused if such a method is regarded as a second responsibility for the class, thus violation of SRP. So, how do you go with reasoning in such cases?
On the other hand, this reminds me of 'Feature Envy' (from the book Clean Code), so such a method would wish to be in the class perhaps. Anyway, I'm just confused as I said.
"Single Responsibility Principle" is a somewhat misleading name. SRP means that there "should only be one reason for a class to change"; this is not necessarily the same as "should only do one thing".
Whether you "do one thing" or not changes easily as you move up or down levels of abstraction. For example you could say that your class provides access to a person's name AND age AND so on, or you could say that it provides access to person-related information.
That person class would have to change when you change the range of information it offers about a person. If it also would have to change when you change your data management system or various other things, then that violates the SRP.
|
On June 15 2014 07:48 darkness wrote:
Thanks! I have another question, this time regarding SRP (Single Responsibility Principle).
So if you have a class Person (standard fields such as name, age, etc). Is it reasonable to have a method, e.g. calculateAge() which calculates person's age based on their birth date? Basically, I'm confused if such a method is regarded as a second responsibility for the class, thus violation of SRP. So, how do you go with reasoning in such cases?
On the other hand, this reminds me of 'Feature Envy' (from the book Clean Code), so such a method would wish to be in the class perhaps. Anyway, I'm just confused as I said.
The age accessor definitely belongs in the Person model. A one line method as a mixin that will only ever be able to be used in on a single person object would be silly. Maybe something slightly more complicated, such as a function for calculating the distance between two people would belong in a different class.
|
On June 15 2014 08:02 Nesserev wrote:Show nested quote +On June 15 2014 07:48 darkness wrote:
Thanks! I have another question, this time regarding SRP (Single Responsibility Principle).
So if you have a class Person (standard fields such as name, age, etc). Is it reasonable to have a method, e.g. calculateAge() which calculates person's age based on their birth date? Basically, I'm confused if such a method is regarded as a second responsibility for the class, thus violation of SRP. So, how do you go with reasoning in such cases?
On the other hand, this reminds me of 'Feature Envy' (from the book Clean Code), so such a method would wish to be in the class perhaps. Anyway, I'm just confused as I said. If there's one thing that I learned about SRP, is that you don't want to overthink it... just keep a class as general and as easy to work with as possible, there are so many ways to look at a class, and say "well, I could split this up in ten different classes if I look at it in a different way". In my opinion, it's okay to have a calculateAge()- or a getAge()-method for the Person class. If you look at Person as a class that governs all the information about a certain person, then just like birthdate and name, age is just another piece of information, even if you don't supplement it directly to the class, and need an extra function to calculate it. Show nested quote +On June 14 2014 10:30 mcc wrote:
As far as function size goes, some can be refactored, but in general sometimes large body just makes most sense, because there is no logical grouping of statements that could make a meaningful method. I agree that duplicate code is sometimes preferable, mostly for readability; but having a large body of code almost always means that are multiple steps/phases, so you could definitely split that body up per phase/step into smaller functions.
You would have a function called Age() which would be called everytime you want to access a persons age. The performance impact should be negligible, however if you wanted to optimise you could use lazy loading.
As for method size, 99.999% of the time there is a way to split it up into smaller methods. If you know how to do it properly it will always make the code more maintainable and neater.
|
|
|
On June 15 2014 23:42 Nesserev wrote:Show nested quote +On June 15 2014 19:21 sluggaslamoo wrote:
You would have a function called Age() which would be called everytime you want to access a persons age. The performance impact should be negligible, however if you wanted to optimise you could use lazy loading. In my opinion, storing age is rather redundant (if you already have the birthdate), and potentially 'dangerous'. Storing age might actually not be a good idea, since age is based on the difference between the current date and the date of birth, and the current date changes every day. Imagine if the age-variable of a person is initiated the day before his birthday... the next day his age won't be correct anymore. Of course, you can have mechanisms in place to keep track of whether or not the age is still correct, but that would totally negate the advantages of 'lazy evaluation'.
Nobody says that you would store age. If you already store the date of birth, you could calculate age based on a somehow obtained "now" value. Whether you can get your hands on such a "now" without causing any problems depends on various circumstances.
|
|
|
On June 16 2014 00:21 Nesserev wrote:Show nested quote +On June 15 2014 23:50 spinesheath wrote:On June 15 2014 23:42 Nesserev wrote:On June 15 2014 19:21 sluggaslamoo wrote:
You would have a function called Age() which would be called everytime you want to access a persons age. The performance impact should be negligible, however if you wanted to optimise you could use lazy loading. In my opinion, storing age is rather redundant (if you already have the birthdate), and potentially 'dangerous'. Storing age might actually not be a good idea, since age is based on the difference between the current date and the date of birth, and the current date changes every day. Imagine if the age-variable of a person is initiated the day before his birthday... the next day his age won't be correct anymore. Of course, you can have mechanisms in place to keep track of whether or not the age is still correct, but that would totally negate the advantages of 'lazy evaluation'. Nobody says that you would store age. If you already store the date of birth, you could calculate age based on a somehow obtained "now" value. Whether you can get your hands on such a "now" without causing any problems depends on various circumstances. Storing the value is part of 'lazy loading', which is what sluggaslamoo recommended as a optimization... (I did use the term 'lazy evaluation' instead of 'lazy loading' in my answer... will fix that)
But he suggested it only if you really cannot stand the loss of efficiency that comes with recalculating that value. Sometimes you need to make such a trade-off.
|
|
|
On June 16 2014 00:46 Nesserev wrote:Show nested quote +On June 16 2014 00:24 mcc wrote:
But he suggested it only if you really cannot stand the loss of efficiency that comes with recalculating that value. Sometimes you need to make such a trade-off. What trade-off is there to make, when one option is always right, and the other one is easily wrong? Seriously, two people in a row that don't bother to read what I pointed out?
Always calculating the value actually has costs you know. So if those costs are too big for your particular scenario (not likely in the case of Person class, but possible) you might want to sacrifice the safety for the efficiency.
|
Well, I did miss the lazy loading part. My bad. I wouldn't even consider that though. That's the kind of optimization that would pretty much never improve performance, considering how fast the calculation is.
|
On June 16 2014 01:02 spinesheath wrote:
Well, I did miss the lazy loading part. My bad. I wouldn't even consider that though. That's the kind of optimization that would pretty much never improve performance, considering how fast the calculation is.
It would, but the exact amount would depend on what exactly are you calculating. On one hand you have boolean test and a retrieval of int/struct. On the other hand you have date subtraction, which is extremely annoying operation if you are not dealing with pure ticks1 - ticks2 scenario.
But I agree that it makes no sense in nearly any practical scenario that i can conceive of.
|
|
|
On June 16 2014 01:48 Nesserev wrote:
Sacrificing safety for efficiency, is Machiavellian logic. What're you going to do with all those ticks that you saved if you're not even sure if you're working with the information that you want?
If you're concerned about efficiency on a certain level, but 'solving' that efficiency problem could possibly compromise the correctness of the information that you're working with, then it's better to try to solve that efficiency problem on a different level within your code structure: maybe the code on a lower level can be made more efficient, maybe the code on a higher level can minimize your efficiency concern (f.e: calling getAge() once, and storing it in a variable; instead of calling getAge() multiple times within the same runcycle). Otherwise though luck.
Efficiency is only your prime goal, when you're working with lossy information, like livestreams, or when speed is critical, and you can assure that the 'loss of precision' of information has no impact.
No. It is not either or. It is a tradeoff on a continuous scale. The code that uses the lazy evaluation can and most likely will be as correct as the one without. It just won't be as elegant and thus more bug-prone. That is the trade-off. It is not between efficiency and correctness, it between efficiency and robustness/readability/being error-prone. And sometimes you need to take that trade-off. You are not saying anything that was no accounted for in my previous post, since I just claimed that there are situations where you need to make that trade-off.
|
|
|
On June 15 2014 23:42 Nesserev wrote:Show nested quote +On June 15 2014 19:21 sluggaslamoo wrote:
You would have a function called Age() which would be called everytime you want to access a persons age. The performance impact should be negligible, however if you wanted to optimise you could use lazy loading. In my opinion, storing age is rather redundant (if you already have the birthdate), and potentially 'dangerous'. Storing age might actually not be a good idea, since age is based on the difference between the current date and the date of birth, and the current date changes every day. Imagine if the age-variable of a person is initiated the day before his birthday... the next day his age won't be correct anymore. Of course, you can have mechanisms in place to keep track of whether or not the age is still correct, but that would totally negate the advantages of 'lazy loading' over a simple function that calculates the age (which will always be correct).
Wow trust the programming thread to completely take me completely out of context. 
On June 15 2014 19:21 sluggaslamoo wrote:
You would have a function called Age() which would be called everytime you want to access a persons age. The performance impact should be negligible, however if you wanted to optimise you could use lazy loading.
As for method size, 99.999% of the time there is a way to split it up into smaller methods. If you know how to do it properly it will always make the code more maintainable and neater.
This is extremely vague upon rereading actually, sorry. It makes more sense if you read the post above it which talked about writing a getter, I removed the "get" and implied that age would be calculated every time, and yes most of the time it is not necessary to store age.
BUT IF (A BIG IF) performance is an issue!!!! for example if you are working on a database warehouse or caching system on a site that uses a ton of sorting and recalculating with millions of users, then you could lazily evaluate it.
Sorry for providing alternatives jeez 
Cheers mcc for covering up for me though.
On June 16 2014 03:38 Nesserev wrote:Show nested quote +On June 16 2014 02:33 mcc wrote:
No. It is not either or. It is a tradeoff on a continuous scale. The code that uses the lazy evaluation can and most likely will be as correct as the one without. It just won't be as elegant and thus more bug-prone. That is the trade-off. It is not between efficiency and correctness, it between efficiency and robustness/readability/being error-prone. And sometimes you need to take that trade-off. You are not saying anything that was no accounted for in my previous post, since I just claimed that there are situations where you need to make that trade-off. Ow... I think we were discussing two different things in the end. You were focusing on the fact that you sometimes have to make the trade-off between efficiency and code clarity. I was talking about that one shouldn't take the more 'efficient' way, if it could lead to errors due to the chosen strategy, like the 'lazy loading' of age example.
Only in a utopian world will you be able to write code while not worrying about performance. If you work for a site with tonnes of users, you will have to make "sacrifices" sometimes.
Yes in the beginning you will not pre-optimise, but after load testing if you know for a fact that the new feature you coded will not fly in production you will have to add extra code to optimise it. Yes it makes the code more complex, and harder to maintain, but its better than a site that doesn't run.
Ops can also be stubborn or lazy as hell too, sometimes they can't just boot up more powerful servers even though it would be cheaper overall because it means talking to the higher-ups for a bigger budget. But sometimes the thing you wrote is so slow, that its worth sacrificing a days work to make the whole site run faster.
Yes this probably wouldn't apply to a method like Age(), but definitely database and sorting algorithms sometimes end up being more complicated than necessary purely for performance reasons. Especially with mapped relational database libraries, they are less than ideal when it comes to efficiency.
|
I tried learning Python on whatever sites were on the first page of Google. I spent a couple hours every day for 3 weeks and never really got to a point I could do anything except add simple numbers and look stuff up in documentation. Oh, also I can put lots of semicolons and parenthesis in.
To be honest, this thread isn't at all helpful for someone who knows nothing about programming. It's really hard to look through 500 pages and try to guess which of you are bronze league retarded theorycrafters when I have no knowledge of programming to help me decide that. I don't think it was intended to be helpful to noobs, so I'm fine with that.
It seems like none of the sites are focused towards making some simple games, which is what I want to do with it. If I could get to the point where my drawings are up on the screen, I think that might motivate me more. At this point, I don't know if it would be better to keep slamming my head into the wall trying to figure it out or just give up and find some random nob to work with.
|
|
|
|
|
|
EPT
