Is there a standard convention for naming Model classes? I looked at Apple's conventions, but I really couldn't find an answer, if there is one. Views are usually prefixed with UI and/or contain view in the name; controllers usually post-fix "controller," but I'm not sure how to name my model classes. I've seen Manager, but usually these are singletons.
Model classes typically represent objects of the real world, so you'll just name them exactly like those, a few examples:
Car
User
Animal
House
Note that Model classes are essentially there to provide a logical component of your app's application domain.
You can give prefixes to your classes so that their namespaces don't interfere with classes that come from other projects or frameworks where they might have been named identically. Also, the prefixes that Apple uses usually indicate the framework that these classes come from (although this is not always the case), like UIViewController, UIButton, UILabel etc coming from UIKit.
Related
I've added SACalendar custom classes to my Xcode project and now when I run the app I get this log:
objc[3230]: Class SACalendar is implemented in both /System/Library/PrivateFrameworks/SAObjects.framework/SAObjects and /private/var/mobile/Containers/Bundle/Application/XXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX/MyApp.app/MyApp. One of the two will be used. Which one is undefined.
What is such SAObjects.framework? Would this conflict cause actually a problem?
Thanks
As the message says, it is a private framework (meaning that it contains stuff that does not have a public API). I think this one started shipping with iOS7.
IMO, Apple should do a better job naming their private classes, and prefix them with an underscore or something, but they don't. That framework even has classes with no specific prefix (like AceObject).
Since ObjectiveC does not have namespace support, you can (and will) get name collisions. All you can do is rename your classes that clash with system frameworks... and hope your prefix of choice is not chosen by some other framework shipped with the system.
I would advise you to rename your SACalendar class, and any other classes that cause a conflict.
If you want to know the contents of that framework, just load it and use the objc runtime to discover its properties... or use one of the many tools already available (like this one).
It seems to be this: https://github.com/nopshusang/SACalendar
Yes, it is a problem.
However, you get this problem because you and many, many other developers do not read the Objective-C's and Cocoa's naming conventions. There are typically two mistakes:
Prefixes with two letters are reserved for Apple. You are not allowed to use it. I really do not know, why do not respect this. This is the problem in your case.
Prefixes does not denote a subject, but the origin of code. Therefore extending (subclass, category) a class from Cocoa (NS-Prefix) by a third-party developer does not have the prefix NS. But you see it everywhere.
I really do not know, why it is that difficult to accept that simple rules.
Your own classes should use three letter prefixes. These might relate to a combination of your company name and your app name, or even a specific component within your app. As an example, if your company were called Whispering Oak, and you were developing a game called Zebra Surprise, you might choose WZS or WOZ as your class prefix.
As for what SAObjects.framework actually does, according to https://www.theiphonewiki.com/wiki/Siri, it contains "Resources for Siri objects".
I'm a newbie to Swift and iOS programming in general, and I'm currently getting my hands dirty building a Swift app. I have encountered this problem of where to put the Constants.swift file (which basically stores the constants used by the app), and the confusion is mainly caused by the MVC logic. I have two options that I deem somewhat reasonable.
Put Constants.swift outside of the MVC framework, so that it does not belong to any particular party. Rationale: this way it could be conveniently referenced by all the components.
Put Constants.swift in the controller. Rationale: Controller is application-specific, and so is Constants.swift. Model and View are generic and hence should not be used to store constants.
But I don't know which of the two above I should use, or if there are any better options. What do you all think?
I think you should separate the constants in the classes that have to do with them and access them like:
Configurations.Constants.width or Car.Constant.speed
You can use structs with static properties to store them.
Don't know if that is your case, and depends on the constants, but it is not common to have one file with ALL the constants of the program, or one file with constants that need to be accessed from all the other components, this could indicate a design problem. If you store them close to or in the classes related to them, you won't have a problem with Cocoa's MVC.
What are the guidelines about when it is better to nest Model name spaces and when it is better to leave them all top-level?
For instance, when I have a few classes that all have something to do with one core class (and the majority of the system only deals with that core class) then my instinct tells me to declare them as such:
CoreModel
CoreModel::DependentOne
CoreModel::AnotherDependent
Almost always this corresponding to has_many/belongs_to relationships (i'd almost consider this the next candidate for convention over configuration.)
And again, my routes often reflect this nesting:
/CoreModels/:core_model_id/DependentOne/:id
The reason I feel like I should do this is because often two component areas of the same large application may need a supporting component with similar if not identical names as other areas of the software. I feel like name spacing these dependent models (which only exist to support that core model) is the best way to go.
I'm confused because while some times doing things this way can make stuff easier (such as link_to which needs only to take the DependentOne model and will automatically route correctly) yet other items such as form_for refuse to work properly (because it doesn't route properly and if I add the CoreModel to the form_for it complains about no such route core_model_core_model_dependent_one etc....
Perhaps I haven't been clear enough and so I'll ensure I update this as requests for clarifications come in.
...the majority of the system only deals with that core class...
In that case, I wouldn't bother namespacing them.
The reason I feel like I should do this is because often two component areas of the same large application may need a supporting component with similar if not identical names as other areas of the software. I feel like name spacing these dependent models (which only exist to support that core model) is the best way to go.
Bingo - if you have name conflicts, namespacing is a good way to fix it. But, do you have that problem yet?
Namespacing prevents name conflicts, but in Rails it also introduces some gotchas and headaches and (throughout the app) quite a bit more typing. So, to me, it isn't worth it unless you actually have a name conflict.
Consider a structure like this, with your core model and many that just help it.
#Core Models
Model
Supporter
Assister
Helper
Benefactor
For most of the life of your app you may never run into a problem. If you do finally hit one, you could just do this:
AltModel
AltModel::Supporter
OtherModel
OtherModel::Benefactor
Or if it's really simple just prefixing the class name would work:
AltModelSupporter
OtherModelBenefactor
For that matter, it's probably simpler to name your core models in this way than it would be to "properly" namespace them:
CoreModel
CoreSupporter
CoreAssister
So, there are many ways to accomplish what you need, none of which suggest you should bother namespacing the core functionality of your app when you don't actually have a namespace conflict. Given the headaches you've already run into I think you'll be happier leaving the core models of your app in the top-level namespace and only nesting alternate models that actually have a conflict down the road.
A best practice in DI I've read in a few places is not to inject object B just to get at object C, but to inject C instead.
But if a single method from C is all that is required, would you just inject that method instead of C?
If so, what about if a few methods from C were required? Is there a point that it's just more convenient to pass in the full object and live with the fact that you're getting stuff you have no interest in?
Or does that point indicate that maybe class C has too many varied responsibilities and needs to be extracted into multiple smaller classes, the objects of which can then be injected without as much baggage?
Don't be afraid to state the obvious, this is all new to me.
If the dependency has (many) more methods than you care about, it's a pretty good sign that it's a Header Interface that violates the Interface Segregation Principle.
If you have control over the interface, I'd suggest splitting it up into several smaller Role Interfaces. You can still have one concrete class implementing more than one Role Interface if that makes more sense for your specific implementation.
If you don't control the design of the dependency, I'd tend towards injecting the whole interface, as it still represents a cohesive collection of behavior (even if we don't agree with the design choice of the original designer). You might need more of that behavior later on.
Heyho,
There´s a question in my mind for some time now, which hopefully can be cleared quickly by some of you:
I am a big fan of MVC, ASP.Net Mvc in my case.
What I have noticed is the hype about interfaces. Every video, tutorial and book seems to solve any kind of abstraction with interfaces. I have adapted these patterns, understood why and how and I am basically very happy with it.
But I just don´t get why interfaces are used everywhere. I´ve almost never seen some abstraction being done with abstract base classes, which I don´t understand. Maybe I miss something? I know that you can only inherit from one base class while multiple interfaces are possible. But interfaces do have disadvantages, especially when some changes need to be done, which breaks your implementations.
In my projects so far, I only used to pick interfaces for completely different classes.
For example, the whole repository pattern could be done with an abstract base class, still providing testability and exchangeability, or did I miss something?
Please point me to the part where my brain laggs :)
Interfaces are used in tutorials, blogs and elsewhere because those authors are particularly influenced by a group of methodology called "design for testability".
Primarily, design for testability school of thoughts used interface every way because they want to be able to mock any component under tests. If you use concrete class, then a lot of mocking tools can't mock those class, and hence will make it difficult to test your code.
A Story
I once attended a Java user group
meeting where James Gosling (Java's
inventor) was the featured speaker.
During the memorable Q&A session,
someone asked him: "If you could do
Java over again, what would you
change?" "I'd leave out classes," he
replied. After the laughter died down,
he explained that the real problem
wasn't classes per se, but rather
implementation inheritance (the
extends relationship). Interface
inheritance (the implements
relationship) is preferable. You
should avoid implementation
inheritance whenever possible.
While using only or mostly Interfaces does have code reuse problems(as well as eliminating nice base classes), It makes it a lot easier to do Multiple Inheritance like things. As well as having widely different implementations that will work and where you don't have to worry about the base class changing or even what it does(you do have to implement the whole thing though so its a trade off).
P.S. I think the new Go language is based on interfaces rather then inheritance(looks sort of interesting).
If the language doesn't support multiple inheritance or mix-ins abstract base classes are limited in scope compared to interfaces. E.g. in .NET if you must inherit from some other type such as MarshalByRef, you can't use an abstract base class to implement a pattern. Interfaces do not impose this restriction.
Besides the fact you mentioned that you can inherit from a single base class only (which is pretty inconvenient if you want to use an existing class that already inherits from some class with the new framework base class), you also avoid the fragile base class problem if you use interfaces instead.
Coding against interfaces makes your design more flexible and extensible. For instance, plugin frameworks and dependency injection. Without interfaces, the extensibility of it is pretty much limited.
Read about interfaces, abstract classes, breaking changes, and MVC here: http://ayende.com/Blog/archive/2008/02/21/Re-Versioning-Issues-With-Abstract-Base-Classes-and-Interfaces.aspx.
One solution that is presented there (or somewhere else on Ayende's blog) is: do use interface but also provide abstract classes. Those who case about breaking changes can base their implementations on abstract classes. Those who need power of interfaces are also satisfied. But do make sure your methods accept interfaces, not abstract classes, as input.