Book Image

Hands-On Design Patterns and Best Practices with Julia

By : Tom Kwong
Book Image

Hands-On Design Patterns and Best Practices with Julia

By: Tom Kwong

Overview of this book

Design patterns are fundamental techniques for developing reusable and maintainable code. They provide a set of proven solutions that allow developers to solve problems in software development quickly. This book will demonstrate how to leverage design patterns with real-world applications. Starting with an overview of design patterns and best practices in application design, you'll learn about some of the most fundamental Julia features such as modules, data types, functions/interfaces, and metaprogramming. You'll then get to grips with the modern Julia design patterns for building large-scale applications with a focus on performance, reusability, robustness, and maintainability. The book also covers anti-patterns and how to avoid common mistakes and pitfalls in development. You'll see how traditional object-oriented patterns can be implemented differently and more effectively in Julia. Finally, you'll explore various use cases and examples, such as how expert Julia developers use design patterns in their open source packages. By the end of this Julia programming book, you'll have learned methods to improve software design, extensibility, and reusability, and be able to use design patterns efficiently to overcome common challenges in software development.
Table of Contents (19 chapters)
1
Section 1: Getting Started with Design Patterns
3
Section 2: Julia Fundamentals
7
Section 3: Implementing Design Patterns
15
Section 4: Advanced Topics

Chapter 8

What are the benefits of developing assessor functions?

Assessor functions are a great way to provide an official API to users of the particular object. The underlying implementation is therefore decoupled from the interface. Should there be any changes to the implementation, there will be zero impact on users of the object as long as the contract of the assessor functions is unchanged.

What would be an easy way to discourage the use of internal fields of an object?

The easiest way to discourage the use of internal fields of an object is to have a special naming convention. A commonly used convention is to have an underscore as the prefix of the field name. If the programmer tries to use the field, then they are reminded that the field is supposed to be private.

Which functions may be extended as part of the property interface?

There are three functions from the Base...