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
When I use protocols with structural patterns such as MVP, or VIPER I usually add protocol and class conforming to the protocol in the same file.
For example, in MVP for the View component:
file: ListViewController.swift
protocol ListView {}
class ListViewController: ListView {}
and for the Presenter component:
file: ListPresenter.swift
protocol ListPresenter {}
class MainListPresenter : ListPresenter {}
1) is adding protocols and classes (when there is only one class conforming to it) in the same file, a good practice?
2) is ok to name the file containing the view controller with its name?
3) can I name the presenter file with the protocol name or do I lack of consistency?
How would you name filenames and classes in this example?
thanks
1) is adding protocols and classes (when there is only one class conforming to it) in the same file, a good practice?
If there's only one class conforming to a protocol, I would strongly argue that you're misusing protocols. If your pattern encourages this, then I would strongly question the value of the pattern.
But putting them in the same file is fine. Placing closely related types in a single file is good.
2) is ok to name the file containing the view controller with its name?
Sure.
3) can I name the presenter file with the protocol name or do I lack of consistency?
Sure...but again, if you have a protocol that has exactly one implementation, then something is likely wrong, and you should be digging into improving that rather than filenames.
Related
This question already has answers here:
Swift extension example
(8 answers)
Closed 5 years ago.
As we have Object Oriented Programming, so we can make parent class which have all the functions those are needed for all child classes. so what is the purpose of extensions? I'm little bit confused in that question, please anyone help me.
Extensions
Adds functions to your class without subclassing, is very useful in cases where you don´t have the implementation of the class you are trying to extend, example classes that are inside an Framework or library
as is defined in https://developer.apple.com/library/content/documentation/Swift/Conceptual/Swift_Programming_Language/Extensions.html
Extensions add new functionality to an existing class, structure,
enumeration, or protocol type. This includes the ability to extend
types for which you do not have access to the original source code
(known as retroactive modeling). Extensions are similar to categories
in Objective-C. (Unlike Objective-C categories, Swift extensions do
not have names.)
Extensions in Swift can:
Add computed instance properties and computed type properties Define
instance methods and type methods Provide new initializers Define
subscripts Define and use new nested types Make an existing type
conform to a protocol In Swift, you can even extend a protocol to
provide implementations of its requirements or add additional
functionality that conforming types can take advantage of. For more
details, see Protocol Extensions.
NOTE
Extensions can add new functionality to a type, but they cannot
override existing functionality.
Extension Syntax
Declare extensions with the extension keyword:
extension SomeType {
// new functionality to add to SomeType goes here
}
An extension can extend an existing type to make it adopt one or more protocols. To
add protocol conformance, you write the protocol names the same way as
you write them for a class or structure:
extension SomeType: SomeProtocol, AnotherProtocol {
// implementation of protocol requirements goes here
}
Adding protocol conformance in this way is described in Adding
Protocol Conformance with an Extension.
An extension can be used to extend an existing generic type, as
described in Extending a Generic Type. You can also extend a generic
type to conditionally add functionality, as described in Extensions
with a Generic Where Clause.
Hope this help to clarify you
This question already has answers here:
Difference between static function and singleton class in swift [closed]
(3 answers)
Closed 6 years ago.
I have made a class that will contain all the utility methods. So, instead of making it as a singleton, I have marked the methods as static and accessing those methods by the ClassName.methodName without the need for instantiation.
Is this approach OK?
Just consider that a singleton is used in order to ensure that only one instance exists for a given class, and that there’s a global access point to that instance.
I believe that having all utility functions marked as static within a class is a good approach since, as you have stated, you will need to use ClassName.methodName in order to use them.
In addition, based on what you want to achieve and the information provided by this link, I would reassert that having a class with static methods is the best alternative.
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
Consider the following class:
template <class Endianness>
class bitcode
{};
With Endianness that could be: default_endianness, little_endian or big_endian.
The question is the following: according to C++14 and the following C++17, what is/will the best and common practices? (by common I mean those used (or which will be used) by the standard library or boost. (+ and why?)
// The enum option
enum enum_endianness {default_endianness, little_endian, big_endian};
// The enum class option
enum class enum_class_endianness {default_endianness, little_endian, big_endian};
// The class option
class class_default_endianness{};
class class_little_endian{};
class class_big_endian{};
(Note: of course the declaration of bitcode will depend on the prefered option.)
You have to choose what fits your end:
enum: It is mostly for backwards compatability.
enum class: Can only be used when you know all the tags in advance.
class: Anyone can introduce new tags and you can make the tags contain data.
enum class is most appropriate. It is a type-safe, scoped enumeration. You can compare values using the == operator, and also apply template specialization and deduction using template parameters.
enum alone is an unscoped enumeration. These are mostly considered a backward compatibility feature with C++98 and C. Values will implicitly convert to int, but those integers will be meaningless.
class alone gets you dispatch tags. Although this will work, you won't have the == and != operators, which might force you into excessive use of templates and overloads.
Another pattern to consider is the type-traits pattern: a class containing static data members and functions, so you don't have to add more template parameters.
enum class endianness {little_endian, big_endian};
class little_endian_traits {
static const enum endianness endianness = endianness::little_endian;
};
class big_endian_traits {
static const enum endianness endianness = endianness::big_endian;
};
typedef little_endian_traits default_endian_traits; // depending on platform
template< class traits >
class bitcode;
The choice is somewhat subject, but if you want to use this as a template parameter (e.g. for your bitcode class template), I'd stick with class/struct tags. This tends to make template programming simpler than mixing things templated on types with things templated on particular constant values.
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 was wondering why you cant use the static keyword in a class.
I know that you can use it in a struct but not in a class
Does anyone know why they choose for this?
And if so are there any advantages for letting static away?
It is a terminological bêtise. What Apple did was decide that you use static in an enum or struct and class in a class. In my view this was a very foolish decision, as they are exactly parallel to one another. Many people have posted on the dev forums suggesting that they just call them all static.
The outcome is a candidate for Occam's Razor: two phrases, e.g. static property and class property, or static method and class method, that mean exactly the same thing. And then they try to cover their tracks in the documentation by adding a third term as an umbrella, "type property" (meaning a static-or-class property) or "type method" (meaning a static-or-class method), which just makes the situation even worse.
The badness of the situation is also revealed by what you have to do in protocols: you declare a class property in a protocol and then if a struct adopts it, it calls that a static property. Same thing with a class method in a protocol; an adopting struct must call that a static method. You'd think that this alone would have told them they'd done a bad thing.
Edit: The more I think about it, the more I like the proposal put forth by newacct in a comment below. If Apple had simply used the umbrella keyword type here as part of the language, the whole problem would have been solved. We could have declarations type var, type let, type func, and this would work equally in enums, structs, classes, and protocols across the board.
From the Swift Language Guide on Methods, Apple has chosen to differentiate the syntax used, based upon the fundamental Type that you're building.
Classes declare "Type Methods" with the keyword Class. Example:
class MyClass {
class func myFunc(){ ... }
}
Structs declare "Type Methods" with the keyword Static. Example:
struct MyStruct {
static func myFunc(){ ... }
}
In both cases, crating a Type Method allows you to invoke the method without first creating an instance of the class or struct.
Whereas a non class/static function would require something like
let instance = MyClass()
instance.myFunc()
... declaring the variable as a Type Method allows something like
MyClass.myFunc()
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 8 years ago.
Improve this question
Is there any situation when I need to declare the class data members as public?
Are there any chances of errors with such declarations?
Need to? No.
Any data access can be done through getters and setters:
(the truth of the above statement may depend on the language)
private member
public getMember()
return member
public setMember(newValue)
member = newValue
Instead of
public member
Errors? No. Well, apart from having to change your code to use the getters and setters instead.
Want to? Possibly.
The main disadvantage of using getters and setters is how pretty your code looks - how readable it is and code bloating.
See this for advantages of using getters and setters.
If using getters and setters classifies as similar to making the member public for you, then there are many scenario's where you need this at one of these kinds of access. Consider an artificial example of having a Car class. There would be many reasons why you'd want to get the windscreen member variable.