Effective Kotlin (The Course)
$19.00
Minimum price
$29.00
Suggested price

Effective Kotlin

Course Info

This course includes 1 attempt.

Share

Course Material

  • Notes about the course
  • Project with exercises
  • icon/quiz Created with Sketch.
    Quiz 13 attempts allowed
  • Introduction: Be pragmatic
  • Part 1: Good code
  • Chapter 1: Safety
  • Item 1: Limit mutability
  • Limiting mutability in Kotlin
  • Read-only properties
  • Separation between mutable and read-only collections
  • Copy in data classes
  • Different kinds of mutation points
  • Summary
  • Item 2: Eliminate critical sections
  • The problem with threads and shared state
  • Synchronization in Kotlin/JVM
  • Atomic objects
  • Concurrent collections
  • Do not leak mutation points
  • Summary
  • Item 3: Eliminate platform types as soon as possible
  • Item 3: Eliminate platform types as soon as possible
  • Summary
  • Item 4: Minimize the scope of variables
  • Item 4: Minimize the scope of variables
  • Capturing
  • Summary
  • Item 5: Specify your expectations for arguments and state
  • Item 5: Specify your expectations for arguments and state
  • Arguments
  • State
  • Nullability and smart casting
  • The problems with the non-null assertion !!
  • Using Elvis operator
  • error function
  • Summary
  • Item 6: Prefer standard errors to custom ones
  • Item 6: Prefer standard errors to custom ones
  • Item 7: Prefer a nullable or Result result type when the lack of a result is possible
  • Item 7: Prefer a nullable or Result result type when the lack of a result is possible
  • Using Result result type
  • Using null result type
  • Null is our friend, not an enemy
  • Defensive and offensive programming
  • Summary
  • Item 8: Close resources with use
  • Item 8: Close resources with use
  • Summary
  • Item 9: Write unit tests
  • Item 9: Write unit tests
  • Summary
  • Chapter 2: Readability
  • Item 10: Design for readability
  • Reducing cognitive load
  • Do not get extreme
  • Conventions
  • Item 11: An operator’s meaning should be consistent with its function name
  • Item 11: An operator’s meaning should be consistent with its function name
  • Unclear cases
  • When is it fine to break this rule?
  • Summary
  • Item 12: Use operators to increase readability
  • Item 12: Use operators to increase readability
  • Item 13: Consider making types explicit
  • Item 13: Consider making types explicit
  • Explicit API mode for library authors
  • Summary
  • Item 14: Consider referencing receivers explicitly
  • Item 14: Consider referencing receivers explicitly
  • Many receivers
  • DSL marker
  • Summary
  • Item 15: Properties should represent a state, not a behavior
  • Item 15: Properties should represent a state, not a behavior
  • Item 16: Avoid returning or operating on Unit?
  • Item 16: Avoid returning or operating on Unit?
  • Item 17: Consider naming arguments
  • Item 17: Consider naming arguments
  • When should we use named arguments?
  • Parameters with default arguments
  • Many parameters with the same type
  • Parameters with function types
  • Summary
  • Item 18: Respect coding conventions
  • Item 18: Respect coding conventions
  • Part 2: Code design
  • Chapter 3: Reusability
  • Item 19: Do not repeat knowledge
  • Item 19: Do not repeat knowledge
  • Knowledge
  • Everything can change
  • When should we allow code repetition?
  • The single responsibility principle
  • Summary
  • Item 20: Do not repeat common algorithms
  • Item 20: Do not repeat common algorithms
  • Learn the standard library
  • Implementing your own utils
  • Summary
  • Item 21: Use generics when implementing common algorithms
  • Item 21: Use generics when implementing common algorithms
  • Generic constraints
  • Summary
  • Item 22: Avoid shadowing type parameters
  • Item 22: Avoid shadowing type parameters
  • Summary
  • Item 23: Consider using variance modifiers for generic types
  • Item 23: Consider using variance modifiers for generic types
  • Item 24: Reuse between different platforms by extracting common modules
  • Item 24: Reuse between different platforms by extracting common modules
  • Full-stack development
  • Mobile development
  • Libraries
  • All together
  • Summary
  • Chapter 4: Abstraction design
  • Abstraction in programming
  • Car metaphor
  • Item 25: Each function should be written in terms of a single level of abstraction
  • Item 25: Each function should be written in terms of a single level of abstraction
  • Level of abstraction
  • The Single Level of Abstraction principle
  • Abstraction levels in program architecture
  • Summary
  • Item 26: Use abstraction to protect code against changes
  • Item 26: Use abstraction to protect code against changes
  • Constant
  • Functions
  • Classes
  • Interfaces
  • Next ID
  • Abstractions give freedom
  • Problems with abstraction
  • How to find a balance?
  • Summary
  • Item 27: Specify API stability
  • Item 27: Specify API stability
  • Summary
  • Item 28: Consider wrapping external APIs
  • Item 28: Consider wrapping external APIs
  • Summary
  • Item 29: Minimize elements’ visibility
  • Item 29: Minimize elements’ visibility
  • Using visibility modifiers
  • Summary
  • Item 30: Define contracts with documentation
  • Item 30: Define contracts with documentation
  • Contracts
  • Defining a contract
  • Do we need comments?
  • The KDoc format
  • The type system and expectations
  • Leaking implementation
  • Summary
  • Item 31: Respect abstraction contracts
  • Item 31: Respect abstraction contracts
  • Contracts are inherited
  • Summary
  • Chapter 5: Object creation
  • Item 32: Consider factory functions instead of secondary constructors
  • Companion Object Factory Functions
  • Top-level factory functions
  • Builders
  • Conversion methods
  • Copying methods
  • Fake constructors
  • Methods on factory classes
  • Summary
  • Item 33: Consider a primary constructor with named optional arguments
  • Item 33: Consider a primary constructor with named optional arguments
  • Telescoping constructor pattern
  • Builder pattern
  • Summary
  • Item 34: Consider defining a DSL for complex object creation
  • Item 34: Consider defining a DSL for complex object creation
  • Defining your own DSL
  • When should we use DSLs?
  • Summary
  • Item 35: Consider using dependency injection
  • Item 35: Consider using dependency injection
  • Summary
  • Chapter 6: Class design
  • Item 36: Prefer composition over inheritance
  • Simple behavior reuse
  • Taking the whole package
  • Inheritance breaks encapsulation
  • Restricting overriding
  • Summary
  • Item 37: Use the data modifier to represent a bundle of data
  • Item 37: Use the data modifier to represent a bundle of data
  • The methods that data modifier overrides
  • When and how should we use destructuring?
  • Prefer data classes instead of tuples
  • Summary
  • Item 38: Use function types or functional interfaces to pass operations and actions
  • Item 38: Use function types or functional interfaces to pass operations and actions
  • Using function types with type aliases
  • Reasons to use functional interfaces
  • Avoid expressing actions using interfaces with multiple abstract methods
  • Summary
  • Item 39: Use sealed classes and interfaces to express restricted hierarchies
  • Item 39: Use sealed classes and interfaces to express restricted hierarchies
  • Sealed classes and when expressions
  • Summary
  • Item 40: Prefer class hierarchies instead of tagged classes
  • Item 40: Prefer class hierarchies instead of tagged classes
  • Tagged classes are not the same as classes using the state pattern
  • Summary
  • Item 41: Use enum to represent a list of values
  • Item 41: Use enum to represent a list of values
  • Enum or a sealed class?
  • Summary
  • Item 42: Respect the contract of equals
  • Item 42: Respect the contract of equals
  • Equality
  • Why do we need equals?
  • The contract of equals
  • The problem with equals in java.net.URL
  • Implementing equals
  • Summary
  • Item 43: Respect the contract of hashCode
  • Item 43: Respect the contract of hashCode
  • Hash table
  • The problem with mutability
  • The contract of hashCode
  • Implementing hashCode
  • Summary
  • Item 44: Respect the contract of compareTo
  • Item 44: Respect the contract of compareTo
  • Do we need a compareTo?
  • Implementing compareTo
  • Summary
  • Item 45: Consider extracting non-essential parts of your API into extensions
  • Item 45: Consider extracting non-essential parts of your API into extensions
  • Summary
  • Item 46: Avoid member extensions
  • Item 46: Avoid member extensions
  • Why to avoid extension functions
  • Avoid, not prohibit
  • Summary
  • Part 3: Efficiency
  • Chapter 7: Make it cheap
  • Item 47: Avoid unnecessary object creation
  • Is object creation expensive?
  • Using primitives
  • Summary
  • Item 48: Consider using object declarations
  • Item 48: Consider using object declarations
  • Summary
  • Item 49: Use caching when possible
  • Item 49: Use caching when possible
  • Summary
  • Item 50: Extract objects that can be reused
  • Item 50: Extract objects that can be reused
  • Lazy initialization
  • Summary
  • Item 51: Use the inline modifier for functions with parameters of functional types
  • Item 51: Use the inline modifier for functions with parameters of functional types
  • A type argument can be reified
  • Functions with functional parameters are faster when they are inlined
  • Non-local return is allowed
  • Costs of inline modifiers
  • Crossinline and noinline
  • Summary
  • Item 52: Consider using inline value classes
  • Item 52: Consider using inline value classes
  • Indicate unit of measure
  • Protect us from value misuse
  • Optimize for memory usage
  • Inline value classes and interfaces
  • Typealias
  • Summary
  • Item 53: Eliminate obsolete object references
  • Item 53: Eliminate obsolete object references
  • Chapter 8: Efficient collection processing
  • Item 54: Prefer Sequences for big collections with more than one processing step
  • Item 54: Prefer Sequences for big collections with more than one processing step
  • Order is important
  • Sequences do the minimal number of operations
  • Sequences can be infinite
  • Sequences do not create collections at every processing step
  • When aren’t sequences faster?
  • What about Java streams?
  • Kotlin Sequence debugging
  • Summary
  • Item 55: Consider associating elements to a map
  • Item 55: Consider associating elements to a map
  • Using Maps
  • Associating elements with keys
  • Summary
  • Item 56: Consider using groupingBy instead of groupBy
  • Item 56: Consider using groupingBy instead of groupBy
  • groupBy
  • groupingBy
  • Summary
  • Item 57: Limit the number of operations
  • Item 57: Limit the number of operations
  • Summary
  • Item 58: Consider Arrays with primitives for performance-critical processing
  • Item 58: Consider Arrays with primitives for performance-critical processing
  • Summary
  • Item 59: Consider using mutable collections
  • Item 59: Consider using mutable collections
  • Summary
  • Item 60: Use appropriate collection types
  • Item 60: Use appropriate collection types
  • Array-based list
  • Deque
  • Linked lists
  • Hash tables
  • Sorted binary trees
  • Summary
  • Dictionary
  • Function vs method
  • Extension vs member
  • Parameter vs argument
  • Primary vs Secondary constructor

Instructors

    • Marcin Moskała
      Marcin Moskała

      Marcin Moskala is an experienced developer and Kotlin trainer. He is the founder of the Kt. Academy, Kotlin GDE, an official JetBrains partner for teaching Kotlin, and author of the books Effective Kotlin, Kotlin Coroutines, and Android Development with Kotlin.

The Leanpub 60 Day 100% Happiness Guarantee

Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.

Now, this is technically risky for us, since you'll have the book or course files either way. But we're so confident in our products and services, and in our authors and readers, that we're happy to offer a full money back guarantee for everything we sell.

You can only find out how good something is by trying it, and because of our 100% money back guarantee there's literally no risk to do so!

So, there's no reason not to click the Add to Cart button, is there?

See full terms...

Earn $8 on a $10 Purchase, and $16 on a $20 Purchase

We pay 80% royalties on purchases of $7.99 or more, and 80% royalties minus a 50 cent flat fee on purchases between $0.99 and $7.98. You earn $8 on a $10 sale, and $16 on a $20 sale. So, if we sell 5000 non-refunded copies of your book for $20, you'll earn $80,000.

(Yes, some authors have already earned much more than that on Leanpub.)

In fact, authors have earnedover $13 millionwriting, publishing and selling on Leanpub.

Learn more about writing on Leanpub

Free Updates. DRM Free.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Learn more about Leanpub's ebook formats and where to read them

Write and Publish on Leanpub

You can use Leanpub to easily write, publish and sell in-progress and completed ebooks and online courses!

Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks.

Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. (Or, if you are producing your ebook your own way, you can even upload your own PDF and/or EPUB files and then publish with one click!) It really is that easy.

Learn more about writing on Leanpub

Publish Early, Publish Often

  • Path
  • There are many paths, but the one you're on right now on Leanpub is...
  • › C › Effective Kotlin

*   *   *

Leanpub is copyright © 2010-2024 Ruboss Technology Corp.
All rights reserved.

This site is protected by reCAPTCHA
and the Google Privacy Policy and Terms of Service apply.