Metody to funkcje zawarte w klasach i na ogół będą publiczne lub prywatne. Ogólnie metody mają dostęp do danych klas (które powinny być hermetyzowane z dala od innych obiektów), a także do swoich metod publicznych i prywatnych. Metody publiczne są widoczne dla innych obiektów i powinny być jak najbardziej stabilne, ponieważ inne obiekty mogą zacząć od nich zależeć. Jeśli je zmienisz, możesz nieoczekiwanie przerwać działanie innego obiektu. Metody prywatne są widoczne tylko dla samej instancji, co oznacza, że inne obiekty nie mogą (lub nie powinny, jak ma to miejsce w przypadku języka R) bezpośrednio wywoływać te metody. Prywatne metody mogą zmieniać się tak często, jak to konieczne. Metody publiczne wykorzystują inne metody, publiczne lub prywatne, w celu dalszego delegowania zachowania. Ta delegacja rozbija problem na bardzo małe części, które są łatwo zrozumiałe, a programista zastrzega sobie prawo do modyfikowania prywatnych metod według własnego uznania. Inne obiekty nie powinny na nich polegać. Zwróć uwagę, że technicznie rzecz biorąc, tylko metody publiczne istnieją w R. W jednym z modeli obiektowych R można ukryć metody, a pod innym można je umieścić w innym środowisku, ale to nie czyni ich niedostępnymi, jak w przypadku metod prywatnych w inne języki. Wychodząc z tego, nie zajmujemy się również pojęciem metod chronionych, które są metodami widocznymi dla klasy i jej podklas. Nawet jeśli technicznie nie ma prywatnych metod w R, będziemy programować tak, jakby były. Brak jakiegoś kompilatora lub mechanizmu sprawdzającego błędy, który powiedziałby ci, że korzystasz z prywatnych metod, kiedy nie powinieneś, nie jest wymówką, aby to robić. Powinieneś zawsze tworzyć kod wysokiej jakości, nawet jeśli nie jest to wyraźnie wymuszone przez mechanizmy językowe.
To, co powiedzieliśmy wcześniej, sugeruje, że powinieneś uczynić swoje obiekty tak prywatnymi, jak to tylko możliwe, aby były spójne i oddzielone, co jest fantazyjnym określeniem samodzielności i niezależności. Innymi słowy, spróbuj maksymalnie zredukować liczbę metod w swoich obiektach. Oczywiście spójność i oddzielenie od sprzężeń są znacznie bardziej ogólnymi pomysłami niż tylko zmniejszenie liczby prywatnych metod, ale to dobry początek.