Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
I am looking for something like Java annotations (a way to mark a field or a method with metadata) in Objective c, but i can't find anything that is really a surrogate of this Java Feature.
Is there a way to achieve the same result of a Java annotation in Objective-C ?
Basically in the actual situation i'm trying to mark some fields in a class that i want to export with a serializer, i want to mark all fields in the class that have to be exported or serialized ...
Is there some other way to mark those fields ?
I think you are probably looking for : ObjectiveCAnnotate
Officially, there is no java-like annotation support in Objective-C. But there is a possible workaround to achieve this goal. Use formatted comments as annotation, then write a parser to parse those comment annotations and save them as a file from which you can read the annotations at runtime.
I have implemented a project named ROAnnotation which use this method to provides runtime java-like key-value pairing annotation at class/method/property for Objective-C. I think that is what you need.
ROAnnotation on GitHub
The most common way to provide meta data about a class (and its instances) seems to be to provide a class method which returns the information.
In your case, an array with the names of the properties to serialize, for instance.
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 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 1 year ago.
Improve this question
I'm looking for a practical answer here, I understand Rust approach to OOP, composition over inheritance, writing traits to reuse code and all that jazz.... which is all fine if I had full control of the code and I could have chosen to write everything accordingly, but I'm stuck with the following scenario:
I'm trying to use cursive's TableView, which implements the View trait, and therefore its method on_event. I want to handle more events that those that come with the TableView implementation, but I want everything else, including the events that TableView already handles, to remain the same.
Since I've done OOP for the best part of 25 years, the natural thing for me to do is to extend TableView, implement on_event and call super.on_event where I see fit. This is not possible in Rust, as far as I understand.
I could have my own MyTable struct, which contains a TableView struct, implement the View trait on MyTable, and for every method just call the same method in TableView. I reject this as the proper solution, it can't be...
What's the closest I can get to OOPs super paradigm, or alternative, what is the Rust way of doing this without having to write a lot of useless code that just proxies calls to an inner struct of the type that I'm trying to extend?
Edit: For more detail on exactly what I want to accomplish please check this other question.
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 2 years ago.
Improve this question
Other than the fact that the compiler automatically generates certain functions for Data Class, what is the fundamental difference between them?
In Kotlin, classes declared with the data class keywords simply get some extra methods generated:
equals
hashcode
toString
copy
componentX
Declaring a regular class and defining these methods manually yields exactly the same thing. There is no other difference at bytecode level.
You do however have some extra limitations (no non-property constructor arguments, limitations on inheritance...), but these are just compile-time limitations so that the generated methods behave in a predictable/non surprising way.
The official doc covers everything in detail about them.
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 6 years ago.
Improve this question
If I have many classes which are pretty similar with each other then, does making them inherit from an abstract class a good option?
Only if they are a true abstraction in the Dog is an Animal kind of sense. Stuff on your abstract classes must make sense to all derived.
Otherwise you risk using your base class to sort of import an API. Although you see some frameworks do this, without deliberate design you are usually better off extracting the commonality out to shared dependencies which all the classes commonly use.
Abstract classes that no client code directly references or uses is typically a sign you may be running off track.
Absolutely. Though I would use an interface/protocol where possible. They're more flexible, as they give you the freedom to inherit another class.
The best choice depends on the nature of your classes, and what their duplicated code is.
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 5 years ago.
Improve this question
Hey,
If my application is called "Media Player", is it a best practice to name classes: MPSong, MPSinger, MPAlbumsViewController ... ?
Apple's Coding Guidelines for Cocoa has lots of advice along these lines.
In short, using a prefix for class and protocol names is encouraged, especially if you're developing a framework. However, Apple already uses the MP prefix for its MediaPlayer framework on the iPhone, so you probably want to pick another.
All capital two-letter prefixes are reserved by Apple, so you shouldn’t use those. But otherwise there is no definite answer to this question - it’s a matter of personal taste. I personally use a prefix for library classes but not for application classes.
I don't know if the way I name classes is a best practice or not, but if I have a class that is unique to the project I just give it a meaningful name and start with a capital letter. However if it is a class that I intend to reuse I may give it a prefix like the initials of my company or myself so I see the class is meant for reuse.
Another reason for a prefix would be if you have the same name because of similar titling in the same project but have different functionality and run the risk of becoming confusing. For example if you decide to make a class called state as in the state in which you live. Then you wish to create a class called state meaning the current state of you application. It would be a good idea to use a prefix like ADState and APState (AD for address and AP for application). In other frameworks they have namespaces that do the same job.