This question already has answers here:
VB.NET What is the purpose of a class or module?
(7 answers)
What's the point of OOP?
(45 answers)
Closed 8 years ago.
I understand how to create a class. I understand how to work with it in normal situations. However, I don't see the point of the reason. Can someone give clarification?
Well the point is to make coding more manageable. easier to add and ASSOCIATE functions, properties attributes etc than individually coding them as separate entities.
For instance you write functions to change system sound, one to increase it, other to decrease it and third to mute it. In non-OO languages they would literally be like Increasesoundfunc, Decreasesoundfunc and mutesoundfunc. while in OO they'd be like Soundclass.inreasesound, Soundclass.decreasesound ,Soundclass.mutesound . Horrible example, but you get the point.
Return to the Basics... A Class supposed to be a representation of an object from the real live, most of the time this is true, maybe its only how the computer its able to understand us.
Something its true about the classes: everything, every system, dll, framework, control, etc, etc, was made from a lot of classes.
hope it help you.... :)
Related
This question already has answers here:
Why use inheritance at all? [closed]
(13 answers)
Closed 7 years ago.
What is main purpose of inheritance in OOP? i'm new in programming but I think maybe could be code reuse, are there more purposes or a more important purpose?
The main purpose of inheritance in Object Orientated Programming (OOP) is to give the user ability to change the behavior of the libraries, without actually changing already working and debugged code.
Changing other people's code always has a risk of introducing bugs because you may not fully understanding how the code works. In OOP, the user inherits the object and implements the behavior changes or new features with his own code, separate from the original code.
This way if there are bugs, the user needs to debug and fix only his own code, which is of course an easier task.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've been developing in Objective-C for a long time, mostly games, and lots of people have commented that I frequently use global variables. For example, in my .m file before the #implementation I mostly have:
BOOL X=0;
int y=1;
NSString *ran;
.
.
.
Now, I know I have to use properties, but I've found it much clearer for me to use this global variable, and I'm keeping them safe.
Except for the fact that it is not object oriented and/or not acceptable, does it affect any other facet of my app, like processor operation?
In my games I have something like 40 booleans in 1 class that are shared by almost ALL methods. I find it almost impossible to write getter/setter, or use properties for all of them, and I am comfortable with my way. But is it so wrong?
Is there another way to deal with many booleans that change in real time frequently, and are shared by all methods?
Is this so terrible to use globals? (I dont need to be considered as good Objective-C user…)
Global variables are generally considered bad practice because they lead to coding problems in the long run. If you find yourself able to maintain your code, then go ahead.
But eventually, you'll work on a project big enough where it will cause problems. Why not learn to get along without them now on the easier projects?
ObjC's not much different from its relatives in this regard.
The problem is that the program is very difficult to use in other contexts. That is, it can be a better choice to reimplement a program entirely rather than making the one with 40 globals reusable (and retesting everything).
40 Booleans for one class is also a llllloooooooot. Read your code -- look for patterns. Make smaller, more easily reusable implementations if you want to get away from the globals. Many devs consider them huge maintenance pains (war stories!). I could easily see myself having trouble trying to understand the program flow of such a program.
Even packing your 40 bools into a C struct and putting an instance of that struct in your ObjC class will be one huge improvement which is simple to implement.
If you have had no problems maintaining these programs, consider it a blessing! …but it will not be a favorite design for other people that will read, extend, or maintain said program.
As with most development practices, global variables have their place, BUT they reduce how refactorable, readable and debuggable the code is. Imagine the following scenarios:
a program that has an error in one function, but the error is caused by a global variable. Which other location produced the bad value? It's nearly impossible to tell.
someone who didn't write the code wants to change something, but has no idea where the global values are coming from. The way to figure out how the program works is to understand EVERY place the global variable is used. This is much more difficult than if you had simply encapsulated your functionality appropriately.
one piece of code is repeated over and over again (every method has access to your global so they all use it, but in just barely different ways). Requirements change and you need to change how that works slightly. You now have to change 143 different places in the code. (one time I had to do this was when the software changed from the English system to metric. 30 different code locations all using DIFFERENT conversion values to do the same thing)
On the other hand, if you have performance issues, there are times when having a global will speed things up, but it's much better to code for readability, refractorability and debuggability and then refactor if necessary for performance.
This question already has answers here:
How does a delegate work in objective-C?
(5 answers)
Closed 7 years ago.
I have several documents and the videos on Stanford that explain it, but I still fail to get my head around what Delegation actually is.
I'm trying to picture them in a real use so I can relate to it.
Are the similar to event hooks? I've used event hooks in some PHP frameworks.
Sometimes I need things explaining in lamans terms before I can go "ah ha, I get it".
Thanks.
In software engineering, the delegation pattern is a design pattern in object-oriented programming where an object, instead of performing one of its stated tasks, delegates that task to an associated helper object.
Read this wikipedia article in detail.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
In short I'm creating a 2D mmorpg and unlike my last "mmo" I started developing I want to make sure that this one will scale well and work well when I want to add new in-game features or modify existing ones.
With my last attempt with an avatar chat within the first few thousand lines of code and just getting basic features added into the game I seen my code quality lowering and my ability to add new features or modify old ones was getting lower too as I added more features in. It turned into one big mess that some how ran, lol.
This time I really need to buckle down and find a design that will allow me to create a game framework that will be easy to add and remove features (aka things like playing mini-games within my world or a mail system or buddy list or a new public area with interactive items).
I'm thinking that maybe a component based approach MIGHT be what I'm looking for but I'm really not sure. I have read documents on mmorpg design and 2d game engine architecture but nothing really explained a way of designing a game framework that will basically let me "plug-in" new features into the main game.
Hope someone understands what I mean, any help is appreciated.
If you search for component-based systems within games, you will find something quite different to what you are actually asking for. And how best to do this is far from agreed upon just yet, anyway. So I wouldn't recommend doing that. What you're really talking about is not really anything specific to games, never mind MMOs. It's just the ability to write maintainable code which allows for extension and improvements, which was a problem for business software long before games-as-a-service became so popular and important.
I'd say that addressing this problem comes primarily from two things. Firstly, you need a good specification and a resulting design that makes an attempt to understand future requirements, so that the systems you write now are more easily extended when you come to that. No plug-in architecture can work well without a good idea of what exactly you hope to be plugging in. I'm not saying you need to draw up a 100-page design doc, but at the very least you should be brainstorming your ideas and plans and looking for common ground there, so that when you're coding feature A, you are writing it with Future feature B in mind.
Secondly, you need good software engineering principles which mean that your code is easy to work with and use. eg. Read up on the SOLID principles, and take some time to understand why these 5 ideas are useful. Code that follows those rules is a lot easier to twist to whatever future needs you have.
There is a third way to improve your code, but which isn't going to help you just yet: experience. Your code gets better the more you write and the more you learn about coding. It's possible (well, likely) that with an MMO you are biting off a lot more than you can chew. Even teams of qualified professionals end up with unmaintainable messes of code when attempting projects of that magnitude, so it's no surprise that you would, too. But they have messes of code that they managed to see to completion, and often that's what it's about, not about stopping and redesigning whenever the going gets tough.
Yes, I got what you want...
Basically, you will have to use classic OOP design, the same one that business software coders use...
You will first have to lay out the basic engine, that engine should have a "module loader" or a common OOP-style interface, then you either code modules to be loaded (like, as .dlls) or you code directly within your source code, using that mentioned OOP-style interface, and NEVER, EVER allow a module to depend on each other...
The communication, even inside your code, should be ALWAYS using a interface, never put "public" vars in your modules and use it somewhere else, otherwise you will end with a awfull and messy code.
But if you do it properly, you can do some really cool stuff (I for example, changed the entire game library (API that access video, mouse, keyboard, audio...) of my game, in the middle of development... I just needed to recode one file, that was the one that made the interface between logic, and game library...)
What you're thinking about is exactly what this article describes. It's a lovely way to build games as I have blogged about, and the article is an excellent resource to get your started.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
Stackoverflow users,
How do you keep yourself from creating large classes with large bodied methods. When deadlines are tight, you end up trying to hack things together and it ends up being a mess that needs refactoring.
One way is to start with test driven development and that lends itself to good class design as well as SRP (Single Responsibility Principle).
I also see developers double clicking on controls and typing out line after line in the event method that gets fired.
Any suggestions?
I guess it depends on your internal processes as much as anything.
In my company, we practise peer review, and all code that gets comitted must be 'buddied in' by another developer, who you have to explain your code to.
Time constraints are one thing, but if I review code that has heinously long classes, then I won't agree to the check-in.
It's hard to get used to at first, but at the end of the day, it's better for everyone.
Also, having a senior developer who is a champion for good class design, and is willing and able to give examples, helps tremendously.
Finally, we often do a coding 'show and tell' session where we get to show off our work to our peers, it behooves us not to do this with ugly code!
Use a tool like Resharper and the Extract Method command.
Long classes is one bad code smell of many possible.
Remedying overly large classes by creating lots of small ones may create its own problems. New engineers on your project may find it difficult to follow the flow of the code to work out what happens where. One artifact of this problem can be very tall call stacks, execution nesting through many small classes.
Another suggestion is to do only what is asked. Don't play the "What if" game and try to overdesign a solution. This has the "Keep it simple, stupid" idea behind it.
We're a java and maven shop, and one of the...I guess you could say forensic methods we use are the excellent FindBugs, PMD and javancss plugins. All will give warnings about excessive length in a method, and the cyclomatic complexity calculations can be very eye opening.
The single most important step for me to avoid large classes that often violate SRP was to use a simple dependency injection framework. This freed me from thinking too much about how to wire things together. I only use constructor injection to keep the design free from cycles. Tools like Resharper help to initialize fields from constructor arguments. This combination leads to a near zero overhead for creating and wiring up new classes, and implicitly encourages me to structure behavior in much more detail.
This all works best if data is kept separate from behavior, and your language supports constructs like events that can be used to decouple communication that flows in the downward direction of the dependency graph.
use some static code analysis tools in your automated builds and write/configure/use some rules so that for example someone has to write a justification when he/she breaks it..