Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
What does this line means "Swift doesn’t require you to create separate interface and implementation files for custom structures and classes."
link
It is referring to the old C-style way of separating interfaces and implementations in separate .h and .c (.m for ObjC/.mm for ObjC++) files.
In Swift, you no longer need to deal with this - interfaces are generated by the compiler.
For example:
public class Loader {
private let resource: URL
init(resource: URL) { self.resource = resource }
public func load {
//..
}
}
Generates an interface (effectively, an API) with only the public members exposed:
public class Loader {
init(resource: URL)
public func load()
}
The key here is, that there no longer needs to be a separate file maintained by the developer. The interfaces are generated (or not) based on the access control levels defined on your types.
In objective C you have different files for interface called .h file and for implementation of that interface you have .m file
but in swift you have .swift file in which you implement the functionality so you don't need to create two separate files in swift
thats what docs are referring to ... hope it helps
happy coding =)
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 2 years ago.
Improve this question
Background
When developing an application, my approach (rightly or wrongly) is to separate the logic into a Framework (Kit)
The reason(s) for this are fairly straight forward ..
• I like being able to test the logic in isolation
• I like that it forces me to forget about the UI and any UI assumptions
• I like that I am free to create the app using a separate UI .. depending on device (iPhone, Watch .. Apple TV .. Command Line Utility)
The Problem
because I like the logic in a separate framework .. I have introduced a complexity in terms of access modifiers (Public, Internal, Private) for classes, structs, enums, methods, properties.
What I have most trouble with is properties (and properties of Entities in particular)
I prefer not to expose the setter to the consumer of the Framework (i.e. the UI Application)
Within a Module I would typically use the.
private(set) var nameOfProperty
approach.
However this isn’t an option to me in entities of a framework.
So for a framework, I would much rather return a Protocol describing the interface of an Entity
.. i.e. it’s writable properties, it’s read-only properties and it’s accessible methods
We (Swift Developers) have been encouraged down the route of naming Protocols according to a behaviour .. however,
.. for example, a Football/Soccer Team Selection framework I wouldn’t want to be passing back and forth something that conforms to ‘Player-able’, ‘Manager-able’, ‘Fixture-able’
.. I want to pass back and forth a ‘Player’, ‘Manager’, ‘Fixture’ (as the consumer would rightfully expect)
Question
What should I be naming my Entity (assuming it conforms to a commonly known as Protocol) ?
Understandably, we can not have a Protocol called protocol Player and class Player
Some Suggested Ideas
Idea 1: Use underscoring within the framework (my most likely approach)
e.g.
public protocol Player {
public var name: String { get }
}
public class _Player: Player {
..
}
Idea 2: Don’t use protocols, but use computed properties instead (not preferred)
e.g.
public class Player {
private var _name: String
public var name: String {
get {
return _name
}
}
Idea 3: Don’t use protocols, because you're the only consumer then trust yourself and make everything public 🤪
e.g.
public class Player {
public var name: String
}
Idea 4: Use a substitute name within the framework (a bit like underscoring)
e.g.
public protocol Player {
public var name: String { get }
}
public class PlayerEntity: Player {
..
}
or
public class PlayerImpl: Player {
..
}
or
public class PlayerObj: Player {
..
}
Personally, I'd go with Player: PlayerProtocol, unless you are going to be using the protocol much more often. There are some examples of this in the standard library, such as StringProtocol and IteratorProtocol.
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 3 years ago.
Improve this question
I have a few classes i.e. User, Settings... that I use in most of my ViewControllers. Because I use them often, is it better if I have only one instance of them to use globally, or a new instance for each class?
In AppDelegate:
let user = User()
class AppDelegate: UIResponder, UIApplicationDelegate {
...
vs.
In each class:
class TimerViewController: UIViewController {
private let user = User()
For the current state being globally is better
let user = User()
but it's much better to make it a singleton
class Service {
static let shared = Service()
let user = User()
}
so not to confuse other developers when read the code won't know whether this global var is local/instance/global , so being singleton will sort this
My two cents
It is always better to declare it where you actually need instead of declaring it globally. It is good practice to limit the scope the variables that we use so that it gets deallocated and cleared from memory when its job is over. Here, it is clear that there is only one owner for that instance.
Declaring global objects will lead to maintaining global state for the instance properties and since it is open to all classes, it will not be clear which class is changing what.Here, everyone is like owner of this instance.So, It is always better to avoid it.
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
Coding to an interface is argued to be a good practice, allowing for the possibility to change an object later without affecting program behavior, but why do we need to change something if it does not have an effect? I understand the flexibility that this practice gives, I just do not understand the definition.
They mean you are able to change the implementation of that class and you will be 100% sure the rest of the program isn't broken after the change. Because you do not change a single line outside of that class implementation. Of course you can break the implementation.
Using interfaces doesn't just allow you to change the implementation of a class. It also allows you to change the class itself. Details after the break.
Interfaces also serve to reduce the mental effort needed to develop (and understand) complex code. If you can clearly define the interaction between two parts of your program then work can proceed on both parts without one knowing how the other implements the interface. This happy situation can continue until both parts are ready to be put together, when something called "integration testing" takes place.
Interface, in the sense described above, is quite an abstract concept. The signature of a function, for instance, is an "interface".
Other forms of interfaces are constructs that use the interface keyword (e.g. in Java or C#) or classes with pure virtual methods (in C++). When people say "programming to an interface" they usually refer to these constructs.
Not the best example in the world, but but suppose we have this:
interface ICooking
{
void Chop();
void Grill();
// other cooking functions
}
which is implemented by this class:
class Chef implements ICooking
{
void Chop()
{
...
}
void Grill()
{
...
}
// other cooking functions
}
And now you want to write a function that makes a steak. You will need someone to operate the kitchen (i.e. someone that implements ICooking).
You could write the function like this:
void MakeASteak( Chef ThePersonWhoCooks )
{
...
}
and call it as:
Chef Joe;
MakeASteak( Joe );
or you could write it like this:
void MakeASteak( ICooking ThePersonWhoCooks )
{
...
}
and call it as:
Chef Joe;
MakeASteak( Joe );
You should observe the following:
you call MakeASteak exactly the same in both cases
you can change the implementation of Chef::Grill and, as long as it still "grills" (e.g. you go from medium-rare to medium) you don't need to change the code in MakeASteak
This is one of the benefits of using a clearly defined interface. As long as the Grill method does what it is supposed to do, its callers don't need to know how it does it.
The second version is quite different. This is the one people have in mind when they say "program to an interface". It allows one to add this:
class HomeCook implements ICooking
{
void Chop()
{
...
}
void Grill()
{
...
}
// other cooking functions
}
and call
HomeCook AverageJoe;
MakeASteak( AverageJoe );
So, if the MakeASteak function only uses the methods defined in ICooking then not only does it not care how the ICooking functions are implemented, it also doesn't care what object implements the interface.
You can then also use complex objects:
Class ComplicatedPerson implements ICooking, IWriting, IActing, ISwimming
{
}
and use it just like before:
ComplicatedPerson person;
MakeASteak( person );
Another example would be the std algorithms that use iterators. The library writer only needs to know that the iterator "iterates" and can focus on the algorithm itself. The programmer responsible for writing the iterator code for a vector or for a set can focus on his code without having to worry about the binary search algorithm details. If both programmers do their job properly then the algorithm will be usable no matter what container provides the iterators.
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 which will contain list of two dependent classes inside it.
example
Class ActivityHolder{
private ArrayList activityList;
private ArrayList promiseList;
}
My question is how do i name the ActivityHolder class.
[Edit]
I have a class structure as above.And not the wallet and coin scenario.
Like Richard and amal pointed, the class name must be something related to its function.
If it represents a bunch of activities, so it is okay to name it Activities.
Class Activities {
private List activities; // backlog, planned, other better name (more specific)
private List promises;
}
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
This question about unit testing best practices mentions designing classes for dependency injection. This got me thinking as to what exactly that might mean.
Having just started working with inversion of control containers I have some ideas on the issue, so let me throw them against the wall and see what sticks.
The way I see it, there are three basic types of dependencies that an object can have.
Object Dependency - An actual object that will be used by the class in question. For example LogInVerifier in a LogInFormController. These should be injected in through the constructor. If the class is sufficiently high level that it requires more than 4 of these objects in the constructor consider breaking it up or at the very least using a factory pattern. You should also consider providing the dependency with an interface and coding against the interface.
A Simple Setting - For example a threshold or a timeout period. These should generally have a default value and be set via a builder of factory pattern. You can also provide constructor overloads which set them. However in most cases you probably shouldn't be forcing the client to have to set it up explicitly.
A Message Object - An object that is handed off from one class to another which the receiving class presumably uses for business logic. An example would be a User object for a LogInCompleRouter class. Here I find it is often better for the message not to be specified in the constructor as you would then have to either register the User instance with the IoC Container (making it global) or not instantiate the LogInCompleteRouter until after you have an instance of User (for which you couldn't use DI or at least would need an explicit dependency on the Container). In this case it would be better to pass in the message object in only when you need it for the method call (ie. LoginInCompleteRouter.Route(User u); ).
Also, I should mention that not everything should be DI'ed, if you have a simple bit of functionality that was just convenient to factor out to a throw-away class, it is probably ok to instantiate on the spot. Obviously this is a judgement call; if I found it expedient to write a class such as
class PasswordEqualsVerifier {
public bool Check(string input, string actual) { return input===actual;}
}
I probably wouldn't bother dependency injecting it and would just have an object instantiate it directly inside a using block. The corollary being that if it is worth writing unit tests for, then it is probably worth injecting.
So what do you guys think? Any additional guidelines or contrasting opinions are welcome.
The important thing is to try to code to interfaces and the have your classes accept instances of those interfaces rather than create the instances themselves. You can obviously go crazy with this, but it's a general good practice regardless of unit testing or DI.
For example, if you have a Data Access Object, you might be inclined to write a base for all DAOs like this:
public class BaseDAO
{
public BaseDAO(String connectionURL,
String driverName,
String username, String password)
{
// use them to create a connection via JDBC, e.g.
}
protected Connection getConnection() { return connection; }
}
However, it would be better to remove this from the class in favor of an interface
public interface DatabaseConnection
{
Connection getConnection();
}
public class BaseDAO
{
public BaseDAO(DatabaseConnection dbConnection)
{
this.dbConnection = dbConnection;
}
protected Connection getConnection() { return dbConnection.getConnection(); }
}
Now, you can provide multilple imlementations of DatabaseConnection. Even ignoring unit testing, if we assume we are using JDBC, there are two ways to get a Connection : a connection pool from the container, or directly via using the driver. Now, your DAO code isn't coupled to either strategy.
For testing, you can make a MockDatabaseConnection that connects to some embedded JDBC implementation with canned data to test your code.