Notes about the course
Project with exercises
Quiz 1
3 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
errorfunctionSummary
Item 6: Prefer standard errors to custom ones
Item 6: Prefer standard errors to custom ones
Item 7: Prefer a nullable or
Resultresult type when the lack of a result is possibleItem 7: Prefer a nullable or
Resultresult type when the lack of a result is possibleUsing
Resultresult typeUsing
nullresult typeNull is our friend, not an enemy
Defensive and offensive programming
Summary
Item 8: Close resources with
useItem 8: Close resources with
useSummary
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
datamodifier overridesWhen 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
whenexpressionsSummary
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
equalsItem 42: Respect the contract of
equalsEquality
Why do we need equals?
The contract of equals
The problem with equals in java.net.URL
Implementing
equalsSummary
Item 43: Respect the contract of
hashCodeItem 43: Respect the contract of
hashCodeHash table
The problem with mutability
The contract of hashCode
Implementing hashCode
Summary
Item 44: Respect the contract of
compareToItem 44: Respect the contract of
compareToDo we need a compareTo?
Implementing
compareToSummary
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
Effective Kotlin
Effective Kotlin
About
About the Course
Price
Course Price
Minimum price
$19.00
$29.00
You pay
$29.00Author earns
$23.20Instructor
About the Instructor
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.
Episode 254
An Interview with Marcin Moskała
Material
Course Material
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 earned over $14 million writing, 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.