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 9 years ago.
Improve this question
What are the best practices for separating data in different classes? Not just objective c, but programming in general.
For example, if someone was making a game like angry birds, how one manage classes?
Would you have a separate class for just the projectiles (in angry birds case, the birds) and have different classes for the targets, music and images, etc?
There is no simple answer to this. You first need to really understand, deep in your soul, how object-oriented programming works and what it represents. Then you need to make your own decisions based on that understanding and your understanding of the problem at hand.
I've seen many "cookbook" applications of OO and MVC and the like that are terrible, even though the writers dotted all the i's and crossed all the t's and their college professors would have given them an A+ on the project.
But in general I'd probably have a common superclass (with several subclasses) for entities that represent visible, movable objects, but probably not use that for music, eg.
not even data but your functional approach must be modular. create as many smaller components in terms of classes and define their behavior as methods and set the interaction between them through the Game Manager/Logic control system that you design for your game...
Best of luck..!!
Related
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 6 years ago.
Improve this question
How Composition is a lesser principle level, than Inheritance? One always has to consider Composition over Inheritance, but there is no mention of Composition in the four major OOP principles. What is the reason behind this? Are they not at the same level?
Composition is a lower-level and a much older concept than inheritance; it comes from the analysis-synthesis approach which basically states that things are either composed of other things or trivial (atomic). It was first introduced back in ancient Greece as a general approach to understanding things.
Composition is not specific to OOP, e.g. in plain C, which is far from being OO, structs are authored using composition, likewise in functional programming functions are composed of other functions, though the nature of composition is totally different in these two examples.
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 6 years ago.
Improve this question
I'm almost new to programming and I came to this question that:
why should object carry code along with data? isn't packing data enough?
For example:
Instead of having 5 employee objects that each has a getDataOfBirth() method (consuming more memory), have a single method in global space and have 5 object with only attributes(smaller objects).
Am I getting something wrong? Is my question even considered general and possible to be occurred in every newbie's mind?
The linguistic aspect of it:
This is an idea that OOP skeptics have been talking about for a long time, but it's more of a matter of preference I would say. If you are new to programming and already are thinking about these things, then maybe functional programming would make a lot of sense to you.
The memory aspect of it:
The functions are typically not stored inside the objects, so OO objects that have a lot of functions do typically not carry those functions around. This is however an implementation detail but most OOP languages should be thought of like that.
Especially in the case of natively compiled languages like C++, the code and the data will be separated into different memory areas altogether and will not really mix. That is also a bit of an implementation detail but all mainstream operating systems, as far as I know, will allocate memory with code separated from data. The functions of a class will be allocated in one area and the data of the objects in another, and normally all objects of the same class will use the same functions.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
I'm currently developing a school project and we are instructed that we are required to implement Object-Oriented Programming concepts in our software. But I don't want to implement it just by simply inheriting this class to that class and overriding this method to implement its own functionality and so on. Though it is still acceptable but I want to do it differently. By differently, I mean by using design patterns. I'm trying to understand it one by one and I noticed that some of them are very useful(Builder, Memento and Adapter). But the problem is there are so many of them and if possible I want to put/implement it all(those 3 design pattern). Is it okay if I do that? Would it mess up the project as a whole?
As always: It depends.
Overusage of patterns on small and simple bits of code can obscure the code. But it can also make it more clear.
Don't use patterns wherever possible. Use them when it serves a purpose. Every pattern has its purpose and if you can't find that purpose in your code, you shouldn't rewrite it to match a pattern. Try to keep your code a) maintainable and b) easy to read. If a pattern fulfills these criteria more than your approach without patterns: go for it.
You can have code with dozens of patterns and code with none. In both cases it can be the ideal choice.
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
I always hear that we need to encapsulate whenever we write object-oriented code. If I'm the only developer on a project, do I still need to use encapsulation?
One way to put an answer: Encapsulation, conceptually, exists for writing better, safer, less error-prone code. It doesn't exist, primarily, to facilitate teams working together on code (that might be a side effect, but that's not the purpose).
So the goods that encapsulation seeks to foster scale from one coder to many coders, and they are goods that do not really have to do with the number of coders, although those goods may find stronger expression the larger the project and teams are.
Encapsulation is there for a reason.
Someone has to maintain and manage your code after you are done, right? What if the project gets bigger and you get team members?
So, the answer is "yes", it is always best to use encapsulation whenever possible.
The fact you are asking this question makes me wonder you actually did not get the actual value of encapsulation as a means to reduce and thus deal with complexity.
My theoretical computer science professor used to tell me that in the end, if you think at the whole binary representation of a program, any program is just a number. Very big indeed but, only a number. And that is true, any other construct we use but 0 and 1 (i.e. C++, Java, Python, functional programming, object oriented programming, aspect oriented programming, etc..) is just because of the fact we need more abstract means to get the one number we need.
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 6 years ago.
Improve this question
I have a class called 'Inventory' that has two subclasses, 'Drink' and 'Condiment'. They are a part of a software system being developed for use in a hot drinks vending machine. Note that this isn't really going to be implemented, rather it is a piece of coursework for my Software Engineering class. Anyway, I'm having trouble deciding what stereotype to apply to 'Inventory', as I can see it having aspects of both a control class (managing the drinks and condiments during a transaction), and of an entity class (noting the quantities of each item in its subclasses, but it also is the sole manager of the water water levels, as hot water is common to all drinks dispenses from this machine).
I'm basically looking for some guidance on how to classify this class. Thanks a lot.
You might consider that since you are unsure how to classify it, perhaps you could design separate control and entity classes. First rule of software engineering: if the design feels wrong then it probably is.
Come to think of it, the zeroth rule is: know when to ignore the other rules, especially the ones about stereotypes and design patterns.
I vote for entity class -- Having inventory is not the same as controlling inventory.