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.
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 1 year ago.
Improve this question
While searching on the internet for information I found it difficult to get a good understanding of which approach should be taken.
One concern is that Util or Helper class is considered an antipattern because it often violates Single Responsibility Principle.
Yet Util or Helper classes are still widely used.
Are there any good reasons to prefer one or another?
This question is probably too opinion-based…
But in my experience, most of the utility/helper methods I used to write in Java were related to a particular class or interface: I had a load of String- and char-based methods, a load of methods that used a Collection or List or array, a load of methods for handling Components and Frames and other Swing classes, and so on. I wasn't thinking of them as extension methods when I wrote them (mostly long ago!), but in hindsight that's how they seemed to go.
So when converting things to Kotlin, almost all of my utility methods fell out as top-level extension methods. I didn't initially intend that, but it seemed the most natural way.
And I expect that will apply to the majority of helper and utility methods. I'm sure there are cases where a utility class is more appropriate — but in my experience those cases are pretty rare.
You should also consider methods in companion objects; that's the most natural place for factory methods, and for other ‘static’ functionality that's closely related to a class without fitting into a normal instance method.
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 7 years ago.
Improve this question
What is the current state of serialisation-to-binary in Rust?
I have some large (1-10MB) data structure to be sent across a network, and don't want to encode them as JSON or hex (the two serialisers I have found).
I have found #[repr(packed)]. Is this what I should use, or is there something more portable?
#[repr(packed)] only makes your data small. It does not offer any format guarantees or serialization help.
You have a few choices here (ordered by my opinion from best to worst solution):
You can use the Cap'n proto implementation for Rust
https://github.com/dwrensha/capnproto-rust
It's not really serialization, more of a forced format for structs that are then sent over the network without any conversion
fast
You could write your own Serializer and Deserializer.
you have full control over the format
runtime overhead for every single datum
you need to implement lots of stuff
You can transmute your structs to a [u8] and send that
probably the fastest solution
you need to make sure that the compiler for the program on both sides is exactly the same, otherwise the formats don't match up.
Someone evil may send you bad data. When you transmute that back, you get buffer overflows and stuff
references in your data-structure will cause wild pointers and undefined behaviour
Don't use references
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I've been reading Wirth's books on Oberon--or at least trying to--and I'm hitting a mental road block when it comes to figuring out what is going on regarding object oriented programming in Oberon.
I know his method is supposed to simplify object oriented programming by avoiding "standard" OOP syntax, which he labels a perpetration, as if it was somehow criminal, and maybe I'm just too rooted in class, method, etc... kind of thinking, but can someone translate Oberon's method into standard OOP language, or at least conceptually explain it.
You may get some insight by comparing Ada's tagged type, examined in Ada 95 Rationale: II.1 Programming by Extension, with Oberon-2's type tag, discussed in Object-Oriented Programming in Oberon-2: Run-Time Data Structures, cited here. Both use a record structure with hidden type information to implement inheritance and polymorphism. See also A Comparison of the Object-Oriented Features of Ada 95 and Java, cited here.
Addendum: So are they simply associating procedures with records?
An Oberon record type encapsulates both procedures and data, in a manner similar to the object type in Object Pascal. An Ada tagged record encapsulates the data, while the enclosing package encapsulates the subprograms and record.
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 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..!!