Omgnow I can understand the power of a simple question
![]()
Omgnow I can understand the power of a simple question
![]()
When you 're trying to help somebody in the newbie section, don't forget that he is a newbie. Be specific and give examples.
You might be asking at this point why it matters WHERE the change is happening and what KIND of change is required. For example, why is it better to subclass an interface to get new behavior rather than alter an existing one.
This is sort of why I suggested looking these things up. It's a long discussion and at this point I have to assume certain premises in order to reasonably critique design decisions.
What it boils down to though is that experience shows that some types of changes are easier than others. It is easier to write new code than to maintain legacy code. People everywhere who have to maintain long existing projects lament at the task of altering existing code. Every time you do it you have to make sure you haven't broken anything, etc...etc... You have to learn WTF the person who wrote it was thinking (even when it's yourself and you only did it two weeks ago, not 10 years). This is true because the human brain is simply incapable of tracking the enormous complexity of even the simplest programs; it can only do so in layers and abstractions. Thus it's always easier just to write new code, so the object is to make that what you are doing as much as possible.
So, years and years of experts shooting themselves in the face over and over and over again, and finally figuring out some semblance of a system of criteria that works has resulted in these principles. It's well worth becoming familiar with them and getting used to thinking about them as you write and critique your own designs. Unfortunately, though this is probably the single most important skill for a developer to have...I don't know of any school that teaches it.
It's a cost benefit always. You can't be open to all extensions and closed to all changes. Sometimes you just didn't account for what the user wanted and you are forced to change something. That doesn't negate the principle though and in the case when you CAN see it, and can easily solve the problem without closing those paths of extension, you nearly always should (I'm tempted to omit 'nearly').
Of course, a newbie is not going to get it right in the beginning. Just like everything else. I would say though that these principles and issues should really be TOP on the concerns of all new developers to figuring out and becoming proficient in.
I wouldn't worry if you didn't understand everything I said. The only thing I would worry about if I were you is two things:
1) if you can get the behavior you want without having to change set_m, do it that way.
2) Go search the web for "Principles of Object Oriented Design", "Robert C. Martin", and "Open/Closed Principle" and just keep reading about that stuff over, and over, and over...for the rest of your career. It'll sink in in parts, just like coding in any particular language/API, and you'll be a cut above a LOT of people in the field.
This rude guy who doesn't want you to answer his questions.
Note: An "expert" here is just someone that's posted a lot.
"The fact of where you do the encapsulation is meaningless." - Qt Certified Developer and forum moderator
Bookmarks