Szybkie pytanie. Czy można to już nazwać programowaniem obiektowym w js?

Question

const btns = document.querySelectorAll('.btn')

const wrapper = document.querySelector('.wrapper')



const Color = class{

    constructor(color) {

        let _color = color;

        this.getColor = () => _color

    }



    setColor = () => {

         wrapper.style.backgroundColor = this.getColor()

       

    }

}

const red = new Color('red')

const blue = new Color('lightblue')

const green = new Color('lightgreen')

btns[0].addEventListener('click',red.setColor)

btns[1].addEventListener('click',blue.setColor)

btns[2].addEventListener('click',green.setColor)

 

Comments

Proszę stosować odpowiednią funkcję edytora postów do zamieszczania kodu.

Answer 1

Jak się przymknie jedno oko i mocno zmruży drugie, to tak. W końcu masz obiekt zawierający dane i jakieś zachowanie. Tylko że absolutnie nic by się nie stało, gdybyś zamienić klasę Color na prostą funkcję, która ustawia tło na podany jej kolor. Powiedziałbym nawet, że kod stałby się przez to prostszy.

No i nazwy samej klasy oraz metod nie oddają tego, co ta klasa tak naprawdę robi. Bo nie reprezentuje jako tako koloru, tylko pozwala zmienić tło jednego, konkretnego elementu. O wiele sensowniej byłoby, gdyby metoda setColor() przyjmowała element, jakiemu ma zmienić tło, jako parametr.

Cała koncepcja z getColor() i setColor() ma sens, gdy takie metody robią faktycznie to, na co wskazuje nazwa – pobierają i ustawiają wartość pola color klasy. Tutaj getColor() faktycznie to robi, ale setColor() już robi coś innego, przez co psuje tak naprawdę oczekiwania usera. W tak prostym przypadku równie dobrze można olać gettery i settery i po prostu pozwalać na bezpośrednie odczytywanie pola color. Dodatkowo, jak już wspominałem, klasa Color powinna reprezentować kolor, nie zaś ustawiać tło jakiemuś elementowi.

Comments

Jak się przymknie jedno oko i mocno zmruży drugie, to tak.

:D muszę sobie zapisać ten tekst, czuję że nie raz się przyda przy niektórych CR :)