ochococo / design-patterns-in-swift Goto Github PK

The observer pattern is acting like one. When setting new values, information should be invoked in observer object not in object that is observer. In fact it is acting like normal setter.

Hi,
Thanks for a great work and excellent samples. If you can add UML diagrams to every pattern it will be nice.

I am proposing the addition of Template Method with the use of Protocol and Protocol Extensions.

To ensure that one and ONLY one instance of a class is created, there should be a bit more than just having a public shared instance. One have to ensure that nobody else can create another instance by making the initializer private. So, the example might be extended as follows:

class DeathStarSuperlaser {
    static let sharedInstance = DeathStarSuperlaser()

    private init(){
     // Do something ...
   }
}

NOTE: In the playground the private scope might not be respected, since I could create instances of my singleton class even if the initializer was private, but in the "real" code I get the error "'DeathStarSuperlaser' cannot be constructed because it has no accessible initializers", when I try to crate an instance of my singleton by calling the initializer like this: let anotherLaser = DeathStarSuperlaser()

In Mediator case, just have the MessageMediator broadcast the message to all Programmers. But In GOF, mediator structure like below:

Apparently, programmers need to communicate with each other, so they also need to hold the MessageMediator.
Looking forward to your reply, thanks.

There are 3 more patterns from the classical GOF collection that are missing.
I will open a separate issue for each of them and send a pull request to add those too sometime this week.

So contributors don't have to remember about generating files.

Do you plan to upgrade this to Swift 2 or are the differences negligible when dealing with objects and design patterns?

You will probably need to add a return after the Table of Contents.

I think it's better to use enum for Keys because we don't need to initialize Keys.

Please see #32

class MessageMediator: Mediator {
private var colleagues: [Colleague] = []

func addColleague(colleague: Colleague) {
    colleagues.append(colleague)
}

func send(message: String, colleague: Colleague) {
    for c in colleagues {
        if c !== colleague { //for simplicity we compare object references
            colleague.receive(message)
        }
    }
}

}

It should be c.receive(message) :-)

Maybe will be good to improve the examples with multi paradigm in mind. Please take a look at more simple Swift 2 Multi-paradigm Decorator Pattern https://gist.github.com/carlosypunto/a179a9203b60c7b1c19357af717d0f54
Suggestions are welcome. Take the code if you want

For example in your Decorator code initialisers of Milk or WhipCoffee are no necesary

class CodeGenerator: ICodeGenerator{
    var delegate: IGeneratorPhases
}

This code can make circular reference because delegate has strong reference.

please see #32

Table of Contents in README.md has invalid sorting, in Behavioral section (Visitor pattern should be after Template Method pattern)

📷 Screenshot

For the generated giant readme, it's kind of hard to locate a certain pattern. If there is a table of contents like this:

Table of Contents

it could be very helpful. 😜

Constant properties.

Spotted by M. Lisiecki.

Is it possible to add an example of the Factory design pattern in Swift?

Here is an implementation example in Java:
https://www.tutorialspoint.com/design_pattern/factory_pattern.htm

Here is the difference between Java interfaces and Swift protocols:
http://stackoverflow.com/questions/30859334/compare-protocol-in-swift-vs-interface-in-java

Thanks!

There is an opportunity to improve readability in ./source/creational/builder.swift. The opportunity is to use guard let... instead of if let... reducing indenting's length.

Hi,

At first I want to thanks for this repo, it's great for people who want to read about design patterns in swift and it is good for me, for learning others by contributing and sharing our knowledge and for learning myself when I'm wiring examples of some patterns :)

What this issue is about is maintenance Readme.markdown file. I was thinking a little bit and I'm afraid this file is bulky, hard to browse and maintenance. Wouldn't it be better to move all the patterns implementations to separated .swift files and create links in description to these files (with some description optionally)?

The file could looks like this:

/// Pattern name
/// Xcode version

/** Short description
description here
*/

/// Implementation
implementation here

/// Usage
One or more use cases

What do you think about the idea?

It would be great if we could have better explanation for the patterns as reading entire code to understand what it does is rather difficult!

./source/behavioral/chain_of_responsibility.swift has an opportunity to improve readability.

Consider this snippet from the file:

if let next = self.next {
    return next.withdraw(amount: amount)
}

That could be rewritten as:

if let next {
    return next.withdraw(amount: amount)
}

Though, it requires newer version of the Swift programming language.

Monostate example code has build issue.

And it uses struct, since struct is "copy" semantics, which is not the good way to share singularity state.

struct Settings {

    enum Theme {
        case .old // build error
        case .new // build error
    }

    private static var theme: Theme // build error

    var currentTheme: Theme {
        get { Settings.theme }
        set(newTheme) { Settings.theme = newTheme }
    }
}

I think there's some text showing up that probably shouldn't:

let laser = DeathStarSuperlaser.sharedInstance
Behavioral |
Creational |
Structural

https://github.com/ochococo/Design-Patterns-In-Swift#example-3

extension NovellasCollection: SequenceType {
    typealias Generator = AnyGenerator<T>

    func generate() -> AnyGenerator<T> {
        var i = 0
        // Requires the `defer`
        return AnyGenerator { defer {i += 1}; return i >= self.novellas.count ? nil : self.novellas[i] }
    }
}

If confirmed I can create a PR.

Thanks for this wonderful repo!!

Any plan to update to swift 4?

What is the reasoning behind having the BuilderClosure in the implementation of the Builder pattern?

 typealias BuilderClosure = (DeathStarBuilder) -> ()

    init(buildClosure: BuilderClosure) {
        buildClosure(self)
    }

I don't recall seeing this when working with the Builder pattern in other languages and my code works without it.

Facade direct link in README.md file is broken and when you tap on it doesn't direct you to the Facade section

https://github.com/ochococo/Design-Patterns-In-Swift/blob/master/source-cn/contents.md

进去点击 会404

谢谢

Template method is also a classic design pattern. Will add it here.

Hi guys,

I have used monostate in some cases, so I think maybe it would be important a reference inside this documentation.
I opened a Pull Request, I wonder if someone helps me to improve the example or description.

About monostate

Best,
Victor

(planned just after https://github.com/ochococo/Design-Patterns-In-Swift/tree/swift5 is merged to master)

...SuperlaserTarget -> ...SuperLaserTarget

Why no invoker on the Command Pattern?