しつもんが あります

---

すみません、せんせい。しつもんが　あります。

はい、なんですか。

"It's hot today, isn't it?" は　にほんご　で　なんですか。

うん、「きょうは　あついですね」です。

ふ～ん、じゃ、"Yes, That's right." は　なんですか。

「そうですね」です。

わかりました。ありがとおございました。きょうは　あついですね。せんせい。


ああ。そうですね。

---

せんせい。しつもんが　あります。

はい、なんですか。

"That's good, isn't it?" は　にほんご　で　なんですか。

「いいですね」です。

じゃ、"Yes, That's good." は　なんですか。

それも「いいですね」です。

わかりました。ありがとおございました。

はい

---

せんせい。しつもんが　あります。

はい、なんですか。

「そうですか」つて　なんですか。

「そうですか」は　'Oh, you're' Oh, it is.' です。

ああ、 わかりました。ありがとおございました。

はい

Algorithm ex: Fibonacci Sequence

Write a method that returns a Fibonacci sequence from 1 to n.

The Fibonacci sequence là 1 danh sách các số, mà giá trị tiếp theo trong dãy sốlà tổng của 2 số đàng trước. chuỗi số cũng định nghĩa rằng số đầu tiên là số 0 và số tiếp theo là số 1.

Using return with if Statements

Whenever you have a return statement inside an if statement, you do not need to provide an else clause. If an if statement condition is false, the code execution continues after the block. If the statement is true, the method execution will finish with the return statement. This has the advantage that your code does not need an extra level of indentation due to the redundant else block:

Caching previously computed Fibonacci numbers

Measuring the performance increase

Non cached time: 19211293000 nanoseconds
Cached time: 311000 nanoseconds

-> Quite an improvement: from 19 seconds to 0.000311 seconds.

Write a factorial implementation that does not use recursion.

An iterative implementation of a factorial

Happy coding

Algorithm example: Implementing FizzBuzz

Write an algorithm that prints all numbers between 1 and n, replacing multiples of 3 with the StringFizz, multiples of 5 with Buzz, and multiples of 15 with FizzBuzz.

-> lưu ý nhỏ là phải check 15 trước. vì nếu 1 số chia hết cho 15 thì cũng chia hết cho 5 và 3

Abstraction with FizzBuzz

Happy coding

Singleton Pattern

1 singleton là 1 class mà chỉ cho phép 1 instance (thể hiện) đc tạo.

It is often used to create a single point of entry to a third party, such as a database or web service, so that the number of connections can be easily managed and configured in one place.

ex: problem of singleton

The approach here is called lazy initialization: The Singleton instance is only created when it is first needed. At first glance, it looks like any other calls to getInstance() will return that same instance. If, however, INSTANCE is null, and a thread is switched after the if statement but before INSTANCE is initialized, then a second (or more) thread calling getInstance() will also have the if statement return true and create a new object. This can result in strange, erratic behavior or worse, memory leaks resulting in the JVM eventually crashing.

Java 5 introduced the Enum type. If you create the Singleton as a single-element Enum, the JVM guarantees that only one instance will ever be created

Be aware that using the Singleton Pattern can lead to other issues: It can be very difficult to test in isolation, especially if the Singleton performs heavyweight operations, such as writing to a database. It is often better to simply manage any “singleton-like” object as a dependency on a class, and use a dependency injection framework to construct only one object.

Singletons work best in specialized applications, such as a GUI on a desktop or mobile application

Happy coding

Design Pattern

How is the Builder Pattern useful?

Can you give an example of the Strategy Pattern?

The Strategy Pattern enables you to easily swap specific implementation details of an algorithm without requiring a complete rewrite. You can even swap implementations at run time. The Strategy Pattern is often used in conjunction with dependency injection to allow implementations to be swapped out for test-specific code, or to allow mocked implementations to be used instead.

Implementing a logger with the Strategy Pattern

-> bạn có thể dùng ConsoleLogging để test,
FileLogging cho production
sau này muốn thêm kiểu logging khác thì interface vẫn ko thay đổi

Happy coding

SOLID principle

1. 1 class chỉ giữ 1 chức năng

-> thay đổi class chỉ 1 lý do duy nhất

ex class vi phạm:

-> làm tới 3 nhiệm vụ -> tách thành 3 class

2. có thể mở rộng 1 class, nhưng ko đc sửa trong class đó?

-> khi thêm chức năng mới, ta nên viết class mới, kế thừa, mở rộng chức năng từ class cũ chứ ko nên sửa class cũ.

3. trong 1 chương trình, các object của class con có thể thay đổi class cha mà ko làm thay đổi tính đúng đắn của chương trình

ex: class cha: Vịt
class con: vịt bầu + vịt xiêm
giờ viết thêm class vit chạy pin
vì class cha ko có pin nên gây lỗi
-> vi phạm quy tắc này

4. thay vì dùng 1 interface lớn, ta nên tách thành nhiều interface nhỏ với nhiều mục đích cụ thể

ex. 1 interface có 100 method...
khi kế thừa, có thể 1 số class ko cần một số method (trong 100 method đó) -> nên tách ra.

5. các module cấp cao ko nên phụ thuộc vào module cấp thấp

-> cả 2 nên phụ thuộc vào abstraction

Interface ko nên phụ thuộc vào chi tiết và ngược lại (các class giao tiếp với nhau thông qua interface chứ ko nên qua implemention)

ex: đèn tròn và đèn huỳnh quang -> đều có đuôi tròn
khi lắp thì ổ điện chỉ quan tâm đuôi tròn (interface)
mà ko quan tâm implement của nó (đền tròn và đèn huỳnh quang)

happy coding

Java note

1. String concatenation

Với những case đơn giản thì ko cần thiết phải sử dụng StringBuilder
Trong java, String object thì immutable - nghĩa là 1 khi đã tạo là ko thể thay đổi.
Ví dụ:
String str= "Hello";
String str1= str+ " World";

LinkedList: insert new element ở đầu và ở giưã good.

Kết luận:

a. you should use an ArrayList if you need random access to elements in the list, especially if your use case could result in large lists.
b. If you intend to make many insertions and deletions particularly if you make them at the beginning or in the middle of the list, then a LinkedList would make more sense

2. Queue - First in - First out
3. Tree - Binary Tree is common
1 element có tối đa 2 con

binary search tree:

elements “less than” the value of a given node are children on the left, and elements “greater than” the value of a given node are children on the right.

4. Tree Map and Hash Map

TreeMap the order of the keys is preserved when iterating over the whole collection, because the collection is stored in order.
This isn’t possible with a HashMap, because the keys are stored dependent on the object’s hashCode
LinkedHashMap same HashMap, -> so element retrieval will be O(1)

5. SET

A set is an unordered collection of objects that does not contain any duplicates.

happy coding